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