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