做好項目管理，對于每個職場人來說，都是一件很重要的事情。本文作者結合自己3年的工作經驗，梳理了一套自己的方法論，并將這套方法論分享給大家，希望能夠有所幫助~

為什么會寫這篇文章？

從事項目管理3年已經左右，從最開始的什么都不懂，到現在的同時處理多個重點項目，一路走來也有一些心得，希望可以總結下來，幫自己梳理出自己的方法論，便于在日后更加清晰便捷的完成后續項目交付，也便于日后總結自己的不足時有所依據。

各類項目和各類項目管理方法

“萬物皆產品，萬事皆項目”

以上是我對所有事物的理解，每個“物”都可以被理解為產品，每件“事”都可以理解為項目，世間每種“事”都有自己的處理方法，放到工作上就可以理解為各類項目都有各類項目的項目管理方法。

我是不贊成使用統一一個項目管理方法來管理所有的項目，比如工程類項目與研發類項目不同、瀑布類項目與敏捷類項目不同等等。

其實針對細分類別，已經出現了很多行業內的項目管理方法論，比如華為內部就有“六步一法”方法論，現在我來介紹一下我總結的項目管理方法。

六部一法：

• 第一步：明確目標、范圍確認；
• 第二步：制定重大項目里程碑；
• 第三步：項目活動分解、準備工作計劃；
• 第四步：質量控制、實施指導書；
• 第五步：進度計劃及站點計劃的制定；
• 第六步：制定區域計劃流程；
• 一法：項目的溝通策略

我所寫的項目管理方法分類及內容：

首先，我所在的行業為軟件行業，所做的工作內容為交付類項目管理；此類行業的特點為：公司內部有標準產品，但交付給客戶時會接受部分定制開發。

經過長時間實踐，我總結出了此類行業自己的項目管理方法：二維四階段項目管理方法。

下面來介紹一下此方法內容：

二維四階段方法怎么用，有什么用？

首先，方法論的作用一定是用于指導工作，所以方法論的用法建議為：在項目各個階段（在項目啟動階段尤其重要）進行項目規劃時，按照方法論來梳理項目交付流程。

那么方法論有什么用呢？其實所謂“方法論”就是前人總結下來的經驗，積極正確的使用方法論可以避免工作中絕大多數“坑”的存在。

什么是二維四階段

二維：即內部維度和外部維度。

主要是按照利益相關來劃分維度，維度主要用來區分相關方；內部維度即“自己人”，特指與項目利益正相關的人；外部維度即“外人”，特指與項目利益負相關的人。

無論內部維度還是外部維度，都會存在幫助項目經理推進項目的相關方以及會阻礙項目經理推進項目的相關方，所以在項目啟動前期識別出各個維度的相關方對日后項目交付尤為重要。

四階段：啟動階段、方案階段、研發上線階段、收尾階段。

按照不同的目的，將項目交付的不同目的區分各個交付階段，在每個階段完成指定的任務，是二維四階段方法的核心。

在日常生活中，人們處理事情的步驟基本都是：收到通知要做一件事（啟動），了解這件事要做成什么樣（方案），去做這件事（研發上線），事情做完了（收尾）。

所以，按照人們的日常習慣，將項目交付也區分為四個階段來進行管理，更加直觀與便捷。

下圖為二維四階段方法的實施流程圖：

各階段人員職責：

在項目交付過程中，每一類相關方都有不同的職責，在本方法中職責內容總結如下：

各階段工作內容簡述：

（1）前言

標準產品模塊 定制的項目交付，相較于傳統的大型項目交付有著很大的不同，不同點包括但不限于：

1. 傳統大型項目發展較為成熟，有著市面上標準的交付件，交付流程
2. 與傳統IT行業純定制交付方式相比，存在標準產品模塊，無法全部按照客戶的需求去進程產品設計及交付
3. 與新興的SaaS產品類互聯網公司相比，產品應用環境復雜，功能相對不夠完備，故無法直接讓客戶使用標準產品功能
4. 模式較新
5. 成本核算困難

近幾年，國內已經出現了幾十家以此類項目為主營業務的公司，產生的原因也是這類公司希望以項目來養產品，最終做成純SaaS類公司。但由于其產品類型特殊，功能復雜，所以距離最終結果還有很長時間。

換句話說，此類標準模塊 定制的項目還是會存在很長時間。

下面就來正式介紹一下“二維四階段”：

（2）啟動階段

“項目”的定義為“為創造獨特的產品、服務或成果而進行的臨時性工作”，其中“臨時性”則代表著這個工作一定是有明確的開始和結束時間的，啟動階段就是來定義這個項目的“開始”。

啟動階段的目標為：

1. 將項目的負責人從商務轉交到項目經理；
2. 組織公司內部項目成員及甲方項目相關方，組建項目團隊并確認分工；
3. 確認項目“開始”時間，并動員項目團隊成員開工。

以啟動階段的目標為依據，一般在啟動階段需要進行的工作內容為：項目資料的交接與收集、組建項目團隊以及組織項目啟動會，其中：

項目資料的交接與收集：主要指項目經理與商務或者其他成員進行的項目資料交接與收集。其中的項目資料主要指的是：客戶需求，客戶組織架構，客戶的主要對接人及項目相關方，客戶內部對本項目的期待/目標，客戶公司資料以及對接人員/部門的資料。商務人員不一定有全部的項目資料，所以如果有欠缺的資料還需要項目經理與商務人員繼續收集。

項目資料的交接與收集的主要意義在于讓項目經理從客戶公司信息、組織架構信息、成員信息、目標信息等多個維度去詳細了解客戶以及客戶對于本項目的期待，從而分析客戶相關成員可能對本項目給出的支持情況。

知己知彼，百戰不殆。

組建項目團隊：項目需要有人執行下去，而項目經理是不可能獨自完成項目的；所以，在項目正式開始之前，需要完成項目團隊的組建，并把任務分配出去。

在這一階段，新手常犯的錯誤主要是僅將本公司項目成員確定的非常完善，但對于客戶方的項目成員并沒有去定義，或者定義的不明確。這樣會出現的問題是如果項目出現變更或需要客戶側提供資料等的情況時，找不到客戶的聯絡人或者相關責任人，導致項目延期。

所以，在確認項目團隊時，除了內部成員外，還要詳細了解客戶側的決策人、項目主對接人、與決策人的聯絡人、相關業務的使用者等角色都是誰，并盡量將這些人員都納入到項目團隊成員中。或聯合客戶決策人對這些成員進行定義與指派，達到組建客戶側項目團隊的目的。

項目啟動會：當項目資料收集完畢，內部項目團隊組建完畢，客戶側項目團隊也定義完畢之后，就需要一個“儀式”來向所有項目成員公告項目正式啟動，這個“儀式”就是項目啟動會。

由于在項目啟動會上，我們需要對客戶側的項目成員進行定義，以及多爭取一些我們可以調用的資源，所以在項目啟動會上，客戶的決策人一定要在場，我們需要借助決策人的手，來幫我們調動客戶側的人力資源。

（3）方案階段

從啟動階段確認好項目何時開始后，便可以進入項目方案階段，此階段的目標為：

1. 根據合同內容，調研客戶相關需求內容及期望；
2. 收斂需求范圍，統一交付目標；
3. 確認項目實施&研發計劃；
4. 雙方確認項目“解決方案”。

方案階段主要是確認“怎么做”以及“做多少”，所以這一階段主要的工作為：業務需求調研，項目計劃輸出，方案輸出及確認。

業務需求調研：由于一般需要進行項目交付的產品都是toB的產品，對于這類產品來說，客戶的需求才是決定產品形態的最重要因素，所以在業務需求調研階段的工作尤為重要。至于為什么這個階段的工作叫做“業務需求調研”而不是“需求調研”，原因在于，在了解客戶需求的同時也要同時了解客戶的業務是怎樣運轉的，客戶提出的需求是否可以滿足客戶的真實業務場景。

與此同時，作為一名專業的項目經理，需要對業務有著全局的前瞻性考量，在業務需求調研時也需要結合自己對于業務的思考及規劃，適當對客戶進行引導。

此部分工作內容及順序主要為：確認業務需求調研對象，以客戶需求為基礎編寫《業務需求調研內容》，實施調研，輸出《業務需求調研報告》，雙方對業務需求調研報告進行簽字或郵件確認。

項目計劃輸出：計劃是項目可以正常交付的基礎，是內部項目成員實施項目的標準。

制定項目計劃時，首先要根據客戶需求，確認需求中的每一項任務的實施/研發周期以及前置條件，再結合客戶的時間預期，進行工作的調整，最后輸出《項目實施計劃表》或《項目實施計劃書》，雙方確認。

方案輸出：這里的“方案”通常指“業務解決方案”，即融合了自己公司的產品能力以及調研時收集到的客戶方業務需求，最后輸出的統一解決方案。

此項任務為整個項目交付過程中最重要的一環，輸出此方案的意義在于統一客戶與公司內項目成員的目標，限定項目的需求范圍以及產品形態，避免因前期需求溝通內容不明確、合同內需求描述不完善、人員交替等原因導致的需求范圍不明確的現象。

由于每個公司的產品形態不同，所需要的業務解決方案也不相同，所以無法詳細定義業務解決方案具體涵蓋的內容。但通常來說，業務解決方案中應包括的內容為項目背景、項目目標、業務需求調研內容、產品設計方案、功能責任部門/責任人等，視產品形態不同而選擇性增減。

需要注意的是，在業務解決方案中對產品的描述應盡可能以產品設計高保真原型圖 文字解釋來展示，以此來約束產品細節的邊界。同時，業務解決方案也一定要有決策人的簽字或郵件確認，才可進行下一步研發工作，否則一旦產生變動，成本可能會成倍增加。

（4）研發上線階段

研發上線階段項目經理主要工作內容為監督項目成員按項目計劃及解決方案內容，準時保質保量開發完成，并可以交付客戶使用，所以此階段的目標為：

1. 確保產品準時上線；
2. 上線后讓客戶可以使用起來。

在研發上線階段，項目經理需要進行的工作主要有：協助項目成員完成產品的研發上線及培訓客戶、產品上線動員會、簽署產品上線確認單。

協助完成產品研發上線及培訓：產品研發上線過程中，涉及的工作較多，但大多數均為實施人員去推進，相關工作可能有：

• 采購及準備研發上線環境；
• 與各個部門如產品經理、研發（前端、后端、客戶端等）、測試、運維等持續溝通，保證需求傳達準確；
• 與甲方項目相關人員溝通收集業務基礎信息并完成配置；
• 準備產品使用手冊及功能培訓資料等等。

產品上線動員會：其實在大多數情況下，客戶理解的“上線”與我們理解的“上線”并不相同，我們認為代碼部署到正式環境中即是產品的上線，而客戶對于上線的理解可能是多種多樣的，我們需要有個“儀式”來將雙方對于“上線”的理解統一。

同時，產品上線后，客戶的相關成員可能由于責任心、工作量增加等各種原因，導致并不一定會正式使用產品功能，使得產品功能交付后無人使用，我們也需要有個正式的產品推介會，來向項目相關成員推廣介紹產品，并通過客戶的決策人來推動客戶側的相關成員使用相關產品功能。

了解了以上兩點關于“產品上線動員會”的作用后，我們就可以組織發起一場動員會了，關于動員會的注意事項為：

1. 要保證甲方決策人在場，否則大概率很難推動甲方項目相關成員；
2. 盡量保證產品功能責任落實到人，而非角色或部門，否則會因為責任歸屬不清而造成成員之間相互推諉；
3. 會后要留會議紀要及參會記錄等留痕文件。

同時，項目經理也需要依據合同約束或者項目需求，安排一些產品功能的培訓。

簽署產品上線確認單：幾乎在每個項目中，產品上線均為項目的關鍵里程碑節點，所以確認此項工作的完成也是很重要的；

產品上線確認單中要詳細描述已完成事項及待完成事項，以便于推進后續工作的進行及項目驗收。

（5）收尾階段

產品上線后就標志著本項目工作即將完成，但其實項目收尾階段的工作不一定會少。

由于業務調研階段及產品研發階段進行的調研及研發與產品上線時，已經有一段時間間隔，所以很難保證需求100%是按照當初的業務解決方案來處理的。同時，初期上線的產品也很難保證沒有缺陷……

在項目收尾階段，主要的目標為：

1. 完成前幾階段未完成的任務。
2. 解決前幾個階段出現的問題（文檔缺失、缺陷修復、補充培訓等）。
3. 完善合同內要求的交付件。
4. 進行項目驗收。

在項目收尾階段，項目經理所要做的事歸結起來就是一個詞——“查漏補缺”，主要的工作內容有：核查并完成未完成事項、驗收前溝通、項目驗收會、簽署項目驗收單。

核查并完成未完成事項：收尾工作的主要工作有80%為核查并檢查未完成事項，其中未完成事項的內容包括：未完成的需求、待解決的BUG、未提供的文檔、未配置的配置項、未提供的培訓等等，具體無法細講。

但是需要注意的是，理想情況下，項目經理的主要職責是按照“清單”將事情做完。也就是說，在此階段，主要的目標就是將所謂的“清單”——也就是各類合同、需求變更單、補充協議等——上面的要求，把沒有完成的事情做完即可。

驗收前溝通：“中國的社會是一個人情社會”，即使已經發展到了現在這么繁榮，依然逃脫不了人情世故。

在做項目時，最難的其實就是項目的驗收，難在即使滿足了合同里的一切內容，也不一定滿足關鍵對接人的需求。所以在正式驗收之前，一定要組織多次驗收前的溝通，主要的溝通內容就是了解客戶側驗收的流程，以及整個流程中起到關鍵作用（主要是簽字）的關鍵人員對于此次驗收的想法，并且逐一攻克，直至整個驗收流程的所有人員都同意項目驗收。

至于攻克所有的方式，是采用合同談判、高層壓力、利益誘惑還是其他手段，全憑對接人的性格特點以及當時所在的形式以及項目經理個人經驗，無法展開講述；

項目驗收會：當驗收前溝通已經順利完成后，項目驗收會就變成了一個過場形式；但即使是一個形式會議，也要做到甲方決策人必須在場，畢竟沒有什么比決策人現場做的決定更有說服力了。

簽署項目驗收單：項目驗收單可以在項目驗收會的會議上當場簽訂，也可在會議結束后的當天或當周簽訂，最好不要過于拖延。

當項目驗收單簽署完成，也就標志著本項目的交付工作已經完結，項目經理就可以與商務交接此項目了，交接的目的主要為：讓商務持續跟進項目回款以及是否有二次銷售機會。

至此，二維四階段式交付方法就全部介紹完畢了，篇幅有限，無法將全部細節一一展開，只能去講述交付時最關鍵的節點，后面會針對特殊的細節繼續分享~

本文由 @李強~ 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議