項目管理手記：迭代式開發(fā)進度控制

02年11月15日剛到公司2個月的我被軟件事業(yè)部老總T指定負責公司旗艦產(chǎn)品EC網(wǎng)絡分銷系統(tǒng)開發(fā)的管理工作。

　　現(xiàn)在（03年4月1日）根據(jù)我的規(guī)劃，EC產(chǎn)品的1.0版本已經(jīng)進入測試階段，目前一切順利進行，老T對我們的工作成果很滿意。

　　回顧5個月的產(chǎn)品項目進展，感受頗多，完完全全是一個困難一個困難解決，一步步走過來的。我以為軟件開發(fā)實踐中的經(jīng)驗教訓、感受比抽象的項目管理理論更難得，特于項目空隙做此總結，希望與有志于企業(yè)級應用軟件產(chǎn)業(yè)化的諸位同道共享，交流提高。

　　計劃

　　計劃定義的是項目的目標是什么，為什么？在這個職能的執(zhí)行中，項目開發(fā)組的任務、目標、具體目標和戰(zhàn)略被確定。

　　即使在軟件開發(fā)領域之外，人們對于事物的處理總有慣用的思路。我的定式是：“我的目標是什么？我的起點是什么（包含擁有的資源）？從起點出發(fā)需要經(jīng)過哪些途徑可以達到目標？”這個自覺的思維模式非常有效，無論項目大小，它包含了樸素的管理思想。

　　公司資本雄厚，對于EC產(chǎn)品的戰(zhàn)略構想是，1為地域分散（可能是全球）的分銷企業(yè)提供提高業(yè)務管理效率的軟件產(chǎn)品；2該產(chǎn)品的應用是基于Internet；3該產(chǎn)品的應用部署問題及安全問題與專業(yè)廠商協(xié)作解決，產(chǎn)品的核心競爭力在于業(yè)務處理。

　　EC項目組組建僅僅3個月，人員背景基本分為兩部分：軟件開發(fā)、視覺設計。軟件實現(xiàn)業(yè)務以滿足下屬一IT硬件分銷企業(yè)為目標，該企業(yè)營運總監(jiān)（MBA出身）負責與軟件事業(yè)部協(xié)調軟件開發(fā)，事實上該企業(yè)業(yè)務量暴漲，分銷渠道遍布全國，迫切需要一套網(wǎng)絡管理軟件。

軟件工程的“迭代式開發(fā)”已經(jīng)逐漸取代“瀑布式開發(fā)”成為主流。所謂“迭代式開發(fā)”，根據(jù)我的理解說白了就是象愛因斯坦那樣做小板凳，終極的理想板凳就是不斷修正前面板凳錯誤的后一個板凳，“最好的是下一個”。“迭代式開發(fā)”與“瀑布式開發(fā)”存在本質的不同，傳統(tǒng)“瀑布式開發(fā)”的出發(fā)點是務求各個開發(fā)階段的成果都是最優(yōu)成果，無需變更。而“迭代式開發(fā)”則是假設各個階段的成果都有優(yōu)化、變更的余地。我們采取了“迭代式開發(fā)”，當前工作圍繞的核心是如何使未來的變更、優(yōu)化變得容易。

　　應用“迭代式開發(fā)”，公司的產(chǎn)品戰(zhàn)略是可以通過N次迭代實現(xiàn)，問題是資本的耐心常常是有限的，產(chǎn)品經(jīng)過趨向于無窮大的N次迭代肯定會日臻完美，但我們必須使資本在每次迭代中看到利潤。換句話說，產(chǎn)品的開發(fā)必須結合商業(yè)成功的良性循環(huán)中。

　　經(jīng)過以上分析，我確定了項目組的產(chǎn)品目標：5個月完成軟件的1.0版本開發(fā)，7個月后完成該產(chǎn)品在公司下屬企業(yè)的上線運行。時刻謹記的核心任務是確保當前開發(fā)模式的可復制性和當前版本的可重用性，目前的工作是為了將來修改的簡易性。

　　計劃上報后獲得通過，給項目組和客戶（下屬企業(yè)）都帶來了壓力，大家開始為共同的7個月的里程碑奮進。

　　7個月的時間內我們又細化為兩次迭代，每次的過程分為：需求分析、系統(tǒng)設計、代碼實現(xiàn)、系統(tǒng)測試。

　　組織

　　階段目標確定后，達到目標要完成的工作立即浮出水面，這樣依據(jù)任務安排工作，人員調配的問題很快迎刃而解。

　　“韓信用兵，多多益善”，根據(jù)我的計劃，項目組的人員配置應該是足夠的，可是經(jīng)過幾次人員安排的反復，我的結論是成功的關鍵并非兵精將廣，而是項目組的每個人都能各司其職，完成份內的工作。

　　項目組最多時參與的人員達到15人之多，但根據(jù)項目階段的需要、公司其他任務的安排以及IT企業(yè)員工的正常流動，每個階段參與項目的人員數(shù)目都不相同，但直至項目基本完成，團隊仍然保持著強勁的戰(zhàn)斗力，保持了正常的動態(tài)平衡，項目沒有因為人員問題影響進度。

　　項目需求調研、分析階段，共有9人參加，編為三個小組分別同不同部門就不同業(yè)務內容展開交流，并完成業(yè)務活動分析。9人中的4人成為項目后續(xù)進程中的核心力量，積極參與完成了項目。

　　系統(tǒng)概要設計階段有6人參與，完成數(shù)據(jù)庫設計及界面風格、功能實現(xiàn)模式設計。詳細設計由4人專職進行，主要任務為頁面表現(xiàn)及功能邏輯設計，設計成果以WORD文檔方式向頁面程序員與組件程序員下發(fā)。

　　代碼實現(xiàn)包括組件代碼編寫和前端頁面編寫、組件調用，6名程序員分為3個小組。

　　單元測試由2名測試人員（非專職測試）在項目后期逐步完成，系統(tǒng)聯(lián)調為項目組9人最終分擔測試完成。

　　人員組織中值得強調的經(jīng)驗是，“龍生九子，各不相同”，核心工作必須花大力氣安排項目核心人員完成。EC項目中人員分工非常精細，設計人員無須編碼，但他們的設計文檔極其詳盡，使編碼工作變得簡單、純粹，大大減輕了工作量。設計人員同時又是功能實現(xiàn)的原始驅動，他常常要牽頭主動與頁面人員、組件實現(xiàn)程序員協(xié)作溝通完成工作。

　　激勵

　　項目管理是軟科學，不是簡單依據(jù)前面生硬的“三段論”就可以順利把握，軟件開發(fā)活動必須有良性的反饋。隨著項目進程的展開，我琢磨出的經(jīng)驗是，階段目標要設立明確，階段成果要顯而易見，不能模糊、抽象、泛泛而談。這樣才能真正激發(fā)人們的成就感，加強完成項目的信心，使對軟件已完成部分的修正不至于寸步難行。

　　以需求分析階段舉例來說。

　　對定制型軟件來說，客戶需求調研、分析階段的工作事實上是極其難以把握的。需求分析太深入，時間耽誤太多影響后面工作，而且分析的結果還未必能用上，后期客戶需求的改變會令對前期分析工作自信滿滿的系統(tǒng)分析員吐血。需求分析太淺薄，自然后期工作捉襟見肘，不說人們也知道有多少壞處。

　　我對需求分析階段的最終成果的定義是完成類似于SAP實施的業(yè)務藍圖，統(tǒng)一圖例。而此業(yè)務藍圖是在三天的小組成果報告會議中接受全體項目組成員質詢，討論通過。而此份業(yè)務藍圖經(jīng)過修飾，格式規(guī)范，簡潔明了，轉呈營運總監(jiān)簽字時獲得好評。最令大家得意的是，營運總監(jiān)在大區(qū)會議上要求各大區(qū)經(jīng)理規(guī)范業(yè)務時，就是拿著我們的業(yè)務藍圖在做演示。

　　事實上，需求分析的真正成果是大家都成為某方面的“業(yè)務專家”，成為項目中活躍的一份子，能夠積極從客戶的角度參與后來的項目溝通。

　　領導

　　項目管理者必須完成領導的職責，我對此的理解是：1決策；2保證決策意圖的順利執(zhí)行。

　　性能和成本永遠是一對矛盾，項目經(jīng)理因此常常陷入兩難的境地，這種狀況下常常能體現(xiàn)出項目經(jīng)理出色的對大小、輕重、緩急判斷的均衡感。決策能力來源于項目經(jīng)理的實踐經(jīng)驗，是管理者厚積薄發(fā)的功力體現(xiàn)。

　　對于第二項，人們最常說的是“領導是一門藝術”。藝術是發(fā)散的，與嚴謹?shù)亩M制邏輯是格格不入的，這常常構成了程序員向管理方向發(fā)展的恐慌。雖然作為EC項目的主管對我來說是硬著頭皮上，但我始終是抱著學習的態(tài)度去面對困難，我一直的心態(tài)是“讓暴風雨來得更猛烈些吧！”。

　　以我的經(jīng)驗來看，作為項目經(jīng)理，一個半年的項目下來不吵個20、30架是不稱職的，說明項目的溝通存在極大的問題。我沒有天生的領導魅力，依靠的只是自己琢磨的兩件法寶：1坦誠對待工作上的溝通；2任務本位，區(qū)別于官本位。

　　坦誠就是管理過程中坦率指出別人錯誤，同時也準備讓別人指出自己的錯誤。這是解決問題變得簡單，在項目組中一旦形成傳統(tǒng)，大大有益于項目的進行。

　　我始終沒有試過威勢壓人、軟硬兼施的領導手段，對其效果難以提出中肯的意見。我覺得交流的目的只是解決一個具體的問題時，交流就會變得簡單，當然，經(jīng)過開始階段的磨合，我認識到立刻要求別人和自己的思路合拍是不現(xiàn)實的，作為管理者應當寬容。

　　控制

　　軟件開發(fā)項目的管理在我看來是一個比較復雜的領域，它的控制包含了定性和定量的成份，同時項目進程中特有的、大幅度的迭代構成了軟件項目復雜性的另一個因素，即所謂的需求變化導致設計、代碼變化。

　　如何能按期、按計劃完成EC項目，一直是我考慮的重點。宏觀地看，我在項目管理中自覺地用了兩級控制。

　　一、總體控制

　　如前“計劃”中所述，項目進程安排兩次迭代，而每次迭代過程又包括需求分析、系統(tǒng)設計、代碼實現(xiàn)、系統(tǒng)測試四個階段。

　　總體控制的目標基本是大目標，采取定性控制的方法。但要說明的是，雖然需要達到的目標是定性的，但階段成果的體現(xiàn)是具體的、明確的。

　　比如需求分析階段，完成的階段性成果業(yè)務藍圖所描述的業(yè)務范圍、業(yè)務深度是很難量化要求的，但業(yè)務藍圖本身的表達規(guī)范、“人人都是業(yè)務專家”的要求又是具體的。

　　二、具體控制

　　軟件作為一種可以實際感受的產(chǎn)品，最終拿給用戶的必須是經(jīng)過量化控制的。