二、啟動階段

　　1.項目的一些基本概念

　　項目三要素有多種版本，各不相同。實際操作中多分為范圍，成本與進度，其中最重要的莫過於范圍。我們把項目最終生成並提交給用戶的產品和文檔統稱為遞交件。談判的時候一定要確立遞交件的和要求，也就是范圍。盡管商戰的時候不可避免的客戶會不斷提高標准和要求，而承諾的款項卻不會有一分錢的增加。但是這個標准對每個公司來說都有一個底線，一旦超過了這個底線，那項目就肯定是虧的。除非是為了二期有利可圖或者是為了搞好關系，否則范圍超過底線的時候情願不做，再厲害的PM在這種情況下也是無能為力。建立范圍需要的就是PM的多年的實戰經驗，在大大小小的項目中用血淚換來的一些體會。在這個時候，很能體現 PM與技術人員的區別。成本就是客戶答應付的款項，與我們的投入成本並不是一回事情。進度就不用多描述了。

　　項目如何成功？也有一些關鍵的因素。個人的理解也不盡相同，通常包括以下幾個方面：界定工作目標及工作任務；老板或高層的支持；優秀的PM和開發團隊；充足的資源；良好的溝通；對客戶的積極反應以及適當的監控和反饋。這裡要注意的就是資源和高層的支持。一個上規模的公司總是同時會有很多項目，可是再大規模的公司資源也不足以保證每個項目都能組建最合適的開發隊伍或擁有最好的環境。這時候各個團隊或者部門之間不可避免的會發生資源爭奪戰，摩擦再所難免。這時候對PM的作人再次提出挑戰。除了高層對PM項目的重視程度，如果PM平時在公司與同事相處的好往往能使很多別人看起來很棘手的問題迎刃而解。相反，一個不會作人的PM由於人緣差，即使高層強壓別的部門或團隊配合，別人也會能拖就拖，延緩項目的進度和質量。有時候，這種內耗對項目和PM來說是毀滅性的。對客戶的積極反應也比較關鍵。一般來說PM已經被項目裡大大小小的事情搞的筋疲力盡，要PM去主動要求客戶配合是很吃力的事情。然而，這個時候，越是困難，越是覺得累，越是要去主動。客戶往往也不是特別的積極，主動與客戶聯系溝通和測試能及早發現問題。從風險控制的角度來說，問題發現的越早，風險越小，損失也就越小。積極的態度可以帶動客戶的積極性，在項目完工的時候，客戶對你的感激往往是難以用語言描述的，這對以後接單或者做二期三期會打下良好的基礎。因為在和別的新客戶談判的時候，新客戶自然會找你的老客戶了解情況，這時老客戶隨意的一句話頂的上你很費心的十句。

　　項目具有商業行為的幾個重要特征，有消費源，有參與者，有成功關鍵因素，有財務目標，有風險。

　　2.啟動階段的主要任務

　　根據PMI的解釋，接單之後項目自然轉入啟動階段。啟動階段PM的主要任務是率領總體架構設計師和系統分析員收集盡可能詳細的數據，確立盡可能詳細的需求，進一步確立詳細的項目范圍，預估資源，確立其他方案並獲得進入下一階段的批准。在這個階段，隨著需求分析的深入，PM也開始在公司內部進行人員挑選和資源爭奪，著手組建自己的項目團隊。項目即將進入計劃階段。

　　在收集完數據之後，PM要和客戶開始明確項目的大小，成本，規格，期限等重要特征並將其寫入文本，同時准備內部的包括預算，衡量標准等文檔，建立項目的評估標准。接下來就是需求分析。由於專業的原因，我們這裡僅討論軟件工程項目的需求分析（以下簡稱需求分析）。需求分析的主要參與人員有PM，總體架構設計師，系統分析員，熟悉業務流程的客戶。PM統領的團隊這時候還不是真正的開發團隊，我們叫做前期團隊。隨著需求分析的逐步深入，新的團隊成員不斷加入，啟動階段結束的時候正式的團隊將建立。對一個已經啟動的項目來說，需求分析直接決定了項目的成功與失敗。最初的需求體現在客戶的工作說明書或招標文件及附件上。這種需求一般比較含糊，無法體現客戶真正的需求。前期團隊要根據自己的經驗和客戶溝通並引導客戶進入正軌。有時候客戶會很不講道理或者思路僵化，就要求按照他的思維去定一些明顯錯誤的需求。這個時候團隊成員要耐心和客戶舉事實，談經驗，講道理，用圖形或模型等直觀的方式將需求描述出來，比如常見的數據流圖等。所以說，爭論再所難免，客戶有時候會吹胡子瞪眼睛拍桌子甚至會說“這個東西不要你們做了”之類的話。PM此時除了要親身參與需求分析綜合整理文檔之外，還要處理好團隊成員與客戶的關系，確保關系不會惡化到無法收拾的地步。只要PM盡力約束團隊中的成員，這個度還是很容易控制的。

　　對快速開發和疊代開發來說，需求和實現往往是同步進行，開發速度快是一大優勢。對有相同或類似模式的小項目來說采用快速開發或疊代開發是很合算的做法，時下流行的極限編程就是針對這方面建立的思維模式。然而，大中型項目中有太多不一樣的需求和模塊。如果不是因為項目有差異，那麼市場上就只有產品而沒有項目了。所以，大中型項目的需求要認真仔細的去做。我們要討論一個問題，究竟應該在需求分析和總體設計上花費多少時間？我們熟悉的瀑布開發模式基本上分需求分析，總體設計，軟件開發，測試等幾個階段，然而究竟應該在前兩個階段上花多少時間卻沒有定論。實際項目操作的例子表明，分析設計的時間越長，需求設計做的越詳細，測試的時間就越短，返工率越低，風險也越小，成本越容易得到控制。

　　而需求分析和總體設計沒有做好就急忙上馬進行開發的項目在項目初期進展順利的時候問題不大，到了項目後期和測試階段一些潛伏期比較長但是破壞作用比較大的問題就會凸顯出來，造成返工，延長測試時間。所以與其把問題堆積到緊張的項目後期，不如把時間多花點到需求分析和總體設計上。基礎夯實了，金字塔就容易造了。在日本公司打工的程序員們可能都知道，小日本的軟件非常厲害，他們花在需求分析和總體設計上的時間通常在40%到50%左右，遠遠超過國內軟件項目的實施，效果也要強的多。他們總體設計的規范甚至詳盡到某個過程該如何判斷，確立什麼樣的條件，換言之就是把什麼時候該如何寫（if……else）語句都幫程序員定好了。在這樣的軟件規范下，程序員更象是裝配流水線上的工人，對一個模塊或技術熟悉到一定程序就變成了完全的重復性勞動。所以在日本和歐美經常會有程序員是低級工作一說，很多人不明就裡，對國內程序員也照搬，對國內的程序員來說是很不公平的。在國內，只會照抄別人代碼，一點都不懂創新，凡事依靠別人，快下班就盯著表看的程序員是不少，這種人一般很難有什麼前途。但是，優秀的不斷進取的程序員也很多。由於國內沒有象CMM這樣的軟件規范或者很少，所以這類優秀的程序員不少都是干著系統分析員甚至PM的活，拿著程序員的工資。這類程序員雖然在起步時會吃很多虧，而且是主動找虧吃，然而幾年之後與前一種程序員的社會地位會出現明顯的分化。當上進的程序員們作為PM進行商務談判的時候，前者還在各個公司裡頻繁跳槽，跳來跳去都不滿意。有些扯開了，回到我們的話題。

　　日本的軟件規范與CMM有驚人的相似，其中至少有35%以上都是幾乎一模一樣的。最近經濟不景氣，東京倒閉了160家軟件公司，這個數字是今年6月份的，還在不斷增加。這些公司紛紛搶灘上海，招收技術人員。如果去這樣的公司應聘就要考慮清楚了，進去可以學到他們的規范和質量控制，可是要想從程序員成為系統分析員或PM，比登天還難。往往一個程序員進去干了好幾年，對自己的那一塊熟的不得了，而對隔壁同事所做的東西一竅不通。拒傳華為正在嘗試CMM4（華為印度研究所已經通過CMM4），對在華為工作的程序員們來說可謂福禍難料。當然，已經作到PM或QA或者熱愛CODING的朋友例外。需求分析本身也存在著時間分配的問題。第一遍需求分析花的時間會最長，分析員們在客戶的各個部門之間幾乎把腿都跑斷，把口水說干，就是為了確立一個初期的需求模型。所有的文檔將會提交給PM進行復審並簽字，不合格的打回重做。反饋表隨之將提交給客戶，第二遍第三遍等等等等接踵而來，與客戶反復討論和磋商，反復提交文檔和，目的只有一個，明確需求。當PM最終合並了所有文檔並確立需求之後，最終生成的需求文檔將提交給客戶的各部門負責人簽字。這些文檔將作為合同的附件添加，以便在將來項目變更或者碰到重大問題時和客戶扯皮的重要依據。

　　需要說明的是，客戶並非都是蠻不講理，但是說實話，頗有無奈，國內目前的項目大多數客戶為了不讓自己的錢白花，經常變著法子提需求。在啟動階段明確需求並簽字，無論最終情況如何，一份詳盡的書面文檔可以解決很多口頭承諾或概念模糊的文檔帶來的許多問題。詳盡的需求分析有一個額外的好處就是對一些雙方都很陌生或者從來無人嘗試的領域將是一個決定是否進行項目的判斷標准。有時候，這種大項目在簽單時雙方都沒有絕對把握保證可以出成果，一旦在需求分析階段發現難以逾越的技術難關，就會放棄項目。典型的例子就是NMD洲際導彈防御系統。上世紀八十年代初美國搞星球大戰計劃，拖跨了蘇聯。大家對那段歷史有些含糊，很多人認為蘇聯人上了美國的當。其實並不完全如此，蘇聯人的情報機構無孔不入，並非那麼容易上當受騙。實際上當時美國國防部已經開始著手NMD系統軟件的需求分析，前後耗資數億美圓，耗時兩年，僅僅是做需求分析，終於發現存在著在當時技術上無法達到的高度，隨後項目被放棄。

　　3.項目啟動

　　項目啟動要確定項目計劃，與客戶一起實施第一次項目審核，確認並對一些產品和服務向下包廠商下訂單。這個時候的PM會忽然發現有開不完的會，一天開三到四個會議是很正常的事情。這些會議有與客戶的會議，與下包廠商的，有團隊的，有公司高層的。團隊的會議主要是建立正式的團隊，提供團隊成員的角色和職責，提供績效管理方法，向成員提供項目范圍和目標。與客戶的一個主要會議將是項目啟動會議。在這個會議上PM會與客戶確立正式的交流渠道，項目綜合描述，讓項目參與人員相互了解，建立以PM為核心的管理制度。還有一些零零碎碎的東西甚至包括辦公場地的大小，電話多少部，所有人的聯系方式等等都要在會議上確立，並做會議記錄。這都是些非常瑣碎的事情，卻是非常必要，缺一不可。大概就是所謂三軍未動，糧草先行吧。

　　這時候，作為公司高層，應該向全公司發表申明，正式給PM發布項目經理任命書和項目授權書。這個動作雖然在別人看來有些形式主義，但是對提高PM本人的士氣和責任感是有很大助力的。