一、 干系人分析應該怎么做
不少剛從技術人員提升成為項目經理的員工經常面對項目中無窮無盡的溝通和注意事項感到筋疲力盡，以前也有同事對我說，“老大，我是不是不太適合項目經理這個崗位，現在感覺還不如做開發人員的時候開心。”我當時除了勉勵他，教他一些項目管理的方法，支持他并給你提供更好的資源，也為他做了一些項目上針對性的分析，現在看來，初次當上項目經理的同事，即使經過項目經理的簡單培訓，仍然對項目管理抓不住重點。
第一課，項目干系人分析，是所有項目經理的必修之道，好比練功，這是基礎中的基礎，馬步站樁雖然不及拳腳好看，可這是夯實你項目成功重要的一步，而且在整個項目管理過程中，還要經常回顧和分析，好像陳氏太極大師陳王廷，每天還堅持站樁。而這個干系人分析在教科書上說得太理論化，我用實例來說說干系人分析應該怎么做。
項目干系人，軟考中參考書籍上有解釋：項目干系人又稱為項目相關利益者，是指積極參與項目、或其利益會受到項目執行或完成情況影響的個人或組織。項目干系人對項目的目的和結果施加影響。項目管理團隊必須識別項目干系人，確定他們的需求和期望，盡大可能地管理與需求相關的影響，以獲得項目的成功。
上面是書面解釋，實際過程我舉個活生生的例子：某公司A的系統集成項目，客戶信息中心主任與該公司的關系很好，而這家公司A通過努力也順利的中標，并開始組建項目小組，分配資源，準備實施，公司派了一位技術經驗豐富的工程師小張作為本項目的項目經理，因為這個項目需要同時與客戶、軟件廠家、硬件廠家、公司技術支持人員（不屬于此項目小組）進行溝通，按公司項目管理規定，小張首先拿出了《項目章程》，按以前其它項目的模板照貓畫虎完成了，在干系人分析時，只是簡單的羅列了相關的客戶方成員信息、廠家信息、和小組成員及技術支持人員信息，簡單的說，是只做了個通訊錄。
各位可能會說，這樣很不錯了啊，我們來看看這個項目章程中的干系人這一節的截圖
大家看到了，算是個通迅錄，也還缺少相應人員的郵箱，問個對方的郵箱不是難事，可這個項目經理小張可能忽略了，重要的是，他沒有做相應的干系人利益分析。
作為項目干系人分析的第一步，需要先仔細識別出本項目的全部干系人。項目經理需要對項目干系人有一個全面的了解，在心中有一張完整的項目干系人結構圖，以后無論是啟動、計劃還是執行、問題處理和收尾，都需要系統全局地思考問題，切忌頭痛醫頭、腳痛醫腳。
在項目干系人識別中，對客戶方項目干系人的識別和分析更是重中之重，在本文中將重點集中在對客戶方干系人做重點分析。通過對上面案例分析，可以畫出一張客戶方項目干系人結構圖，打比方說這個客戶中所有干系人的情況如下圖所示
在識別出項目干系人之后，還需要分析干系人之間的關系和歷史淵源，如果不做這進一步的分析，會在項目過程中遇到不小的麻煩。比如在上述案例中，信息中心主任和公司A的關系很融洽，有多年的合作關系，且相互間合作很愉快，這個主任屬于集團的行政副總分管，和副總的私人關系也還不錯，地位比較穩定。而財務部經理雖然也屬于同一個副總分管，可他希望這個系統由公司A的競爭對手Z公司來做，因為這是平臺化項目，一旦開始，后期還有源源不斷的項目可以開展，但Z公司在競標過程中被淘汰，讓財務部經理心里很不滿意，很擔心這個整合項目一旦由信息中心主任做成功了，Z公司從此沒辦法再拿到后續的項目，從心理上希望項目做不好，從行動上也倚仗自己是企業的核心部門處處對項目設置障礙（不管怎么說財務的地位在大部分企業里面是高于信息部門的，除非本身是IT公司，呵呵）。財務經理手下的人對系統整合也不太支持，認為不僅剝奪了自己本部門系統的建設權，而且以后業務運作都處在領導監控之下，自然不怎么好好配合項目了。
通過以上對干系人的識別和初步分析，我們可以看出，如果不能對項目干系人進行無遺漏地識別，僅僅關注項目具體事情和計劃，項目出了問題可能都不清楚問題出在哪里了。項目干系人結構圖為項目經理描繪了客戶方項目干系人的全景，為進一步對干系人進行分析，為更好地把握項目管理打下了一個很好的基礎。
在中國做事情，有時候是做事，有時候是做人，事情做好了，人沒有做好，項目失敗的案例比比皆是，在這里，我不是說項目經理要練的跟銷售經理一樣油嘴滑舌，算你練到這樣了，客戶反而認為你這項目經理靠不住，畢竟項目經理是需要技術底蘊獲得客戶信任的。那么，有個朋友說“這項目經理太難了，裝孫子也不是，裝大爺更不行，怎一個?字了得！”我說，你沒有抓住人心的本質，你要比客戶更專業，讓他信服你的技術能力比他更，他不會給你不尊重或亂指揮。客戶很多時候亂指揮，是因為我們沒有讓他信服的技術能力和對客戶業務的理解能力，所以造成客戶親自操刀，上陣指揮，各位初哥項目經理們捫心自問，你如果是客戶，你是希望對方的項目經理幫你一桿進洞干凈解決問題呢，還是希望親自上場導致令出多門以慘敗收場呢？
當然，項目中不可能這樣完美，我們做項目的時候，能力不可能在每個方面都比客戶強，所以需要我們去和客戶真誠的交流，中國人講究個面子，你夸他幾句，說他是業務方面的專家，給對方一個高帽的同時也表明了你在技術上比他更專業，大家配合做事才可能成功，技術上的事我說了算，業務上的需求我們來一起協商，私底下，把客戶當朋友，請吃個飯，聊些他喜歡的話題，拉進一下距離，送一些對他胃口的小禮物，都是必要的，大家不要做技術做單純了，做的人情世故都不懂了，那是技術人員的大悲哀了，畢竟，人是感情的動物，你不可能要求別人都和程序員一樣，不是1是0，不是黑是白，項目中的干系人分析來分析去，落腳點是兩個字“利益”。
象上面的例子，怎么對付這個財務經理，很簡單，首先這個項目經理應該對客戶的每個干系人在現場都拜訪一遍，把公司的榮譽和資料介紹給那些不了解公司的干系人，讓他們了解公司的實力。再則根據合同，把需求整理好并與客戶簽字，了解這個項目中可能影響這個財務經理意志的干系人（譬如行政副總或他手下的財務主管位）在意的利益所在（譬如數據要順利遷移、要保證切換后的系統穩定等），當財務經理來刁難的時候，根據雙方確認的需求和合同，不在這個范圍內的，找項目負責人信息中心主任確認，遇到要到老總那里打官司的，提前和信息中心主任對好說辭，并定期向分管副總和財務經理匯報進展，這樣可以把很多問題解決在萌芽狀態。
項目經理的第一課，是具有中國特色的干系人利益分析法。
二、項目章程如何寫
按照項目過程管理的教科書的要求，任何項目上來，除開前期的項目調研外，項目章程是一個必不可少的項目整體管理的組成部分。
看看書面解釋“項目章程是正式批準一個項目的文檔。項目章程要么由項目組織以外的發起人或資助人發布，要么由組織內某個級別的管理層發布，以便為該項目提供所需的資金。項目章程對項目經理進行了授權，以便他可以使用組織資源執行項目，應該盡可能在項目的早期確定并任命項目經理。”
其實這段話和所有教科書一樣，是建立在完美資源和充分條件的基礎上的，在目前國內的實際環境中，一個項目的發起往往是幾個主要決策人拍板決定的，有一個過得去的炒了不知道幾遍的調研分析報告，把合同約定了，有的甚至在沒有簽定合同的前提下，開始組建項目團隊。在項目章程確定上，不能盡信書也不能無書。
項目章程的在教科書上約定的輸入條件、分析工具如下：
| 輸入 | 工具與技術 |
| 合同 | 項目選擇方法 |
| 工作說明書 | 項目管理方法 |
| 企業環境因素 | 項目信息系統 |
| 組織過程資產 | 專家判斷 |
以上內容不太明確的，可以參考清華大學的《信息系統項目管理師教程》的第84-86頁的內容。
但是的重點不在這些，我想說的是象我們這樣的小公司，如何用淺顯易懂的方法理清項目章程，讓項目章程成為軟件開發中的整體過程管理中的標桿文檔，為項目管理提供提綱挈領的作用。
我認為，項目章程在國內的小公司只需要抓住如下重點：
一、項目名稱、項目立項時間、項目小組成立時間、立項調研文檔出處。
大家不要小看上面四項，有很多公司的項目，項目小組內部對項目的名稱叫法都統一不了，這樣的素質怎么能讓客戶放心。
二、客戶描述
這個客戶描述是比較有學問的，一要描述客戶的企業背景，二要描述客戶的組織結構圖，三要描述客戶目前項目小組方的主要成員的姓名、聯系方式。另外，要對客戶在項目中的溝通方式做個簡單描述，譬如客戶中誰看迭代版本，誰看進度報告，誰看測試報告等，有的項目比較小，不用做項目溝通計劃的時候，可以依照這個溝通方式來執行。
三、項目組及職能描述
這節要分為兩部分，一是描述開發方項目小組的主要成員、職務、聯系方式；二要描述項目小組的職能矩陣，具體描述如下所示：
|
序號
|
工作單元
|
高xx
|
歐陽x
|
張xx
|
趙xx
|
譚xx
|
|
1
|
需求調研
|
D
|
d
|
d
|
d
|
|
|
2
|
需求分析
|
D
|
D
|
D
|
D
|
|
|
3
|
項目溝通
|
D
|
d
|
d
|
d
|
x
|
|
4
|
工作計劃分解
|
D
|
d
|
d
|
d
|
x
|
|
5
|
編碼實現
|
d
|
D
|
D
|
D
|
|
|
6
|
架構實現
|
D
|
D
|
D
|
D
|
|
|
7
|
單元測試
|
|
D
|
D
|
D
|
|
|
8
|
黑盒測試
|
|
d
|
d
|
d
|
|
|
9
|
用例測試
|
|
d
|
d
|
d
|
|
|
10
|
集成測試
|
D
|
d
|
d
|
d
|
|
|
11
|
上線實施
|
D
|
d
|
d
|
d
|
|
|
12
|
用戶培訓
|
|
d
|
d
|
d
|
d
|
D 重要決策者 d 參與決策者 x 執行者
四、項目遠景
項目遠景包含以下內容：
項目目標
功能范圍目標
項目管理目標
組織目標
項目目標：師出必有名，做一個項目，必須讓項目組成員明白這個項目是要實現什么目的，這個項目遠景是項目要達成的目標，譬如下面這句話：此項目是為完成客戶總部生產技術部實驗系統的無紙化管理，將以前手工登記的試驗計劃、試驗結果評定、試驗標準對比等紙張數據由計算機系統進行統一管理。這段描述是指的項目的完成目標。
功能范圍目標：如果在項目成立之初了解更多的項目需求和信息，甚至還可以擴展寫下諸如項目的功能范圍目標（譬如要完成和實現哪些范圍的功能），這個功能范圍有別于具體的功能列表，可以說是項目的功能邊界的描述，如果有《項目范圍說明書》，那這里的功能范圍目標要保持前后一致，實際上《項目章程》也是《項目范圍說明書》的必要輸入條件之一。
項目管理目標：我們都知道項目管理的鐵三角（成本、質量、進度），也有人說項目管理有金四角（成本、質量、進度、功能），鉆石五角（成本、質量、進度、功能、發展）等等（見張傳波的UML視頻），其實不管怎么解釋，對各類中小型軟件企業來說，首先要完成的是項目的目標本身，其次才是擴展項目的管理目標，這是一個漸進的目標層次。在這里，應該盡量量化項目的管理目標，而不要模糊化，因為目前國內的項目經理的能力普遍參差不齊的前提下，要通過短短的幾次培訓讓他們明白何為項目管理太難了，還不如明確的告訴本次項目要完成的項目管理目標，譬如：在項目終版本交付時，level300以上的bug數為零；項目章程中各項規定的文檔提交齊全并通過外審和內審；項目總結時按期提交知識共享文章等等。項目管理目標是在完成項目目標并按約束條件驗收（后面論述）的前提下，完成軟件開發企業對項目管理過程提升和總結歸納的要求。說白了，在國內目前的情況下，很多中小型公司都要完成從項目到產品或解決方案的轉變，否則項目做完了，企業也無米下鍋了。
組織目標：組織目標和項目管理目標不同，項目管理目標是在項目管理過程中進行明確的要求，而組織目標則是站在企業戰略目標的基礎上對項目產生的提交物或是企業整體能力完善提出更高的要求。譬如：完成某某通用組件并形成可部署的解決方案1.0版本（含相關使用幫助），并在內審通過后完成企業內開發人員的使用培訓；完成項目小組中開發人員對報表系統的開發能力的提升，并完成對企業內其它開發人員的報表系統的培訓；在項目中嘗試使用客戶溝通管理系統，并提出完善意見和客戶對溝通系統的使用反饋總結等。
五、項目約束
項目約束是指驅動項目成功的因素，在這里奉勸大家要站在出資人的角度去考慮這些約束條件，而不要過多的考慮上述第三條的項目管理目標、組織目標等，我前面說過，項目成功是先決條件，否則其它都是扯淡。
我羅列一些項目的常見約束條件如下：
|
約束
|
備注
|
| 項目資源 | 人力資源、設備資源、關系資源等一切可以為項目成功或失敗的因素對應的實體，可用魚骨圖分析 |
| 發布日期 | 在何時發布什么版本，對大部分項目來說，客戶會只要求一個終版本，這是不現實的，要告訴在終發布版本前起碼還有2個或以上的內測版本 |
| 功能列表 | 要完成哪些功能，即實現哪些必要功能是這個項目成功的必要條件，這個條件需要和客戶反復的商榷，客戶通常都是買小菜的念頭，相信功能越多越好，要讓客戶理解項目成功的鐵三角關系，這個需要進行多次項目管理思想的宣講甚至培訓 |
| 缺陷管理 | 要將缺陷控制在一個什么樣的程度上，這個指標要量化，譬如在終版本時，level300的bug要為零 |
| 工作環境 | 這點恐怕大家都不太注意，我要重點說的是中小型公司來說，要竭力避免現場開發，這里寫清楚，以后少了很多扯皮的事情 |
| 溝通管理 | 有時候出資方的管理背景比較復雜，要求項目經理要提早知道哪些干系人會對項目驗收造成影響，要學會及時溝通和匯報，多打幾個電話可以免去很多溝通障礙 |
| 企業愿景 | 這是指開發方對項目中產生的過程知識進行完善和規劃的要求，通常這個對項目成功的約束很小，但在某些項目，譬如要完成項目到解決方案或產品的抽象時需要這個，不過要完成這個約束需要很高的項目管理造詣，如果項目比較有把握完成時才建議把這個納入到約束中來 |
以上只是列舉了一部分，當然實際情況中，項目的約束有很多，不過對于大部分軟件開發公司來說，基本上足夠了。
值得注意的是，項目的約束需要進行優先級別的排序。也是說一個項目中，這些約束不要在同一個優先級上全部滿足，根據我的經驗，一個項目也是一個高優先級的關鍵約束，另外加上兩到三個的次要約束條件即可滿足項目成功的所有必需條件，另外的約束條件應該作為錦上添花的約束進行羅列，完成了當然好，不完成也影響不了項目的總體驗收。
大部分國內項目的約束條件的頭4個基本是1）工期、2）完成必要的高優先級的功能點，3）可以保證質量的終交付版本，4）項目資源的保證及穩定，高于一個關鍵約束條件或高于三個以上的次要約束條件對項目的成功會造成比較大的風險，同時也會對項目的成本造成很大壓力，畢竟國內的項目很多都是定價合同，象國外一樣的按功能點簽議價合同的是天方夜譚的事情。不過3個以上的次要約束條件才能保證項目本身成功的項目也有很多，這要發揮你項目經理的溝通能力了，如果你不能說服客戶，那么這些約束條件你要做詳細的風險分析了，這個以后的章節再作討論。
下節將介紹項目假設、項目管理方法論、項目的可交付成果、概要進度、參考里程碑提交物等概念
五、項目假設
字面意思來解釋，是必需滿足這些假設的條件，項目才可能按計劃開展任務，這里的假設大家不要寫得過多，而要集中關鍵假設上，這個需要結束上篇文章提到的項目約束來講：
為了大家不用翻上篇文章，我把描述粘過來
值得注意的是，項目的約束需要進行優先級別的排序。也是說一個項目中，這些約束不要在同一個優先級上全部滿足，根據我的經驗，一個項目也是一個高優先級的關鍵約束，另外加上兩到三個的次要約束條件即可滿足項目成功的所有必需條件，另外的約束條件應該作為錦上添花的約束進行羅列，完成了當然好，不完成也影響不了項目的總體驗收。
因此，影響高優先級及次要優先級的假設條件才是你需要關注的：
譬如：工期作為高優先級約束。有些項目有近乎苛刻的工期要求，這時首要保證的假設無外乎如下：
人力資源（包括開發方和客戶方，大部分項目經理在做假設時只估算了開發方，其實客戶如果業務繁忙，沒法配合你的需求調研、版本審核、業務指導等也會影響工期，如果有第三方，那么還要包括第三方）
設備資源（計算機設備、網絡設備、其它硬件設備、辦公條件等）
資金資源（人力成本、加班經費、風險準備金（這個要估足）、交通誤餐等）
知識儲備（預估項目中可能遇到的知識難點，可以通過培訓、外聘專家、外包等解決）
根據項目實景分析（采用魚骨圖，SWOT等工具）會遇到的項目延期問題，譬如客戶沒一個懂需求分析重要性的，那要安排相應的需求分析知識培訓給客戶
項目假設是可以補充的，應該說項目假設有點類似于風險分析，但項目假設是著重于關鍵約束實現的必要條件，而不是應對方案。
六、項目管理方法論
項目管理方法論不過多闡述了，如果你的企業有一個完整的項目生命周期管理，那么這里其實是選擇相應的生命周期，如果需要適當裁剪的，要把裁剪后的周期詳細說明。
瀑布、敏捷、RUP等這些都是生命周期的呈現形式，根據不同的企業特點，會對這些方法進行相應的改動以適應開發過程。
七、項目的可交付成果
這個很清晰，一般來說第1、2項是客戶要求的，第3項需另外約定
1、軟件各個版本
2、各個里程碑提交物（文檔、階段交付產品）
3、項目過程中生產的其它附屬提交物（通用類庫或組件、附屬開發產品（譬如一個小型OA））等
八、概要進度
這一項很多項目經理很反感，確實我也很不愿意預估，因為項目開始的時候很多條件都不是很明確，那些WBS在這個階段是沒法弄的，沒辦法預估，而項目章程非要來這么一項，怎么辦呢。
我提供一些思路給大家
1、憑經驗預測，這是不靠譜的，建議不到山窮水盡的時候不要用，因為你一旦對企業承諾了，實現不了全是你的責任了
2、短暫啟動評估法
老外也叫這個“哈德遜灣式啟動”，方式源自17世紀加拿大的哈德遜灣航運公司，這家公司的商船在啟航后，會在距離港口幾英里的地方做短暫停留幾天，這樣確保如果忘記裝載了一些必須的給養和裝備，可以回到港口再補充。
運用到項目管理中，可以讓項目小組先嘗試在項目的實際環境中先開展完成某些功能和工作，具體說來譬如一組測試驅動的代碼或是某一組功能的思維導圖，這個時間要盡量短，一般不要超過三天，如果你不好選擇開展哪些工作，那么你可以選擇手頭上可以在4小時內完成的工作，完成之后，項目組一起來分析這些工作。如果還是不知道，那么請看下面的辦法
3、短期迭代
和上面不一樣，這個估算是以一組功能或工作完成后，團隊成員來一起分析整個項目的工期，譬如說大家一起把需求分析中所需的功能點整理出來后，或是以某一組功能完成為前提，來進行工期的整體評估，這個時間好在一周內。
4、團隊頭腦風暴
按任務從上至下進行分解，大家各抒己見，用加權平均來分析具體工期。這個做法的誤差很大，而且要求項目組成員的經驗足夠豐富，否則不宜采用。
九、參考里程碑提交物
這個舉例說明了，大家看看下面的表格一目了然了
|
序號
|
工作里程碑
|
前置任務
|
參考提交物
|
|
1
|
項目立項 |
|
《項目章程》 |
|
2
|
需求分析 |
1
|
《需求分析說明書》 |
|
3
|
編碼實現 |
2
|
《任務分配表》《測試計劃》 |
|
4
|
測試 |
3
|
《用例測試》《bug報告》 |
|
5
|
部署 |
4
|
《管理員手冊》《操作員手冊》《數據字典》《驗收報告》 |
|
6
|
維護 |
5
|
《維護計劃》《災難恢復手冊》 |
*黑體的文件需客戶簽字認可
