上述對話雖然是個段子，但也體現了項目管理在項目周期當中的重要性。

眾所周知，產品經理跟項目經理的崗位職責是有區(qū)別的，但在部分公司，產品經理在進行規(guī)劃產品的同時，偶爾也要擔負部分項目經理的工作，阿境結合市面上項目管理的流程及自己所處公司的情況，講講產品經理如何進行項目管理。

下面阿境將從2W1H的方式來進行介紹項目管理，what、why、how。即項目管理是什么？為什么要做項目管理？怎么做項目管理？

另：附上本文導圖框架，節(jié)約時間。若您感興趣，可繼續(xù)深入閱讀；若不感興趣，感謝光臨。（文末有阿境給朋友們準備的知識地圖，有興趣可以看看）

01

什么是項目管理？

了解項目管理之前，我們得先明白，每個PM天天掛口頭上的“項目”到底是什么？

項目是為了創(chuàng)造獨特的產品，服務，成果而進行的臨時性工作。

那么，項目管理是什么？

百度百科的解釋是：項目管理是運用管理的知識、工具和技術于項目活動上，來達成解決項目的問題或達成項目的需求。所謂管理包含領導（leading）、組織（organizing）、用人（staffing）、計劃（planning）、控制（controlling）等五項主要工作。

項目管理的影響因素很多，阿境總結歸納為六要素：質量、進度、成本、范圍、組織和客戶滿意度。

簡單的說，項目管理即一個標準化的流程，使得項目能夠按照預定的時間、計劃（包括質量、成本等）順利地開展。

項目管理的流程大致可以拆分為幾個步驟：項目啟動→項目計劃→項目執(zhí)行→項目監(jiān)控→項目收尾。在下文會做詳細解答。

02

為什么要進行項目管理？

首先我們明確一個范圍，本篇文章中提到的“項目”指的是互聯網產品項目；

另外，對于專業(yè)的項目經理來說，產品經理在項目管理層面更注重的是服務于需求，包括需求的傳遞、評審、落地，同時，追求更高效的跨部門溝通，協作。

2.1 整合資源，集成協同并進

一個項目是多個部門甚至是多個組織/公司進行合作開發(fā)，即集成協同并進。拿開發(fā)軟件來說，涉及產品、設計、前端開發(fā)、后端開發(fā)、測試、運營等多個角色，進行項目管理能夠有效的將多方面的資源融合，更有效地利用起來；

2.2 減少不確定因素，保證進度可控

項目在進行的過程中會出現各種不確定因素（錯誤、延期、改版等），項目管理能夠更好的將不確定的因素盡量保證可控；

2.3 工作內容文檔化，使得項目清晰化、邏輯化、一致化

項目管理的核心是將工作內容文檔化。人的記性是有限的，在項目過程中涉及的方案，人員安排，項目變動等信息量都是巨大的，且經常會出現多個項目并行開發(fā)的情況，這個時候項目文檔的作用更加凸顯。

能夠使得項目人員的思路清晰化、邏輯化、一致化，同時在項目結束之后，相關項目文檔能夠作為復盤項目的有效依據。

總的來說，項目管理就是為了滿足項目管理人員對于項目的需求和預期，在質量、范圍、進度、成本上進行項目的整體把控。

03

怎樣進行項目管理？

項目管理涉及的范圍較廣，歸納起來可總結為項目管理的道、法、術，即方法及工具。

上文提到項目管理的流程（該流程也是PMP中涉及到的完整流程）：項目啟動→項目計劃→項目執(zhí)行→項目監(jiān)控→項目收尾。

在這部分阿境就將這幾個流程一一拆解開進行描述，以便于大家能夠更加清晰地理解項目管理的概念及流程。

3.1 第一階段：項目啟動階段

不論是什么項目，成功與否，之所以能被啟動，有它背后的原因：市場推動、資本推動、領導主觀、多次調研后決定......等等，本篇文章主要重點在于項目管理，這邊就不過多地做項目誕生原因分析。

那么，在項目啟動階段，我們該如何做呢？

利用3W1H的分析思想去思考：①為什么項目要啟動（立項）——why   ②項目目標是什么——what  ③項目參與人員——who  ④項目怎么啟動——how

3.1.1 項目為什么要啟動？

項目啟動的標志為項目立項，所以該問題可以轉化為：項目為什么要立項。

該處分為大項目和小需求，大項目主要指的是從0到1的項目完整開發(fā)，例如某電商系統(tǒng)APP，或者是某產品中的大型功能，例如淘寶中的會員系統(tǒng)等。小需求指的是系統(tǒng)中的部分版本迭代。

項目立項是為了能夠更加明確項目的目的及來龍去脈。

3.1.2 項目目標是什么？

項目的種類跟需求不同，造成了項目目標的差異。有的項目是為了應對上級需求（質量不要求高），有的項目是為了探求市場（質量中等，開發(fā)時間短），有的是完善產品各項體驗，有的是針對產品的促活、拉新，有的是公司的戰(zhàn)略部署等等；

只有明確了項目目標，才能夠合理的安排項目及資源分配。

3.1.3 項目的參與人員？

可以從兩個方面來進行思考：哪些人跟項目有直接關系？哪些人跟項目項目有間接關系。針對于互聯網項目，項目的提出方一般是領導/老板/產品/客戶，項目的執(zhí)行者為開發(fā)團隊：產品、設計、測試、開發(fā)、運營等都跟項目息息相關。

通常在項目啟動之后，阿境會將項目的參與人員（包含需求提出方跟開發(fā)團隊）拉一個群，這樣一來，將項目大概進行介紹，如此一來，項目的參與人員能夠清楚自己是該項目的參與者，也能有個提前準備的時間。

3.1.4 項目如何立項？

在項目啟動階段，針對于線上，則是進行拉個小群，在線下，通常有個“項目立項會”，跟項目參與人員闡述項目的來源（為什么做），誰來做（參與該項目的人員）、怎么做（采用什么框架、何種設計規(guī)范等）、項目目標（快準狠等）、項目的大概起止時間等。

主要是跟團隊的負責人員進行灌輸項目啟動的概念。

3.2 第二階段：項目計劃階段

在進行項目啟動之后，并不是立即的進行投入開發(fā)，產品同學更多的是先將項目理清需求，進行需求文檔的制作，接著進行開發(fā)資源的排期安排等，也就是項目計劃階段。

3.2.1 工作任務分解

工作任務分解就是將任務不斷地進行去分解到不可細分為止，然后根據任務來估算工期及成本，同時責任到人，每個人在固定的節(jié)點給到固定的文檔及完成自身相應的工作任務。

通常我們也稱之為WBS（Work Breakdown Structure），工作分解結構。當任務不斷細分，則整個項目的抗風險能力也越強。

對于工作任務，可以分為兩個類型的項目來看

分解方式

工作分解的方式有：按照產品的功能模塊分解、按照產品的平臺類型分解、按照實施過程來分解，將多種分解方式結合等方法。

舉個例子，產品需求是做一個商城，那么可以分為APP端、小程序端、網頁端（如果需要做這么多平臺的話），這是按照產品的平臺類型來分；

每個端的負責人員又各有異同，APP端分為Android開發(fā)，IOS開發(fā)，后端開發(fā)；小程序端分為前端開發(fā)跟后端開發(fā)；網頁端也分為前端開發(fā)跟后端開發(fā)。

接著，針對于某個平臺，按照功能細化開，可以分為會員模塊，積分模塊，訂單模塊，商品模塊等等，每個模塊又可細分為更細的功能，例如會員模塊又分為會員權益，會員信息等。

工具

工作任務分解的話，可借助excel、Xmind等工具進行梳理分解，因個人喜好來選擇合適的即可。工作任務分解是比較重要的一步，只有分解清楚，后面的優(yōu)先級安排及任務計劃排期才能做的準確。

3.2.2 任務優(yōu)先級安排

在前面的工作任務分解完成之后，接著就是將這些雜亂的進行優(yōu)先級安排。先開發(fā)哪個功能，再開發(fā)哪個功能。

劃分優(yōu)先級的方式也有多種：按產品功能劃分，按緊急程度劃分等。

按照產品功能劃分的前提，一般是在項目時間充裕的前提下，按照功能的優(yōu)先級進行排序。不好理解？來，阿境舉個例子，開發(fā)一個小程序商城，有商品模塊，訂單模塊，分銷模塊，退貨退款模塊等。那么順序應是將前期的基礎商品模塊、訂單模塊先建立起來，再來做分銷模塊跟退貨退款模塊。

按照緊急程度來劃分的話，按照時間管理四象限法來看，依次的排序是：緊急且重要＞緊急不重要＞重要不緊急＞不重要不緊急，但前提也是保證功能劃分可行的前提下。例如，下個月要啟動商城分銷的功能，但商城的商品體系還沒建立起來，那么再急的話，也得將商品體系先建立起來后，再做分銷體系。

任務優(yōu)先級的安排，更多的是將兩三種分類方式結合，才能夠將任務優(yōu)先級劃分得精確，做到開發(fā)效率最大化。

3.2.3 任務計劃排期

完成了任務分解跟任務優(yōu)先級安排，接著就是任務排期（一個項目不可能無休止的進行下去），上文提到，可利用excel、project等工具進行羅列項目功能點跟優(yōu)先級，接著跟開發(fā)人員進行溝通，進行各功能點的項目排期。

正常來說，項目都有一個整體時間，例如2020.5.1-2020.9.1，那么，要按時交付項目，項目計劃排期是十分有必要的，因為項目會出現大大小小的變動，排期是為了控制項目的整體進度。

3.2.4 風險控制

在項目管理當中，要盡量將風險前置，盡量保證風險可控。（劃重點，這個也考）

不管項目管理做得再好，項目風險總是存在的，有的風險可以杜絕，有的風險可以防范，阿境將項目風險劃分如下幾大類：

在項目需求對接的前期，需求提出方只給了一份需求文檔，然后產品同學就開始進行項目的規(guī)劃，在項目規(guī)劃的階段跟設計、開發(fā)的階段，需求提出方并沒有完全參與進來（沒有一步步確認），那么就有可能造成，等項目完全做好之后，提給需求提出方之后，需求提出方指出項目并不是他想要的，需要進行重大改版，甚至是推翻重來。那么這個時候的問題就大了，不論是在成本上還是項目影響范圍上，無疑都是晴天霹靂。

所以在項目的每個步驟（對接需求、設計稿、程序后端建表、測試等）都最好跟需求提出方進行溝通確認，才不會造成后期返工項目大改的情況。

明確項目需求是產品同學的工作內容之一，深入挖需求是必要的。只有明確了全部的需求之后，設計同學跟開發(fā)同學才能夠順利地進行設計跟開發(fā)，自然對于需求文檔的改動也會比較少。需求不明確同樣會造成返工調整，雖然可能在短時間內可以調整，但也容易降低設計跟開發(fā)同學的工作積極性（不斷的返工容易讓人疲倦）。

所以產品同學提高自己的挖掘需求的能力也是很有必要的，有的需求提出方并不能夠完整的描述他的需求，特別是對于傳統(tǒng)行業(yè)的需求提出方，所以這個時候產品同學的作用就很重要了。

任務計劃在上文有提到過，包括任務分解、優(yōu)先級安排、任務排期。任務計劃不合理的原因在于這三個部分其中的一個或者多個出了問題。

舉一些計劃不合理的例子：項目預估工期為五個月，給開發(fā)同學三個月的時間，在任務時間安排上已然不合理，若此時PM不進行任務優(yōu)先級安排，或者是優(yōu)先級安排失誤，那么項目鐵定延期無疑了。

需求提出方通常有以下幾個角色：領導、運營、市場（用戶）、銷售、甲方、PM等。

可能由于各種不可控的因素，導致了需求變動，也會造成開發(fā)難度的增長、工期的延長。部分需求的改動，可能是PM在最初時期沒有考慮清楚，當框架搭建好了之后，再去新增需求的話，開發(fā)人員改起來就會比較傷筋動骨。

技術風險主要在于開發(fā)人員身上。在項目立項的時候，往往會進行技術評估，在立項會中，參與項目的技術人員在了解了項目情況之后，會進行技術選型，以及技術難點的探討，若涉及對接第三方接口，則會進行第三方接口文檔的查看，這個時候會綜合判斷第三方接口提供的功能是否能夠符合預期功能。

在技術階段評定之后，在后續(xù)的開發(fā)，可能會推翻前面的技術評定，也可能由于前期的判斷失誤，在實現某個功能的時候遇到了瓶頸，也可能在技術層面上的拖延，導致工期的延長。

3.3 第三階段：項目執(zhí)行階段

3.3.1 各細分過程跟蹤

在開發(fā)的過程當中，項目經理往往要根據前期所制定的排期計劃（包括之前提過的任務計劃排期、工作任務分解、優(yōu)先級排期）來進行設計過程、開發(fā)過程、測試過程的跟蹤，也就是項目管控。一個項目，少則一兩個月，多則一年半載。

同時，往往在真實的項目開發(fā)過程當中，并不是只有單一的項目在運行，可能會有多條產品線，多個項目并行開發(fā)的情況（也可能涉及到不同的開發(fā)人員），也就是說，一個開發(fā)/設計/測試人員，手頭可能同時負責多個項目的情況，A項目完成到15%，B項目完成到35%......所以，項目的多、亂、雜，需要科學合理的過程跟蹤。

• 若沒有進行項目的過程跟蹤，可能造成未能按照預期完成項目計劃，項目延期。

• 項目如期完成，質量卻不盡人意，最終造成項目返工修改。

• 產品、開發(fā)、設計等對于PRD的功能理解有偏差，模塊的完成與預期不符合，最終也造成返工。（此點更偏向于在開發(fā)過程當中多溝通方面）

由此可見，項目過程跟蹤是否得當，對于最終項目產出的質量也是至關重要的一點。

3.3.2 階段性產出文檔審核

在整個項目的生命歷程當中：

產品經理需要輸出PRD（產品需求文檔），其中包括功能框架、泳道圖、業(yè)務流程圖、原型圖、其余說明等等。

項目經理需要輸出排期表，任務優(yōu)先級表，人物分工表等等。

設計師需要輸出設計選型，配色方案，風格定位，設計稿等等。

開發(fā)工程師需要輸出開發(fā)選型、數據庫結構設計、接口文檔、開發(fā)操作文檔等等。

測試工程師需要輸出測試用例、測試方案、測試結果報告等。

目前太多PM會局限于各類文檔模板，追求文檔的完整度美觀度等。但在這里，阿境要說的是，文檔存在的意義，在于使得項目更加規(guī)范、有條不紊地進行下去。

文檔在這當中只是一個傳達信息的介質，之所以選擇文檔來代替口頭，是因為文檔能夠更好地留存及記錄。而只要能夠達到目的，明確了這點，文檔具體的展現形式，樣式就不那么重要了。

最適合自身公司及業(yè)務需求的文檔，才是好文檔。

3.4 第四階段：項目監(jiān)控階段

3.4.1 例行項目會議

提到了項目過程跟蹤的重要性，那么問題來了，如何進行項目跟蹤？一個比較重要的措施，便是例行項目會議。

項目會議可分為每日站會跟周會。作用除了能夠管理項目，也可以管理項目當中每個角色的開發(fā)狀態(tài)。當然，這邊的管理并非指傳統(tǒng)意義上的管理者，這是由于互聯網行業(yè)，產品經理/項目經理可以看作是一個總的牽頭人，可謂是產品的靈魂。（自賣自夸一下哈哈哈）

每日站會

在每日站會上，不同的角色所需要關注的點也不同。

1、產品經理，可在項目看板上，整體介紹每個項目目前的進展情況，與預期的差別，著重點在于每個項目整體的進度是否符合原先的項目排期。

2、設計師的重點，則在于目前手頭項目的頁面數量及美觀，由于設計方面包含了大量的主觀性，所以設計出來的產品，是否能夠滿足目標用戶（使用者/產品/甲方等）的要求，在目標用戶提出要求之后，加上修改的時間是否能夠如期完成等。往往會遇到一個情況，設計師用兩周的時間完成了設計稿，卻用了一周多的時間來進行設計稿的修改優(yōu)化。這個情況難免會造成項目的延期。

3、開發(fā)人員的話，相對來說就比較復雜一些。除了關注不同項目的不同進度之外，還要著重于每個單一項目的進度。整體進度是否與項目排期表一致；功能模塊是否按照優(yōu)先級來完成；開發(fā)的時候是否遇到瓶頸；準備如何解決，若無法解決，與產品經理協商下，是否有Plan B等等問題，也是開發(fā)人員需要在每日站會上來進行匯報討論的。

4、測試人員，關注點在于項目的完成情況，是否需要進行提前的模塊化測試；若整體完成，則測試進度是否如期進行等。

整體的每日站會時間，控制在5-15分鐘之間，快速高效是重點，不開無意義的會議。

重要的事情說三遍：

不開無意義的會議！

不開無意義的會議！

不開無意義的會議！

同時站會通常安排在每天上班后的半小時后，原因在于：剛開始上班的前半小時，每個人可以回顧一下昨天完成的任務，同時規(guī)劃下今天的任務安排，討論下遇到的任務難題，如此也能使站會更加有意義，形式化的每日站會是不提倡的。

每周會議

而每周會議，與每日站會不同的是，著重點不在于關注項目本身，需盡量脫離各個項目的細節(jié)點（防止陷入細節(jié)討論，耽誤時間），以宏觀的角度來考慮整體的項目進度及情況。

3.4.2 項目周期中的日報與周報

上文提到，有每日站會，每周周會，那么同樣的，也相應會有日報跟周報，如何寫好日報跟周報是個老生常談的話題，也有許多大佬有他們的分享，這邊就不提了。

對于每個崗位，日報跟周報都是及其重要的，但是對于不同的崗位，寫日報跟寫周報的方式也全然不同。日報跟周報在一定程度上，是寫給自己看的（但其實往往都被要求發(fā)送上級領導審核），一旦成為了任務，那么，便可能產生應付的情況，那么意義也不大了。

3.5 第五階段：項目收尾階段

3.5.1 工程師自測

當開發(fā)小哥完成代碼之后，需要進行冒煙測試后，再給到專業(yè)的測試人員。

程序員進行自測是對自己所寫模塊的進一步檢查，這樣可以使對該模塊的邏輯更加明確，同時加深對于該模塊的記憶，并且可以最大程度確保每個模塊程序書寫的正確性。

3.5.2 設計師自測

UI 驗證是由UI設計師來驗證當前的系統(tǒng)UI是否能夠達到預期的效果。

UI驗證是當前頁面UI還原度的一個重要證據。UI驗證是檢測當前頁面能否做到UI圖級別的視覺效果，以及開發(fā)人員是否按照UI設計師的界面需求進行實現的一個重要準則。

3.5.3 產品經理自測

產品驗收是產品經理在項目交付前進行最后需求與程序開發(fā)是否統(tǒng)一的過程。

產品經理進行驗收是對整體系統(tǒng)流程的一個把關，也是對當前系統(tǒng)一次總的檢查，在驗收過程中需要綜合UI驗證以及測試時的一個結果來確認在產品經理在驗收后是否可以交付該系統(tǒng)。

3.5.4、測試工程師測試

測試工程師需要進行功能測試、性能測試、兼容性測試、壓力測試、回歸測試，這邊隸屬測試工程師的范疇，這邊不再過多贅述。

3.5.5 項目收尾文件

在一個項目結束之后，必然要進行項目文件的留檔記錄、包括但不限于項目需求文檔（PRD）、驗收文檔、測試報告、數據庫設計文檔、項目實施總結報告、產品使用說明手冊等文檔。

原則上，文檔涉及到項目生命周期當中的所有文件，PM在項目過程當中需要合理地進行分類及保管，以便后續(xù)項目迭代、復盤使用。

具體需要到什么程度的文檔，各公司要求各異，作為產品，尋求一個平衡點即可。

3.5.6 項目復盤

項目復盤是每個項目的極其重要，卻又容易被忽略的步驟。

• 在經歷了每個項目節(jié)點的開發(fā)推進，往往在團隊當中會暴露出部分問題，那么，不斷地復盤可以總結經驗，并且在下一次產品迭代當中，減少錯誤的發(fā)生。

• 同時也有成功的經歷，那么復盤總結可以將將成功的經驗變成規(guī)律，再次遇到的情況可增加整體項目效率，從另外一方面來看也是為公司減少成本。

• 最后，在團隊當中，幾個項目下來，團隊人員的心情、狀態(tài)都在不斷改變，復盤總結的同時，也能夠及時關注，及時處理及溝通。

項目復盤的四大步驟：收集問題、分析問題、討論問題、解決問題。

這邊不過多贅述，感興趣的可關注阿境（公眾號：夢想家阿境），同阿境一起聊聊。

04

項目管理中的幾個注意點

4.1項目成員的把控

項目管理由人來管理，那么，“人”在項目這個過程當中，尤為重要。

“水能載舟，亦能覆舟?！?/strong>項目比作船，那么人便是水。人促使了項目的推進，但在某些情況下，也能夠導致項目的失敗。

作為項目管理者，不僅僅是要關注項目本身狀態(tài)進程，同時也要關注團隊成員當中，每個人的狀態(tài)，包括效率、情緒等方面。

對于這點來說，較難細化，也沒有具體的方法論，需要朋友們切身去體會下。（有興趣的可同阿境來討論交流）

4.2項目管理工具、方法論的合理使用

項目管理工具市面上包含了TAPD、jira、禪道等等，項目因其體量不同，公司因其流程不同，人員因其性格不同，都造成了項目管理的差異。

明確項目管理的目的才是項目管理者要關注的點：在規(guī)定的時間內保質保量的完成項目目標。那么，在這個結果之前，使用什么方法論，使用什么工具，就都較為次要了。

切勿過于迷信工具以及方法論，他們存在的意義，是為了更好地幫助項目管理者完成項目，提高項目管理的效率。

4.3做好項目延期后的準備

作為項目管理者，當然是希望項目能夠如期、保質保量地完成。

但往往因為各類原因，沒辦法如愿，那么在一開始的時候，就需要做好項目延期的準備，出現風險之后的預案，避免驚慌失措的情況。

因為人員效率、外界原因導致的項目延期，那么可以適當調整需求，將較難的需求，換個方式實現。舉個例子：開發(fā)某平臺，來不及做客服功能，可考慮對接第三方客服，若還是來不及，彈出客服的聯系方式暫時應急下。一個功能按照復雜程序來做可做數個月，按照簡單程序來做可能幾個小時就能完成。

那么，項目的時間也因需求復雜程度而定，把控好這個平衡點，是產品經理需要做的。

寫在最后

“不想當將軍的士兵不是好士兵，不想管項目的PM不是好PM?！?/strong>

一個好的PM，做好自己產品規(guī)劃的同時，也需要兼顧部分項目管理的任務，即使團隊中有項目經理這個角色。

項目的運作是否能夠順利，在于是否有一個好的項目管理。

而項目管理也并非流于理論，需要在實踐當中去不斷調整。由于項目所處的狀態(tài)、個人所處的公司環(huán)境不同，每個項目的管理方法也有所區(qū)別。阿境只是希望從自身的經驗及見解，能夠給到各位小伙伴一點啟發(fā)，靈活的運用在自身的項目當中。

也希望各位產品朋友在跟團隊伙伴們說到“明天上線”的時候，大家的反應不再是“什么鬼”“不行”，而是“問題不大”“妥妥的”之類的回復。

愿從此沒有上線難的難題。（阿境祝?？吹竭@篇文章的你們~）

另：給阿境的朋友們附上自己整理的項目管理知識地圖，可保存領取。（需要高清版的可在公眾號回復“項目管理”領取）

我是阿境，見字如面。

野蠻生長，產品汪一枚，做過電商、醫(yī)療、教育行業(yè)項目。有千萬級流水產品經驗。

堅信"產品源于生活"，歡迎交流。

公眾號：夢想家阿境

萬字復盤 | 語音直播產品的從0到1

在外包公司做產品經理是什么樣的體驗？

萬字長文 | 一文帶你讀懂賬號體系