PM：“這個需求必須做，怎麼實現我不管，明天上線”
開發GG：“你項目管理都沒做好，怎麼上線？”
上述對話雖然是個段子，但也體現了項目管理在項目周期當中的重要性。
衆所周知，産品經理跟項目經理的崗位職責是有區别的，但在部分公司，産品經理在進行規劃産品的同時，偶爾也要擔負部分項目經理的工作，阿境結合市面上項目管理的流程及自己所處公司的情況，講講産品經理如何進行項目管理。
下面阿境将從2W1H的方式來進行介紹項目管理，what、why、how。即項目管理是什麼？為什麼要做項目管理？怎麼做項目管理？
另：附上本文導圖框架，節約時間。若您感興趣，可繼續深入閱讀；若不感興趣，感謝光臨。（文末有阿境給朋友們準備的知識地圖，有興趣可以看看）
了解項目管理之前，我們得先明白，每個PM天天挂口頭上的“項目”到底是什麼？
項目是為了創造獨特的産品，服務，成果而進行的臨時性工作。
那麼，項目管理是什麼？
百度百科的解釋是：項目管理是運用管理的知識、工具和技術于項目活動上，來達成解決項目的問題或達成項目的需求。所謂管理包含領導（leading）、組織（organizing）、用人（staffing）、計劃（planning）、控制（controlling）等五項主要工作。
項目管理的影響因素很多，阿境總結歸納為六要素：質量、進度、成本、範圍、組織和客戶滿意度。
簡單的說，項目管理即一個标準化的流程，使得項目能夠按照預定的時間、計劃（包括質量、成本等）順利地開展。
項目管理的流程大緻可以拆分為幾個步驟：項目啟動→項目計劃→項目執行→項目監控→項目收尾。在下文會做詳細解答。
02為什麼要進行項目管理？
首先我們明确一個範圍，本篇文章中提到的“項目”指的是互聯網産品項目；
另外，對于專業的項目經理來說，産品經理在項目管理層面更注重的是服務于需求，包括需求的傳遞、評審、落地，同時，追求更高效的跨部門溝通，協作。
一個項目是多個部門甚至是多個組織/公司進行合作開發，即集成協同并進。拿開發軟件來說，涉及産品、設計、前端開發、後端開發、測試、運營等多個角色，進行項目管理能夠有效的将多方面的資源融合，更有效地利用起來；
項目在進行的過程中會出現各種不确定因素（錯誤、延期、改版等），項目管理能夠更好的将不确定的因素盡量保證可控；
項目管理的核心是将工作内容文檔化。人的記性是有限的，在項目過程中涉及的方案，人員安排，項目變動等信息量都是巨大的，且經常會出現多個項目并行開發的情況，這個時候項目文檔的作用更加凸顯。
能夠使得項目人員的思路清晰化、邏輯化、一緻化，同時在項目結束之後，相關項目文檔能夠作為複盤項目的有效依據。
總的來說，項目管理就是為了滿足項目管理人員對于項目的需求和預期，在質量、範圍、進度、成本上進行項目的整體把控。
03怎樣進行項目管理？項目管理涉及的範圍較廣，歸納起來可總結為項目管理的道、法、術，即方法及工具。
上文提到項目管理的流程（該流程也是PMP中涉及到的完整流程）：項目啟動→項目計劃→項目執行→項目監控→項目收尾。
在這部分阿境就将這幾個流程一一拆解開進行描述，以便于大家能夠更加清晰地理解項目管理的概念及流程。
不論是什麼項目，成功與否，之所以能被啟動，有它背後的原因：市場推動、資本推動、領導主管、多次調研後決定......等等，本篇文章主要重點在于項目管理，這邊就不過多地做項目誕生原因分析。
那麼，在項目啟動階段，我們該如何做呢？
利用3W1H的分析思想去思考：①為什麼項目要啟動（立項）——why ②項目目标是什麼——what ③項目參與人員——who ④項目怎麼啟動——how
項目啟動的标志為項目立項，所以該問題可以轉化為：項目為什麼要立項。
該處分為大項目和小需求，大項目主要指的是從0到1的項目完整開發，例如某電商系統APP，或者是某産品中的大型功能，例如淘寶中的會員系統等。小需求指的是系統中的部分版本疊代。
項目立項是為了能夠更加明确項目的目的及來龍去脈。
項目的種類跟需求不同，造成了項目目标的差異。有的項目是為了應對上級需求（質量不要求高），有的項目是為了探求市場（質量中等，開發時間短），有的是完善産品各項體驗，有的是針對産品的促活、拉新，有的是公司的戰略部署等等；
隻有明确了項目目标，才能夠合理的安排項目及資源分配。
可以從兩個方面來進行思考：哪些人跟項目有直接關系？哪些人跟項目項目有間接關系。針對于互聯網項目，項目的提出方一般是領導/老闆/産品/客戶，項目的執行者為開發團隊：産品、設計、測試、開發、運營等都跟項目息息相關。
通常在項目啟動之後，阿境會将項目的參與人員（包含需求提出方跟開發團隊）拉一個群，這樣一來，将項目大概進行介紹，如此一來，項目的參與人員能夠清楚自己是該項目的參與者，也能有個提前準備的時間。
在項目啟動階段，針對于線上，則是進行拉個小群，在線下，通常有個“項目立項會”，跟項目參與人員闡述項目的來源（為什麼做），誰來做（參與該項目的人員）、怎麼做（采用什麼框架、何種設計規範等）、項目目标（快準狠等）、項目的大概起止時間等。
主要是跟團隊的負責人員進行灌輸項目啟動的概念。
在進行項目啟動之後，并不是立即的進行投入開發，産品同學更多的是先将項目理清需求，進行需求文檔的制作，接着進行開發資源的排期安排等，也就是項目計劃階段。
工作任務分解就是将任務不斷地進行去分解到不可細分為止，然後根據任務來估算工期及成本，同時責任到人，每個人在固定的節點給到固定的文檔及完成自身相應的工作任務。
通常我們也稱之為WBS（Work Breakdown Structure），工作分解結構。當任務不斷細分，則整個項目的抗風險能力也越強。
對于工作任務，可以分為兩個類型的項目來看
不論是項目的體型大或者小，都是由數量不等的需求組成的，也就是我們說的需求池。定好項目目标及功能之後，需求池也基本有了大概的框架。
我們要做的，就是将需求池裡面的需求，篩選一部分需求放到項目的1.0開發計劃中，接着将這些按照既定的順序進行排列（不可能一次性完成所有需求）。
分解方式
工作分解的方式有：按照産品的功能模塊分解、按照産品的平台類型分解、按照實施過程來分解，将多種分解方式結合等方法。
舉個例子，産品需求是做一個商城，那麼可以分為APP端、小程序端、網頁端（如果需要做這麼多平台的話），這是按照産品的平台類型來分；
每個端的負責人員又各有異同，APP端分為Android開發，IOS開發，後端開發；小程序端分為前端開發跟後端開發；網頁端也分為前端開發跟後端開發。
接着，針對于某個平台，按照功能細化開，可以分為會員模塊，積分模塊，訂單模塊，商品模塊等等，每個模塊又可細分為更細的功能，例如會員模塊又分為會員權益，會員信息等。
工具
工作任務分解的話，可借助excel、Xmind等工具進行梳理分解，因個人喜好來選擇合适的即可。工作任務分解是比較重要的一步，隻有分解清楚，後面的優先級安排及任務計劃排期才能做的準确。
在前面的工作任務分解完成之後，接着就是将這些雜亂的進行優先級安排。先開發哪個功能，再開發哪個功能。
劃分優先級的方式也有多種：按産品功能劃分，按緊急程度劃分等。
按照産品功能劃分的前提，一般是在項目時間充裕的前提下，按照功能的優先級進行排序。不好理解？來，阿境舉個例子，開發一個小程序商城，有商品模塊，訂單模塊，分銷模塊，退貨退款模塊等。那麼順序應是将前期的基礎商品模塊、訂單模塊先建立起來，再來做分銷模塊跟退貨退款模塊。
按照緊急程度來劃分的話，按照時間管理四象限法來看，依次的排序是：緊急且重要＞緊急不重要＞重要不緊急＞不重要不緊急，但前提也是保證功能劃分可行的前提下。例如，下個月要啟動商城分銷的功能，但商城的商品體系還沒建立起來，那麼再急的話，也得将商品體系先建立起來後，再做分銷體系。
任務優先級的安排，更多的是将兩三種分類方式結合，才能夠将任務優先級劃分得精确，做到開發效率最大化。
完成了任務分解跟任務優先級安排，接着就是任務排期（一個項目不可能無休止的進行下去），上文提到，可利用excel、project等工具進行羅列項目功能點跟優先級，接着跟開發人員進行溝通，進行各功能點的項目排期。
正常來說，項目都有一個整體時間，例如2020.5.1-2020.9.1，那麼，要按時交付項目，項目計劃排期是十分有必要的，因為項目會出現大大小小的變動，排期是為了控制項目的整體進度。
在項目管理當中，要盡量将風險前置，盡量保證風險可控。（劃重點，這個也考）
不管項目管理做得再好，項目風險總是存在的，有的風險可以杜絕，有的風險可以防範，阿境将項目風險劃分如下幾大類：
在項目需求對接的前期，需求提出方隻給了一份需求文檔，然後産品同學就開始進行項目的規劃，在項目規劃的階段跟設計、開發的階段，需求提出方并沒有完全參與進來（沒有一步步确認），那麼就有可能造成，等項目完全做好之後，提給需求提出方之後，需求提出方指出項目并不是他想要的，需要進行重大改版，甚至是推翻重來。那麼這個時候的問題就大了，不論是在成本上還是項目影響範圍上，無疑都是晴天霹靂。
所以在項目的每個步驟（對接需求、設計稿、程序後端建表、測試等）都最好跟需求提出方進行溝通确認，才不會造成後期返工項目大改的情況。
明确項目需求是産品同學的工作内容之一，深入挖需求是必要的。隻有明确了全部的需求之後，設計同學跟開發同學才能夠順利地進行設計跟開發，自然對于需求文檔的改動也會比較少。需求不明确同樣會造成返工調整，雖然可能在短時間内可以調整，但也容易降低設計跟開發同學的工作積極性（不斷的返工容易讓人疲倦）。
所以産品同學提高自己的挖掘需求的能力也是很有必要的，有的需求提出方并不能夠完整的描述他的需求，特别是對于傳統行業的需求提出方，所以這個時候産品同學的作用就很重要了。
任務計劃在上文有提到過，包括任務分解、優先級安排、任務排期。任務計劃不合理的原因在于這三個部分其中的一個或者多個出了問題。
舉一些計劃不合理的例子：項目預估工期為五個月，給開發同學三個月的時間，在任務時間安排上已然不合理，若此時PM不進行任務優先級安排，或者是優先級安排失誤，那麼項目鐵定延期無疑了。
需求提出方通常有以下幾個角色：領導、運營、市場（用戶）、銷售、甲方、PM等。
可能由于各種不可控的因素，導緻了需求變動，也會造成開發難度的增長、工期的延長。部分需求的改動，可能是PM在最初時期沒有考慮清楚，當框架搭建好了之後，再去新增需求的話，開發人員改起來就會比較傷筋動骨。
技術風險主要在于開發人員身上。在項目立項的時候，往往會進行技術評估，在立項會中，參與項目的技術人員在了解了項目情況之後，會進行技術選型，以及技術難點的探讨，若涉及對接第三方接口，則會進行第三方接口文檔的查看，這個時候會綜合判斷第三方接口提供的功能是否能夠符合預期功能。
在技術階段評定之後，在後續的開發，可能會推翻前面的技術評定，也可能由于前期的判斷失誤，在實現某個功能的時候遇到了瓶頸，也可能在技術層面上的拖延，導緻工期的延長。
在開發的過程當中，項目經理往往要根據前期所制定的排期計劃（包括之前提過的任務計劃排期、工作任務分解、優先級排期）來進行設計過程、開發過程、測試過程的跟蹤，也就是項目管控。一個項目，少則一兩個月，多則一年半載。
同時，往往在真實的項目開發過程當中，并不是隻有單一的項目在運行，可能會有多條産品線，多個項目并行開發的情況（也可能涉及到不同的開發人員），也就是說，一個開發/設計/測試人員，手頭可能同時負責多個項目的情況，A項目完成到15%，B項目完成到35%......所以，項目的多、亂、雜，需要科學合理的過程跟蹤。
由此可見，項目過程跟蹤是否得當，對于最終項目産出的質量也是至關重要的一點。
在整個項目的生命曆程當中：
産品經理需要輸出PRD（産品需求文檔），其中包括功能框架、泳道圖、業務流程圖、原型圖、其餘說明等等。
項目經理需要輸出排期表，任務優先級表，人物分工表等等。
設計師需要輸出設計選型，配色方案，風格定位，設計稿等等。
開發工程師需要輸出開發選型、數據庫結構設計、接口文檔、開發操作文檔等等。
測試工程師需要輸出測試用例、測試方案、測試結果報告等。
目前太多PM會局限于各類文檔模闆，追求文檔的完整度美觀度等。但在這裡，阿境要說的是，文檔存在的意義，在于使得項目更加規範、有條不紊地進行下去。
文檔在這當中隻是一個傳達信息的介質，之所以選擇文檔來代替口頭，是因為文檔能夠更好地留存及記錄。而隻要能夠達到目的，明确了這點，文檔具體的展現形式，樣式就不那麼重要了。
最适合自身公司及業務需求的文檔，才是好文檔。
提到了項目過程跟蹤的重要性，那麼問題來了，如何進行項目跟蹤？一個比較重要的措施，便是例行項目會議。
項目會議可分為每日站會跟周會。作用除了能夠管理項目，也可以管理項目當中每個角色的開發狀态。當然，這邊的管理并非指傳統意義上的管理者，這是由于互聯網行業，産品經理/項目經理可以看作是一個總的牽頭人，可謂是産品的靈魂。（自賣自誇一下哈哈哈）
每日站會
在每日站會上，不同的角色所需要關注的點也不同。
1、産品經理，可在項目看闆上，整體介紹每個項目目前的進展情況，與預期的差别，着重點在于每個項目整體的進度是否符合原先的項目排期。
2、設計師的重點，則在于目前手頭項目的頁面數量及美觀，由于設計方面包含了大量的主觀性，所以設計出來的産品，是否能夠滿足目标用戶（使用者/産品/甲方等）的要求，在目标用戶提出要求之後，加上修改的時間是否能夠如期完成等。往往會遇到一個情況，設計師用兩周的時間完成了設計稿，卻用了一周多的時間來進行設計稿的修改優化。這個情況難免會造成項目的延期。
3、開發人員的話，相對來說就比較複雜一些。除了關注不同項目的不同進度之外，還要着重于每個單一項目的進度。整體進度是否與項目排期表一緻；功能模塊是否按照優先級來完成；開發的時候是否遇到瓶頸；準備如何解決，若無法解決，與産品經理協商下，是否有Plan B等等問題，也是開發人員需要在每日站會上來進行彙報讨論的。
4、測試人員，關注點在于項目的完成情況，是否需要進行提前的模塊化測試；若整體完成，則測試進度是否如期進行等。
整體的每日站會時間，控制在5-15分鐘之間，快速高效是重點，不開無意義的會議。
重要的事情說三遍：
不開無意義的會議！
不開無意義的會議！
不開無意義的會議！
同時站會通常安排在每天上班後的半小時後，原因在于：剛開始上班的前半小時，每個人可以回顧一下昨天完成的任務，同時規劃下今天的任務安排，讨論下遇到的任務難題，如此也能使站會更加有意義，形式化的每日站會是不提倡的。
每周會議
而每周會議，與每日站會不同的是，着重點不在于關注項目本身，需盡量脫離各個項目的細節點（防止陷入細節讨論，耽誤時間），以宏觀的角度來考慮整體的項目進度及情況。
上文提到，有每日站會，每周周會，那麼同樣的，也相應會有日報跟周報，如何寫好日報跟周報是個老生常談的話題，也有許多大佬在他們的分享，這邊就不提了。
對于每個崗位，日報跟周報都是及其重要的，但是對于不同的崗位，寫日報跟寫周報的方式也全然不同。日報跟周報在一定程度上，是寫給自己看的（但其實往往都被要求發送上級領導審核），一旦成為了任務，那麼，便可能産生應付的情況，那麼意義也不大了。
當開發小哥完成代碼之後，需要進行冒煙測試後，再給到專業的測試人員。
程序員進行自測是對自己所寫模塊的進一步檢查，這樣可以使對該模塊的邏輯更加明确，同時加深對于該模塊的記憶，并且可以最大程度确保每個模塊程序書寫的正确性。
UI 驗證是由UI設計師來驗證當前的系統UI是否能夠達到預期的效果。
UI驗證是當前頁面UI還原度的一個重要證據。UI驗證是檢測當前頁面能否做到UI圖級别的視覺效果，以及開發人員是否按照UI設計師的界面需求進行實現的一個重要準則。
産品驗收是産品經理在項目交付前進行最後需求與程序開發是否統一的過程。
産品經理進行驗收是對整體系統流程的一個把關，也是對當前系統一次總的檢查，在驗收過程中需要綜合UI驗證以及測試時的一個結果來确認該産品經理在驗收後是否可以交付該系統。
測試工程師需要進行功能測試、性能測試、兼容性測試、壓力測試、回歸測試，這邊隸屬測試工程師的範疇，這邊不再過多贅述。
在一個項目結束之後，必然要進行項目文件的留檔記錄、包括但不限于項目需求文檔（PRD）、驗收文檔、測試報告、數據庫設計文檔、項目實施總結報告、産品使用說明手冊等文檔。
原則上，文檔涉及到項目生命周期當中的所有文件，PM在項目過程當中需要合理地進行分類及保管，以便後續項目疊代、複盤使用。
具體需要到什麼程度的文檔，各公司要求各異，作為産品，尋求一個平衡點即可。
項目複盤是每個項目的極其重要，卻又容易被忽略的步驟。
項目複盤的四大步驟：收集問題、分析問題、讨論問題、解決問題。
這邊不過多贅述，感興趣的可關注阿境（公衆号：夢想家阿境），同阿境一起聊聊。
04項目管理中的幾個注意點項目管理由人來管理，那麼，“人”在項目這個過程當中，尤為重要。
“水能載舟，亦能覆舟。”項目比作船，那麼人便是水。人促使了項目的推進，但在某些情況下，也能夠導緻項目的失敗。
作為項目管理者，不僅僅是要關注項目本身狀态進程，同時也要關注團隊成員當中，每個人的狀态，包括效率、情緒等方面。
對于這點來說，較難細化，也沒有具體的方法論，需要朋友們切身去體會下。（有興趣的可同阿境來讨論交流）
項目管理工具市面上包含了TAPD、jira、禅道等等，項目因其體量不同，公司因其流程不同，人員因其性格不同，都造成了項目管理的差異。
明确項目管理的目的才是項目管理者要關注的點：在規定的時間内保質保量的完成項目目标。那麼，在這個結果之前，使用什麼方法論，使用什麼工具，就都較為次要了。
切勿過于迷信工具以及方法論，他們存在的意義，是為了更好地幫助項目管理者完成項目，提高項目管理的效率。
作為項目管理者，當然是希望項目能夠如期、保質保量地完成。
但往往因為各類原因，沒辦法如願，那麼在一開始的時候，就需要做好項目延期的準備，出現風險之後的預案，避免驚慌失措的情況。
因為人員效率、外界原因導緻的項目延期，那麼可以适當調整需求，将較難的需求，換個方式實現。舉個例子：開發某平台，來不及做客服功能，可考慮對接第三方客服，若還是來不及，彈出客服的聯系方式暫時應急下。一個功能按照複雜程序來做可做數個月，按照簡單程序來做可能幾個小時就能完成。
那麼，項目的時間也因需求複雜程度而定，把控好這個平衡點，是産品經理需要做的。
寫在最後“不想當将軍的士兵不是好士兵，不想管項目的PM不是好PM。”
一個好的PM，做好自己産品規劃的同時，也需要兼顧部分項目管理的任務，即使團隊中有項目經理這個角色。
項目的運作是否能夠順利，在于是否有一個好的項目管理。
而項目管理也并非流于理論，需要在實踐當中去不斷調整。由于項目所處的狀态、個人所處的公司環境不同，每個項目的管理方法也有所區别。阿境隻是希望從自身的經驗及見解，能夠給到各位小夥伴一點啟發，靈活的運用在自身的項目當中。
也希望各位産品朋友在跟團隊夥伴們說到“明天上線”的時候，大家的反應不再是“什麼鬼”“不行”，而是“問題不大”“妥妥的”之類的回複。
願從此沒有上線難的難題。（阿境祝福看到這篇文章的你們~）
另：給阿境的朋友們附上自己整理的項目管理知識地圖，可保存領取。（需要高清版的可在公衆号回複“項目管理”領取）
文章來自社區簽約作者：（公衆号）夢想家阿境
,更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!
zpostcode 
Recruit 
weather 
mreligion 
Yellowpages 
sport 
constellation 
shopping 
name 
game 
directory 
literature 
Word 
tour 
furnish 
Lottery 
tftnews 
lyrics 
News 
digital 
car 
dir 
Edu 
Finance 
