專案管理手記：迭代式開發進度控制(轉)

專案管理手記：迭代式開發進度控制
02年11月15日剛到公司2個月的我被軟體事業部老總T指定負責公司旗艦產品EC網路分銷系統開發的管理工作。

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

　　回顧5個月的產品專案進展，感受頗多，完完全全是一個困難一個困難解決，一步步走過來的。我以為軟體開發實踐中的經驗教訓、感受比抽象的專案管理理論更難得，特於專案空隙做此總結，希望與有志於企業級應用軟體產業化的諸位同道共享，交流提高。

　　計劃

　　計劃定義的是專案的目標是什麼，為什麼？在這個職能的執行中，專案開發組的任務、目標、具體目標和戰略被確定。

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

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

　　EC專案組組建僅僅3個月，人員背景基本分為兩部分：軟體開發、視覺設計。軟體實現業務以滿足下屬一IT硬體分銷企業為目標，該企業營運總監（MBA出身）負責與軟體事業部協調軟體開發，事實上該企業業務量暴漲，分銷渠道遍佈全國，迫切需要一套網路管理軟體。

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

　　應用“迭代式開發”，公司的產品戰略是可以通過N次迭代實現，問題是資本的耐心常常是有限的，產品經過趨向於無窮大的N次迭代肯定會日臻完美，但我們必須使資本在每次迭代中看到利潤。換句話說，產品的開發必須結合商業成功的良性迴圈中。

　　經過以上分析，我確定了專案組的產品目標：5個月完成軟體的1.0版本開發，7個月後完成該產品在公司下屬企業的上線執行。時刻謹記的核心任務是確保當前開發模式的可複製性和當前版本的可重用性，目前的工作是為了將來修改的簡易性。

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

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

　　組織

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

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

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

　　專案需求調研、分析階段，共有9人參加，編為三個小組分別同不同部門就不同業務內容展開交流，並完成業務活動分析。9人中的4人成為專案後續程式中的核心力量，積極參與完成了專案。

　　系統概要設計階段有6人蔘與，完成資料庫設計及介面風格、功能實現模式設計。詳細設計由4人專職進行，主要任務為頁面表現及功能邏輯設計，設計成果以WORD文件方式向頁面程式設計師與元件程式設計師下發。

　　程式碼實現包括元件程式碼編寫和前端頁面編寫、元件呼叫，6名程式設計師分為3個小組。

　　單元測試由2名測試人員（非專職測試）在專案後期逐步完成，系統聯調為專案組9人最終分擔測試完成。

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

　　激勵

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

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

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

　　我對需求分析階段的最終成果的定義是完成類似於SAP實施的業務藍圖，統一圖例。而此業務藍圖是在三天的小組成果報告會議中接受全體專案組成員質詢，討論通過。而此份業務藍圖經過修飾，格式規範，簡潔明瞭，轉呈營運總監簽字時獲得好評。最令大家得意的是，營運總監在大區會議上要求各大區經理規範業務時，就是拿著我們的業務藍圖在做演示。

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

　　領導

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

　　效能和成本永遠是一對矛盾，專案經理因此常常陷入兩難的境地，這種狀況下常常能體現出專案經理出色的對大小、輕重、緩急判斷的均衡感。決策能力來源於專案經理的實踐經驗，是管理者厚積薄發的功力體現。

　　對於第二項，人們最常說的是“領導是一門藝術”。藝術是發散的，與嚴謹的二進位制邏輯是格格不入的，這常常構成了程式設計師向管理方向發展的恐慌。雖然作為EC專案的主管對我來說是硬著頭皮上，但我始終是抱著學習的態度去面對困難，我一直的心態是“讓暴風雨來得更猛烈些吧！”。

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

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

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

　　控制

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

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

　　一、總體控制

　　 如前“計劃”中所述，專案程式安排兩次迭代，而每次迭代過程又包括需求分析、系統設計、程式碼實現、系統測試四個階段。

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

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

　　二、具體控制

　　軟體作為一種可以實際感受的產品，最終拿給使用者的必須是經過量化控制的。

　　就目前我們所能採用的手段來看，設計階段以前的定量控制是難以做到的，比如如何能定量考核設計是否契合需求？所以軟體的具體控制是從設計開始的，以設計為核心。

　　-設計文件必須詳盡，並且及時更新。

　　-根據設計文件發放工作單，確定完成時間。

　　-頁面功能測試和元件測試是依據完全最新的設計文件要求。根據設計文件對軟體的測試顯然是可以做到定量的。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7942439/viewspace-21361/，如需轉載，請註明出處，否則將追究法律責任。