項目管理的經歷:
今天的陽光很猛，讓我心潮澎湃。在早上的會議，老板任命我為項目主管，負責公司WEB系統新增功能開發工作。這是我第一次全面負責軟件項目開發。在這過程有成功的喜悅，也有很多失敗的教訓。我將自己的感受和體會寫出來，與大家共勉。
一． 第一天收到的三份禮物
項目成功核心在于管理
對我而言，這個任命是意料之中，在過去的幾個項目我作為程序員都表現非常漂亮。我懷著無比激動的心情迷糊之中回到自己的辦公室，興奮令我久久難以平靜。這個時候，老板走進我的辦公室，笑瞇瞇的看著我說：“嗯，今天是你第一次全面負責項目吧，作為程序員你的表現我就不多說了。今天我送你一句話當作勉勵，程序開發是軟件項目的核心，但缺少管理和受控的開發過程，肯定不會在有限時間和成本內作出高質量的軟件產品。從今天開始你需要轉變角度，從一個項目主管角度思考和處理問題”。
老板走后，我獨自在辦公室思考著老板的這句話。在我過去作為程序員的開發過程中，程序員都是根據主管制定好的開發計劃，已有的模塊設計文檔，然后編寫程序。而從今天開始，我不只是一個程序員，更重要的是要從管理和受控的角度來思考如何在規定時間，有限成本完成項目，這是擺我前面的第一個考驗。
項目第一步是制定開發規范
窗外，太陽灼燒大地，也灼燒著我的心。在我還在迷糊思考如何開展項目管理的時候，公司CIO張力走進了我的辦公室，他也是我良師益友。
他拍了拍我的肩膀，哈哈的笑著說，“怎么樣？第一次做項目負責人感覺如何？我看你好象很緊張啵？”我看著張力，也不好意思的笑了，象看到救星一樣說：‘張總，我正想向你請教呀，項目第一步的關鍵是什么？”
張力說：“你作為程序員已經參加了各種的培訓，如軟件工程思想，項目管理以及CMM和ISO9000等等。我提醒一個就是首先需要先制定好你的開發規范和開發流程”。
“還記得我給你們培訓時說掌握軟件工程思想，對軟件開發負責人更為重要吧。沒有軟件工程管理，所有的事情都會亂七八糟。我們已經知道軟件和程序是兩個不同的概念，軟件除了程序還要有使用和維護該程序所需要的全部文檔。包括需求文檔、設計文檔、測試文檔、維護文檔以及使用手冊”。
從另一個方面看，要保證系統的協調性、統一性和連續性,也需要在開發之前制定嚴格、詳細的開發規范。開發規范的制定需要花費一定的時間和精力,但是"磨刀不誤砍柴功"。開發規范主要包括:需求文檔、系統設計規范、程序開發規范和項目管理規范等。它約束開發人員的行為和設計、編程風格,使不同子系統和模塊的設計、編程人員達成默契，以便形成整個系統的和諧步調和統一風格，也便于今后的系統維護和擴展工作。
溝通與掌控
窗外，陽光很眩目，當我正要甩開膀子準備制定開發規范的時候，辦公室又走進一個人，是公司的人力資源副總陳跡。他看著我意氣風發的樣子，笑著說：“怎么樣？火星，看你現在的樣子，你要去打架斗毆嗎？”。哈哈，風趣是陳總的風格。我連忙說：“陳總，我正想向你請教如何管理人的問題”。陳跡爽朗的說：“我剛剛看到老板和老張來過你的辦公室，我也來送你一份禮物吧，就是你需要時時記住，項目不是一個人在單打獨斗，需要時時與你的組員進行溝通和掌控”。
后來，我們還談了許多，陳跡認為項目負責人是對整個項目有控制和決定權,對項目開發的成敗負責。軟件開發中遇到問題的答案往往不止一個，因此需要有人對這些問題有決定權，避免扯皮。項目主管還要與組員溝通Weekly Report。包括目前進度，質量狀況，各種工作的進展等。一般來說程序員都討厭開會，但項目組至少每周全體開會一次，主要包括團隊交流，規格討論，bug診斷與處理，大家千萬別悶頭寫代碼。同時所有會議、討論都要有記錄。會前發會議議程，會中有人負責主持和記錄，會后有人負責發會議摘要，這都是高效會議的要點。
陳跡還說到一個非常有用的管理技巧，就是為項目組建立多個Mailing Group，這樣發起郵件來方便，而且能讓該收到電子郵件的人都收到、不該收到不被騷擾。通過電子郵件進行正式溝通的好處是免得抵賴，以后也可以時時閱讀。但也要避免矯枉過正，為了加強溝通最好的方法是先用電話和當面說，然后Email來確認。
二．需求分析的教訓
編碼，是軟件過程中一個實現的環節。說起編碼，感覺誰都能做，但做得好的確不多。我以前覺得寫代碼是最麻煩的事情，經過項目初期挫折的磨練我才發現寫代碼只是軟件開發中最簡單的一個步驟。最關鍵的第一個步驟是需求分析，就是要確定自己要做什么，應該怎么做，心里有個底。如果沒有對需求進行分析，可能出現項目設計出來的東西或最終提交的根本就不是所需要的，或有相當的差距。
需求規劃是根據具體需求情況分析和規劃出一個最終需求文檔。需求規劃就像高樓的地基，如果馬馬虎虎，就算是一塊磚塊沒擺好都可能導致整個高樓建設的失敗。目前，很多開發人員深感項目的需求文檔寫得都很單薄，不夠細致。對于一個缺乏需求管理的軟件項目而言，必定會導致系統不能實現預期的功能而需要在后期進行昂貴的修正，使得項目拖期、產生嚴重的質量問題與超出項目預算的現象。
了解真正的需求，可以讓我們在軟件的開發過程中少走很多的彎路，縮短軟件開發的周期，提高軟件的友好性，易操作性，易用性，從而來提升軟件的質量。
三． 項目控制兩大關鍵
在我埋頭苦干的時候，出現了兩個讓我措手不及的問題。就是有一天，CIO張力要求我把項目的管理文檔和項目中出現的問題管理資料給他參考，他想了解項目開發的情況。
張力認為，如果一個項目的每個步驟實實在在的眼皮底下進行，而且隨時可以翻閱，那么這個項目的成功一定不會遠了。開發過程的管理也是這樣，控制每一個細節，就會水到渠成。結果是由每個細節的過程來決定的，這需要控制好每個開發的細節，從管理文檔和問題管理這兩個方面就能直接看出項目控制得好與壞。
管理文檔
開發中我遇到許多開發人員會把工作進度報告看成是一種很重的負擔，他們認為他們是做開發的，不是寫報告的，花時間寫報告還不如多寫幾段代碼。實際上這是非常大的誤解，進度文檔的理念就是清楚的記錄每個事情的狀態。所有事情都記錄在案，可以一目了然完成了哪些模塊，更正了哪些問題。文檔的管理還有另一個好處就是容易翻閱歷史資料，減少內耗和誤差，這一點我在項目中體會很深。
開發流程不是操作復雜，就說明管理好；也不是稿紙寫一寫，會議開一開，就可以。最關鍵的是適合，看得見，管得著。從項目的需求分析、系統分析、編碼、調試、測試、發布都需要一步一步完成，不能輕視或忽略任何一步驟。軟件項目開發普遍存在忽視規范化，隨心所欲，沒有計劃，想到哪做到哪，其最終的結果是失去控制。那種認為只要產品做出來可以運行，何必花費許多精力去做文檔的觀點是錯誤的。經過實踐，我深刻體會到，沒有文檔會帶來很多問題。我認為文檔應該是開發中每段時間的里程碑標志，每個階段后都要提交相應的文檔，這樣可以用文檔去引導開發過程，從而拋棄隨心所欲的開發模式。
確保文檔質量的最有效方法就是評審，提交文檔后，組織相關人員對該文檔進行審核，在充分討論的基礎上進行文檔的重新修改和審核直到滿足項目要求。在不同的階段，需要不停地對文檔進行完善，使之真正成為貫穿整個過程的主線。
問題管理
在開發過程讓我感受非常深刻的經驗是，每個人都需要知道出了問題應該找誰。我們在開發過程中不可能是一帆風順的，不時地會遇到各種各樣的問題，而如何解決問題，或者說是如何想辦法盡早的解決問題，這個才是關鍵。而其中的最關鍵是不能有了問題而一聲不響，悶頭苦干，結果幾天下來以后，卻發現自己還是站在原地，而就算是你通過了幾天的努力完成了這個難題。但是這樣就是不是意味著你的成功了呢？
這樣不但自己的進度沒有辦法完成，更會延誤了整體的開發進度，別的成員就可能因為你一聲不響地沒有成果的努力，而不能再繼續下面的開發。應該說軟件開發過程中遇到問題一聲不響、埋頭苦干的做法是很愚蠢的，軟件開發要求的不是個人英雄主義精神而是團隊的整體合作精神。缺乏團隊的意識的個人和團隊必定是一個失敗的開始。
就開發人員而言，一旦碰到了難以解決的問題，不僅要自己努力調查，想辦法解決，一方面也要把存在的問題向PM反映，讓PM能夠知道存在的問題，而PM可以在進度會議、或者召開臨時緊急會議，把問題擺出來，通過大家來尋求解決的方案。一個人的力量畢竟是有限的，而個人的英雄主義是團隊開發的極大阻礙。
四．痛苦的進度管理
正如夏日的太陽一樣，一直在灼燒我的心的是對進度的控制。進度管理是軟件開發中最難以做好的一項工作。編程工作本身是一個難以量化的工作,再加上開發過程中對設計的修改等因素,使得項目開發工作經常不能按預計的時間完成。
開發人員最擔心“領導不斷催促，可系統提交日期一拖再拖”，項目負責人對此一籌莫展，束手無策。開發活動如同一個黑箱子，資金扔進去了，人員扔進去了，設備資源扔進去了，但不知道什么時候會出來結果，更沒有把握出來的東西是否是用戶所要的東西。
為避免人力、物力、財力浪費，就要進行有效的時間進度控制。在進度管理上主要有兩點，一點是總體進度，另一點就是個人進度了，而總體進度是建立在個人進度的基礎上的。
很多的人可能會以為，進度管理就是leader或者說是項目經理的事情，而與團隊的其它開發人員毫無關系。其實，我認為這樣的認識是非常的錯誤的，開發人員和所有過程都應該是有關聯的。總體進度應該由PM來控制和調整，而個人進度卻是軟件開發人員個人的責任和職責所在。很多時候開發人員可能會抱怨，開發時間本來就少，每天又讓我們寫這種毫無意義的個人進度報告，這樣就會浪費更多的時間。
其實不然，沒有良好的進度控制管理，擁有再精英的團隊也是白搭。開發人員在很多時候都是站在自己的出發點進行思考，相互間的溝通也只是個別人員之間的交流，并不能從根本上把握全體進度，也無法對進度作必要的分析和調整。而開發成員的個人開發進度報告匯總以后，能夠讓PM清楚的知道什么地方存在著問題，從而從項目整體上調整進度，決定相應的對策。
我的做法是每周將項目進度情況與項目進度計劃進行對比。對于拖延的工作如無充份理由,我則會督促有關人員加班或提高工作效率趕上進度。如有正常理由,在無法追回的情況下就可以修改進度計劃。在這里，我建議在軟件開發的過程中，不管項目的大小我們都應該抽時間來寫一份個人的進度報告，而在個人進度報告上應該有清晰的個人進度，存在問題，準備如何解決等等記述。總之，一句話，報告要簡明扼要能夠清楚地反映個人的進度狀況以及存在的問題。
同時個人進度管理也是開發人員的自我管理，是進度控制的最重要組成部分。個人進度是總體進度的基礎，個人進度的狀況好壞直接影響到團隊總體的進度推進狀況。
五．配置管理的重要性
在項目取得一定進展的時候，我們會為之興奮。在這里我想說說對配置管理（Software Configuration Management）的看法和理解。配置管理簡單說可以是版本控制管理，但配置管理并不僅僅是版本的控制管理，還應該涉及到代碼協調、履歷追蹤、品質檢查等等細節的問題。
為什么我們要在軟件的開發過程中引入配置管理？其實不為什么，在前面我也曾經提到過，軟件的開發是團隊行為，是合作，而不是個人英雄主義的自我表現。配置管理就是對軟件開發過程中的產品（這里是說產品，而不是代碼，因為我們的軟件開發還包括各類文檔，會議記錄等等）進行標識、追蹤、控制的過程，目的就是為了減少一些不可預料的錯誤，提高生產率。
一般來說可以使用配置管理工具來提高效率。例如常用的有VSS和CVS。一個好的配置管理工具應該具備這樣的功能：一是并行開發支持，要求能夠實現開發人員同時在同一個軟件模塊上工作，同時對同一個代碼部分作不同的修改，即使是跨地域分布的開發團隊也能互不干擾，協同工作，而又不失去控制。二是履歷管理，也就是修改的歷史記錄的可追蹤性。能夠明確地知道什么時候，誰作了什么，為什么怎么做。從而達到管理和追蹤開發過程中危害軟件質量以及影響開發周期的缺陷和變化。
結束語
最后，我建議對項目開發中容易出現的問題，項目組內部應該舉行技術交流講座。每一兩周搞一次內部的Tech Talk或者Chalk Talk。讓組員之間分享技術心得，這比花錢送到外面去培訓劃算。
在這次作為開發負責人中，我學習到在開發過程中必須處理好四個關鍵問題，這四個關鍵問題為：人員溝通、規范、測試、進度控制。只有嚴格把關，才可以大大提高軟件的質量。
