必備素質

對軟體專案的管理者來說，他最應該關心的是能否按時優質地交付產品的問題。在計劃軟體開發的路線時，他必須首先考慮軟體基本功能的實現和工程交付期，其次，才考慮產品的賣點，許多工程失敗的原因就在於設計者沒有時間概念，工程前松後緊或增加了許多次要的技術特徵，這樣反而對產品質量形成了威脅，總之，最重要的是懂得統籌安排各個環節。

面試程式設計師

理想的方法是由開發小組的其他成員一起來面試，如果誰看不上眼，他都不能加入，否則以後會有很多麻煩。這樣做的另一個好處是藉此機會互相認識一下，經理一定要把新員工介紹給大家，並且小組每個員工都應該過來握手介紹自己，這是起碼的招聘禮節。

程式設計師需要關心尊重

曾經有個例子，某公司開發人員王某由於剛開始學習程式設計，技術水平差一點，常常受到經理的“另眼相看”，每次軟體出現了問題都懷疑是他的原因，老開他的低階玩笑，這位員工會有怎樣的表現就可想而知了。經理透過這種手段能夠迫使這一位自動辭職嗎？非也，這位員工後來工作非常不負責任，把程式碼寫得既長又重複，且在程式碼中留下大量的隱患，此時，經理卻反而不敢過份得罪他了（否則，留下的巨量程式碼很難維護）。如果認為某人不適合目前工作，為何不另請高明？既然已經請他作了這件工作，就得尊重他。不能指望開發人員在非工作場合談吐得體、辦事周到、眼觀六路、耳聽八方，正所謂“尺有所短，寸有所長”，例如要求技術人員在酒席宴上象公關小姐或公關先生一樣舉止適度，從來不會有好的效果。軟體人員普遍喜歡自由而寬鬆的工作環境，最好不要做過多的無謂的規定，例如不準遲到、上班必須換拖鞋，否則罰款等等。如果確實有人經常上班遲到，工作不認真等，首先應該瞭解原因，此時多作思想工作是必要的，許多公司的經理們認為“思想工作”是過時的東西了，其實不然，私企職工揹負的心理壓力其實很重。他們特別需要有人關心，特別需要心理上的“減負”。管理需要合理地使用資金，有的公司在不該花錢的時候花錢，在需要花錢的時候節支，結果卻事倍功半。例如，員工向公司提出買臺電視、熱水器、電風扇等生活設施（甚至是廁所的紙巾）時，公司強調節支，而在組織大家集體乘飛機到外省旅遊這種事情上卻捨得花錢，這種現象比較普遍，效果卻不一定好，因為員工會認為公司集中花一筆錢是在收買人心。所以，關心職工的事情需要過細地作。

心態調整問題

作坊式作業的時候，軟體是由一兩個程式設計師寫的，軟體寫完了，雖然在產權上這個軟體或許不是自己的，但程式設計師心裡會覺得這個軟體就是自己的，對這個軟體的感情就象對自己的兒子一樣，關於這個軟體一切成敗榮辱都被看成是自己的，在這種心態下，程式設計師會不分白天黑夜地超常投入。而現在的軟體一般都是十幾人、幾十人甚至上百人協作完成，軟體寫成後究竟是誰的？有了榮譽是誰的？都不是太明確，同樣，軟體有點毛病也不專是哪個人的，而是大家的，既然是大家的事情，那就讓大家來做，我為什麼多操那個心？如何在大協作的背景下最大限度地提高個人的積極性很值得仔細研究。設計部分大家參與、多開會交流、讓程式設計師直接傾聽使用者對自己工作的意見等方法不妨一試。

工資與福利

如果公司給每個人的薪水相差較大就會引起混亂。例如，某公司高薪聘請了一位高人，卻導致公司許多職工的消極怠工，最後使公司陷入絕境。曾經是非常驚人之舉，最後不了了之！工作成績與獎金掛鉤似乎無可非議，可是某外企的做法卻產生了意想不到的效果。經理在每次週會上都給每個人機會，讓他說出本週內做了哪些工作，最感得意的成績是什麼，原則上誰做得多，就給誰獎金多，可是這種競爭卻造成了同事之間的猜忌和隔閡，本應共享的技術開始保密了，本屬別人的錯誤也不好指出了，本屬自己的錯誤也開始狡辯了。
公司應該負責提供良好的膳食，有些小公司不提供午餐和晚餐，這時，公司裡那些“無家可歸”者吃飯就成了問題，有家300多人的公司，食堂廚師是老闆的親戚，每天做出來的飯菜質量很差，許多新應聘的員工吃了這種飯食馬上就想跳槽了。
專案獎金不能平均分配，但也不能只給專案經理一個人，做軟體僅僅有錢是遠遠不夠的，還需要培養程式設計師對企業、對產品的感情，後進來的人是在為已有的軟體加功能，是在維護軟體，他並沒有權改造軟體，只有權改BUG，這樣的工作很繁複，沒有什麼新意，具有犧牲的意義。所以應該給這些程式設計師高待遇，不分資歷想辦法多給他們一點榮譽。如果不是這樣，比較高階的軟體人才就很難留住。
技術最強的人可以拿最高的工資，卻不一定要做專案經理，因為他往往缺乏管理和專案調控的能力，而軟體大規模工程化研發最需要的恰恰不是一個技術骨幹自己能多做多少，而是透過有效的管理，調動大家的積極性，把團隊的力量發揮出來，所以，應該選具有豐富開發經驗的管理型人才做專案經理，但是，如何平衡技術骨幹和做管理的專案經理之間的關係？可以讓技術骨幹在待遇上得到平衡，讓技術骨幹和做管理的專案經理拿一樣多的工資，甚至更多，而且在技術問題上充分尊重技術骨幹的意見。[@more@]

軟體專案管理心得（轉）

相關文章