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

1、項目管理手記：迭代式開發(fā)進度控制02年11月15日剛到公司2個月的我被軟件事業(yè)部老總T指定負責公司旗艦產 品EC網絡分銷系統(tǒng)開發(fā)的管理工作?，F(xiàn)在（03年4月1日）根據(jù)我的規(guī)劃，EC產品的1.0版本已經進入測試階 段，目前一切順利進行，老T對我們的工作成果很滿意?；仡?個月的產品項目進展，感受頗多，完完全全是一個困難一個困難解決， 一步步走過來的。我以為軟件開發(fā)實踐中的經驗教訓、感受比抽象的項目管理理 論更難得，特于項目空隙做此總結，希望與有志于企業(yè)級應用軟件產業(yè)化的諸位 同道共享，交流提高。計劃計劃定義的是項目的目標是什么，為什么？在這個職能的執(zhí)行中，項目開發(fā) 組的任務、目標、具體目標和戰(zhàn)略被

2、確定。即使在軟件開發(fā)領域之外，人們對于事物的處理總有慣用的思路。我的定式 是：“我的目標是什么？我的起點是什么（包含擁有的資源）？從起點出發(fā)需要 經過哪些途徑可以達到目標？”這個自覺的思維模式非常有效，無論項目大小， 它包含了樸素的管理思想。公司資本雄厚，對于EC產品的戰(zhàn)略構想是，1為地域分散（可能是全球） 的分銷企業(yè)提供提高業(yè)務管理效率的軟件產品；2該產品的應用是基于Internet ；3該產品的應用部署問題及安全問題與專業(yè)廠商協(xié)作解決，產品的核心競爭力在 于業(yè)務處理。EC項目組組建僅僅3個月，人員背景基本分為兩部分：軟件開發(fā)、視覺設 計。軟件實現(xiàn)業(yè)務以滿足下屬一 IT硬件分銷企業(yè)為目標，該

3、企業(yè)營運總監(jiān)（MBA 出身）負責與軟件事業(yè)部協(xié)調軟件開發(fā)，事實上該企業(yè)業(yè)務量暴漲，分銷渠道遍 布全國，迫切需要一套網絡管理軟件。軟件工程的“迭代式開發(fā)”已經逐漸取代“瀑布式開發(fā)”成為主流。所謂“迭代 式開發(fā)”，根據(jù)我的理解說白了就是象愛因斯坦那樣做小板凳，終極的理想板凳 就是不斷修正前面板凳錯誤的后一個板凳，“最好的是下一個”。“迭代式開發(fā)” 與“瀑布式開發(fā)”存在本質的不同，傳統(tǒng)“瀑布式開發(fā)”的出發(fā)點是務求各個開 發(fā)階段的成果都是最優(yōu)成果，無需變更。而“迭代式開發(fā)”則是假設各個階段的 成果都有優(yōu)化、變更的余地。我們采取了 “迭代式開發(fā)”，當前工作圍繞的核心 是如何使未來的變更、優(yōu)化變得容易。應

4、用“迭代式開發(fā)”，公司的產品戰(zhàn)略是可以通過N次迭代實現(xiàn)，問題是資 本的耐心常常是有限的，產品經過趨向于無窮大的N次迭代肯定會日臻完美，但 我們必須使資本在每次迭代中看到利潤。換句話說，產品的開發(fā)必須結合商業(yè)成 功的良性循環(huán)中。經過以上分析，我確定了項目組的產品目標：5個月完成軟件的1.0版本開 發(fā)，7個月后完成該產品在公司下屬企業(yè)的上線運行。時刻謹記的核心任務是確保當前開發(fā)模式的可復制性和當前版本的可重用，性，目前的工作是為了將來修改 的簡易，性。計劃上報后獲得通過，給項目組和客戶（下屬企業(yè)）都帶來了壓力，大家開 始為共同的7個月的里程碑奮進。7個月的時間內我們又細化為兩次迭代，每次的過程分為

5、：需求分析、系統(tǒng) 設計、代碼實現(xiàn)、系統(tǒng)測試。組織階段目標確定后，達到目標要完成的工作立即浮出水面，這樣依據(jù)任務安排 工作，人員調配的問題很快迎刃而解?！绊n信用兵，多多益善”，根據(jù)我的計劃，項目組的人員配置應該是足夠的， 可是經過幾次人員安排的反復，我的結論是成功的關鍵并非兵精將廣，而是項目 組的每個人都能各司其職，完成份內的工作。項目組最多時參與的人員達到15人之多，但根據(jù)項目階段的需要、公司其 他任務的安排以及IT企業(yè)員工的正常流動，每個階段參與項目的人員數(shù)目都不 相同，但直至項目基本完成，團隊仍然保持著強勁的戰(zhàn)斗力，保持了正常的動態(tài) 平衡，項目沒有因為人員問題影響進度。項目需求調研、分析階

6、段，共有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人最終分擔測試完成。人員組織中值得強調的經驗是，“龍生九子，各不相同”，核心工作必須花 大力氣安排項目核

7、心人員完成。EC項目中人員分工非常精細，設計人員無須編 碼，但他們的設計文檔極其詳盡，使編碼工作變得簡單、純粹，大大減輕了工作 量。設計人員同時又是功能實現(xiàn)的原始驅動，他常常要牽頭主動與頁面人員、組 件實現(xiàn)程序員協(xié)作溝通完成工作。激勵項目管理是軟科學，不是簡單依據(jù)前面生硬的“三段論”就可以順利把握， 軟件開發(fā)活動必須有良性的反饋。隨著項目進程的展開，我琢磨出的經驗是，階 段目標要設立明確，階段成果要顯而易見，不能模糊、抽象、泛泛而談。這樣才 能真正激發(fā)人們的成就感，加強完成項目的信心，使對軟件已完成部分的修正不 至于寸步難行。以需求分析階段舉例來說。對定制型軟件來說，客戶需求調研、分析階段的工

8、作事實上是極其難以把握 的。需求分析太深入，時間耽誤太多影響后面工作，而且分析的結果還未必能用 上，后期客戶需求的改變會令對前期分析工作自信滿滿的系統(tǒng)分析員吐血。需求 分析太淺薄，自然后期工作捉襟見肘，不說人們也知道有多少壞處。我對需求分析階段的最終成果的定義是完成類似于SAP實施的業(yè)務藍圖，統(tǒng) 一圖例。而此業(yè)務藍圖是在三天的小組成果報告會議中接受全體項目組成員質詢， 討論通過。而此份業(yè)務藍圖經過修飾，格式規(guī)范，簡潔明了，轉呈營運總監(jiān)簽字 時獲得好評。最令大家得意的是，營運總監(jiān)在大區(qū)會議上要求各大區(qū)經理規(guī)范業(yè) 務時，就是拿著我們的業(yè)務藍圖在做演示。事實上，需求分析的真正成果是大家都成為某方面的

9、“業(yè)務專家”，成為項 目中活躍的一份子，能夠積極從客戶的角度參與后來的項目溝通。領導項目管理者必須完成領導的職責，我對此的理解是：1決策；2保證決策意 圖的順利執(zhí)行。性能和成本永遠是一對矛盾，項目經理因此常常陷入兩難的境地，這種狀況 下常常能體現(xiàn)出項目經理出色的對大小、輕重、緩急判斷的均衡感。決策能力來 源于項目經理的實踐經驗，是管理者厚積薄發(fā)的功力體現(xiàn)。對于第二項，人們最常說的是“領導是一門藝術”。藝術是發(fā)散的，與嚴謹 的二進制邏輯是格格不入的，這常常構成了程序員向管理方向發(fā)展的恐慌。雖然作為EC項目的主管對我來說是硬著頭皮上，但我始終是抱著學習的態(tài)度去面對 困難，我一直的心態(tài)是“讓暴風雨來

10、得更猛烈些吧！”。以我的經驗來看，作為項目經理，一個半年的項目下來不吵個20、30架是 不稱職的，說明項目的溝通存在極大的問題。我沒有天生的領導魅力，依靠的只 是自己琢磨的兩件法寶：1坦誠對待工作上的溝通；2任務本位，區(qū)別于官本位。坦誠就是管理過程中坦率指出別人錯誤，同時也準備讓別人指出自己的錯誤。 這是解決問題變得簡單，在項目組中一旦形成傳統(tǒng)，大大有益于項目的進行。我始終沒有試過威勢壓人、軟硬兼施的領導手段，對其效果難以提出中肯的 意見。我覺得交流的目的只是解決一個具體的問題時，交流就會變得簡單，當然， 經過開始階段的磨合，我認識到立刻要求別人和自己的思路合拍是不現(xiàn)實的，作 為管理者應當寬容

11、?？刂栖浖_發(fā)項目的管理在我看來是一個比較復雜的領域，它的控制包含了定性 和定量的成份，同時項目進程中特有的、大幅度的迭代構成了軟件項目復雜性的 另一個因素，即所謂的需求變化導致設計、代碼變化。如何能按期、按計劃完成EC項目，一直是我考慮的重點。宏觀地看，我在 項目管理中自覺地用了兩級控制。一、總體控制如前“計劃”中所述，項目進程安排兩次迭代，而每次迭代過程又包括需 求分析、系統(tǒng)設計、代碼實現(xiàn)、系統(tǒng)測試四個階段。總體控制的目標基本是大目標，采取定性控制的方法。但要說明的是，雖然 需要達到的目標是定性的，但階段成果的體現(xiàn)是具體的、明確的。比如需求分析階段，完成的階段性成果業(yè)務藍圖所描述的業(yè)務范圍、業(yè)務深 度是很難量化要求的，但業(yè)務藍圖本身的表達規(guī)范、“人人都是業(yè)務專家”的要 求又是具體的。二、具體控制軟件作為一種可以實際感受的產品，最終拿給用戶