編輯導語：產品經理要如何推動項目的順利完成，協調好團隊內關系，助推產品落地？這要求產品經理發揮職能，做好項目管理。那么，產品經理如何才能做好項目管理？本文作者結合案例進行了詳細解讀，一起來看一下吧。

專家說，在一段關系中如果小心翼翼，那可能就離分開不遠了?？善a品經理和程序員這一個“打打殺殺”的組合，分又分不開。

一個段子說，程序員開大會，產品經理還能安安穩穩地坐著，是因為外面有安保。

程序員們只看到了產品經理提需求時候的指指點點、喋喋不休，往往注意不到產品經理面對老板每一個需求都要高優時的抓耳撓腮、面對用戶客戶提出五彩斑斕的黑時的無奈但還得和藹的人格分裂、面對用戶明知道你就是個賣肉夾饃的非讓你賣給他一個熱狗時的語言匱乏。

對產品經理來說，如何和程序員和平共處、順利地推動項目按時完成？如何在加需求、調需求、改BUG、催進度時不被“暴揍”？如何能避免隔壁工位的程序員不在心里或者行動上給自己帶來“人身傷害”？

做好項目管理，或許能解決這些問題。

一、項目管理簡述

談到如何做好項目管理，先來看看什么是項目。

1. 概念

項目是指為創造獨特的產品、服務或成果而進行的臨時性工作，項目是為了組織的經營需要與戰略目標服務的（PMBOK指南）。

獨特性、臨時性、漸進明細是項目的三大特點。

獨特性是指每一個項目都是獨一無二的，即使是一樣的OA系統，項目也會因為客戶的不同、人員的不同而具有獨特性。臨時性是指項目有明確的開始和結束的時間，持續的維護是運營的工作，已經超出了項目的范疇。漸進明細是指項目的成果性目標是逐步完成的，項目前期只能粗略定義或整體定義，需要隨著項目的進行逐漸完善和精確。

項目管理，是將知識、技能、工具和技術應用于項目活動，以滿足項目要求（PMBOK指南）的工作。

2. 項目管理要解決的問題

項目的3個特點，闡明了項目是一個有始有終、獨一無二、逐漸完善和推進的過程。尤其是項目的漸進明細也是在說項目是變化的，變化就意味著項目具有不確定性，存在風險，這也就是之所以需要項目管理的原因。具體來說，項目執行過程中的風險會有以下：

1）在項目啟動和規劃時

• 如何鼓勵相關方、尤其是客戶和高層參與項目的計劃與決策，確保項目結果符合他們的預期？
• 如何引導相關方就目標達成一致？
• 如何獲得相關方包括客戶、高層、項目組人員對項目的承諾，確保提供必要的支持？

2）在項目執行過程中

• 如何及時掌握項目的進度和狀態、確保項目按時交付，而非在即將結束時才發現項目要延期？
• 如何對需求的優先級進行排序，協調好不同相關方、不同需求之間的沖突？
• 如何應對來自客戶、高層變更要求，以及項目團隊改變方案和進度等的訴求？
• 如何解決項目人手不足、資源匱乏的問題，或者資源可使用情況發生變化的情形？
• 如何在問題和風險產生式，推動相關的調整和整改落地？

3）在團隊建設中

• 如何提升團隊的溝通、協作與配合？
• 如何建立互信、尊重、有責任感的項目團隊文化？

……

如何去解決這些問題，項目管理的相關理論劃分了十大知識領域，涵蓋了項目管理的方方面面：整合管理、范圍管理、進度管理、成本管理、質量管理、溝通管理、風險管理、相關方管理、溝通管理、采購管理。

3. 項目管理4種類型

如何把項目管理的十大領域組織起來，建立恰當的管理流程和體系？項目管理理論也提供了4種項目管理生命周期的類型（PMBOK指南）：

以一個布置和完成暑假作業的例子來具體來體會一下這幾種類型：

1）放暑假了，數學老師一口氣布置完了所有的暑假作業，開學的第一天按時交，過程中老師不會檢查——這個是預測型，也叫瀑布型，最終開學你交了作業就可以。

2）放暑假了，語文老師留了一篇作文，要求你先選題，交給她看了、確認了之后，再列提綱，提綱她也得檢查和修改，然后你再寫成作文，并且修改到她認為符合標準——這個是迭代型，中間需要反復檢查修正，但只有最后一次她確認了的作文才能算你的作業。

3）放暑假了，英語老師說作業她每天早上8點發在群里，晚上8點得完成——這個是增量型，每天布置的作業就是給定增量，每天交作業就是交付。

4）放暑假了，科學老師說，每人做一個有新意的科學小發明，他每兩周周檢查一次，你決定做一個遙控汽車；于是第一個兩周你的汽車成型了，老師看了還行但是建議你把車身做大一點以便放進更大容量的電池。

第二個兩周你的車身放大了車也能遙控跑起來了，老師說現在你的車只能往前走，需要包含倒車的功能，現在別的做遙控汽車的同學是水陸兩棲的方案，你可以加上飛行的功能，有新意又不雷同……

如此不斷調整，到開學你交的作業，是一輛超長續航、能直走轉彎后退、車門不僅長得像翅膀還能像翅膀一樣帶著車飛、具備了攝像功能、自帶GPS定位的遙控汽車——這個是敏捷型，原始需求是粗略的，每次給老師看的都是成型的作品，不斷朝著有新意的目標在調整交付。

選擇哪種類型的項目管理方法，取決于項目的特點和目標。就像上邊暑假作業的項目：

• 數學老師希望你在暑假期間進行了練習就可以，要求的是總量；
• 語文老師希望你完成一篇優秀的作文，會通過過程的監管要求質量；
• 英語老師希望你每天練習一點，確保英語的語感和保持持續學習的習慣；
• 科學老師希望你不斷突破創新，提升創造力。

從上述4種類型的對比中也可以看到，預測型和敏捷型是4類中的兩個極端。

在實際的應用中，預測型的項目管理方式適用于需求明確、產品清晰、不需要變更、需要整體交付的行業，如建筑、制造、通信、能源等等。敏捷型的項目管理方式適用于速度變化快、復雜性高和風險高的行業，敏捷的誕生，就是基于軟件行業的管理需求，去滿足組織能夠快速產生滿足市場需求的產品，通過靈敏的調整保持競爭力和占有市場份額的需求。

既然敏捷是隨著軟件行業的興起而誕生的，早在2006年左右，敏捷就被引入中國，且有大量企業進行了敏捷實踐。那在互聯網行業的項目管理中，是否可以直接選擇敏捷的項目管理方式？

這可能需求打個問號。產品經理如果對著開發同學說，我們要敏捷，要應對變化，所以這個需求得改一下——這句話說完，你可能就把自己置于了一個十分危險的境地。

“知己知彼，百戰不殆”，想要管理互聯網項目，還是先看看互聯網項目的特點。

二、淺談互聯網項目

1. 特點

與傳統行業相比，互聯網是輕資產的行業，投入的主要是人力資源，試錯成本更低，鼓勵創新，走了彎路只是消耗了一些人力和時間；同時，互聯網產品開發成本低，不存在物料的消耗，產品的迭代更新速度快、市場競爭激烈；在用戶層面，互聯網和用戶擁有更高的互動性，可以根據反饋實時調整產品。

互聯網的項目管理，由于行業、產品和用戶特征，具備以下3個方面的特點：

1）節奏上，“小步快跑、快速迭代”是大多數互聯網項目的共識。

風口的瞬息萬變、市場的迅速搶占、競爭的分秒必爭都要求互聯網的項目需要快速推進、實時反饋和迅速調整，要勇于“擁抱變化”。

那在項目的節奏上，就需要盡快上線可用的產品，不斷在適應和接收的反饋中迭代，以最小的成本和有效的方式驗證產品是否符合用戶需求，靈活調整方向。

例如小米的MIUI系統，操作系統每周更新，根據米粉的使用意見快速調整，第二個周五再推送一個新的版本，如此往復，幾乎從不間斷。這也是此前很熱門的概念“互聯網思維”的內涵之一。

2）周期上，互聯網的項目往往和運營分不開，這里的運營不是指用戶運營、內容運營、活動運營等，是指產品本身的運營。

項目是臨時性、獨特性的工作，而運營是持續的、重復性的工作，而在互聯網團隊中，項目往往是不斷迭代的，交付一個版本后，產研團隊不僅要專注于后續版本的開發，也需要解決之前的版本中遺留的問題，甚至是進行使用答疑，在執行時間上，項目時間和運營時間也沒有辦法完全割裂而往往是并行，甚至解決線上問題（運營）的優先級是高于開發新的版本（項目）的。

3）人員上，首先是項目經理這個角色，很大情況下由產品經理充當。在互聯網行業，往往是針對跨部門的大項目、或者是面向企業用戶（TO B）的業務，才會有項目經理的崗位，而眾多的面向C端的業務、面向企業內部的產品和服務、部門或者小組之內的項目，是不會有專門的項目經理的，產品經理需要同時承擔起項目經理的角色，推動流程和進度。

其次是項目的成員，尤其是開發人員，同時參與多個項目、或者如上一點所說的那樣，即負責開發又負責運營，也是常態。

同時，不同角色的開發人員，前端、后端、算法、測試、運維、質量等，分屬不同的組或者部門，是再正常不過的現象。雖然項目管理本身就需要協調項目人員所屬的職能部門與項目之間的關系，但互聯網行業這種產品經理要承擔項目管理的工作但往往沒有明確授權、項目參與人員所屬職能部門繁雜的情況，也是獨具特色。

2. 互聯網項目管理要解決的問題

傳統的項目管理要解決的問題，互聯網的項目管理中也會遇到，那個性化的問題會有哪些呢？用“互聯網”的語言，來轉化一下互聯網項目管理中、產品經理需要聚焦的問題：

• 文檔，寫不寫？需要寫哪些、需要多詳細？
• 需求，變不變？變更對已經完成的工作和排期造成影響如何處理？
• 排期，延不延？需求不能按時完成怎么辦？
• 規劃，做不做？需要做到什么程度？
• 決策，早或晚？盡早做決策、方便制定方案，還是盡可能晚做決策、應對變更？

相信回答好這些問題，并且就問題的解決辦法與開發同學達成一致，產品經理就可以和開發同學建立一段平等的關系，開啟安全系數高、甩鍋扯皮少的幸福工作時光。

當然作為一名產品經理，你可能還會有其他的問題，包括我需要做一個什么樣的產品？產品是否有市場競爭力？是否能滿足用戶需求？是否能為公司帶來收益？… … 等等的這些，并不在我們項目管理的討論范圍之內。項目管理是提供“正確地做事情”的方法，而上述這些問題，是“做正確的事情”的范疇，需要在 OKR / KPI 制定環節去解決。

下文所有的討論，也是假設你已經知道做什么了，只是需要知道怎么做，來展開。

基于互聯網項目的這些特點，哪種生命周期類型更適合產品經理去進行項目管理呢？

三、互聯網項目管理范式選擇

1. 預測型生命周期管理與敏捷型生命周期管理

預測和敏捷是4中項目管理類型的兩端，不妨就以這兩種類型展開討論。選擇預測型還是敏捷型的項目生命周期管理類型，再來對比一下預測和敏捷的區別：

預測型和敏捷型的項目管理方式，在需求是否固定、執行次數、交付次數、目標方面都有差異。如何選擇需要在上述幾個維度都進行考量，但根本的還是要從需求入手。從需求的不確定性、交付的不確定性——即技術程度的不確定性兩個方面去構建（敏捷實踐指南）坐標，得到如下模型：

需求和實現的技術如果不確定性較低，使用于線性的方法——比如預測型；如果兩者的不確定性都較高，那可能就是一個混亂的項目，需要重新評估捋順；如果都是一個居中的水平，可以用自適應的方法——比如敏捷型。

預測和敏捷在項目管理中的區別，從《敏捷宣言》中就可明確知曉：

我們正在通過親自開發和幫助他人開發，發現開發軟件的更好方法。通過這項工作，我們開始更重視：

個體及互動而不是過程和工具

可用的軟件而不是完整的文檔

客戶合作而不是合同談判

應對變更而不是遵循計劃

也就是說，右欄的項目固然有價值，但我們更重視左欄中的項目。

簡言之，敏捷對過程和工具、文檔、合同、計劃的關注程度，是低于互動、成果、合作和變化的。敏捷擁抱變化，在需求不明確的時候，在較短的周期內開發出可用的產品，幫助明確需求和調研市場，這也就是產品開發過程中的MVP（Minimum Viable Product，最小可用產品）概念。

但同時，敏捷并不意味著隨意和無序。在敏捷實踐中，也存在著諸多的框架，如精益、看板、水晶、極限編程、Scrum等。

雖然從理念到流程上，敏捷和預測的項目生命周期類型存在諸多差異，但既然都是項目管理，兩者都符合“知識、技能、工具和技術的應用”的項目管理概念。即使敏捷對流程和文檔進行了諸多的裁剪，關鍵的控制還是必不可少的。例如不重視文檔不代表沒有文檔，必要的文檔如產品需求文檔，還是要有的。項目管理的5大過程組和10大知識領域，兩者都會覆蓋到。

預測型項目與敏捷項目中的5大過程組：

整合管理、范圍管理、進度管理、成本管理……等10 大知識領域，在預測型的項目管理中，有完整的輸入、輸出文檔，使用的工具和技術。敏捷項目同樣離不開這10個領域，但關注的重點有所不同。

敏捷在10大知識領域中的應用：

2. 范式的選擇

那互聯網的項目管理到底是選擇敏捷還是預測？

前面部分也分析過，互聯網的項目有3大特點——節奏上的“小步快跑、快速迭代”、周期上的開發與運營兼顧、人員上的非項目制團隊，基于這些特點，適用預測或敏捷，都存在一些障礙。

節奏上的特點——需求的不斷變化和快速的迭代，是使用預測型項目管理方式的障礙，敏捷比較能適應這種節奏。而周期和人員上的特點，兩種管理方式好像都難以招架。

在實踐中，很多公司的項目開發會選擇用看板管理故事點從需求到上線的過程，看板、用戶故事，其實都是敏捷中的工具。還有一種比較常見的互聯網產品開發管理流程，從調研到評審、設計、開發、測試、上線，再逐一版本進行迭代，很多情況下是在對傳統的預測型流程進行大幅度裁剪的基礎上，視情況混合敏捷理念的管理體系。

互聯網產品的項目管理，混合可能是常態，完全的預測型或者完全的敏捷，也有一些適用場景。預測和敏捷最根本的差別，是需求是否明確，需求能否明確的原因，是項目追求的價值。

如果項目的目標是按時上線，那可以用預測型的方法，對過程進行嚴格的管理。而需求存在變更可能性的項目，不應該以按時上線為目標，而是要追求業務價值的實現，順應變化適時調整，才能做到隨價值而變。

一些交付型的項目，如面向B端企業的軟件系統交付，尤其是一些傳統行業的信息化、流程管理系統，項目承接的是甲方的需求，產品和研發團隊作為乙方，基本適用于預測型的管理方法。

業務支撐型的項目，尤其是新業務的探索，需要在激烈的市場角逐中獲得競爭優勢，如開發一個元宇宙社區，那項目的推進可能就需要敏捷起來。

這個項目有著激進的時間限制——早一天有可用的產品就能早一天搶占用戶、有著較高的新穎性——產品形態需要不斷探索以深挖用戶需求、有一定的技術復雜度——涉及5G/通信/云計算/區塊鏈/VR/AR等諸多快速發展中的技術的綜合應用，此類項目就適用于敏捷型的項目管理方式，擁抱變化是必要且能獲得最大價值的。

大多數的互聯網項目，不完全符合以上兩種絕對的場景。畢竟，做軟件交付和探索新業務只是行業內的少數，大多數還是已經發展中的項目，需要維護，但又沒有創新那么時間緊急。如何綜合敏捷型和預測型項目管理的理念和工具，擁有一套適合產品經理進行項目管理的方法論？在下一部分，提供一種實踐。

四、項目管理實踐

想要和寫代碼的同學“相談甚歡”，維護“其樂融融”的合作氛圍，每一次迭代都“功德圓滿”，產品經理不僅需要寫得一手好文檔，更需要于“潤物細無聲”處管理好項目。產品能力和項目管理能力，兩手都要抓，兩手都要硬。方案寫的再好、沒能按時上線，那也是紙上談兵；方案一塌糊涂，項目管理就注定困難重重，即便是磕磕絆絆上線了，其中的扯皮和后續的反復不然不會少。

項目管理怎么做？預測型和敏捷型的項目管理方法如何綜合利用？這里提供的這一實踐，不妨稱其為“理念敏捷、過程可控”。

1. 理念敏捷

敏捷是為軟件行業而生，在理念上也很貼合互聯網的實際。再回顧一下敏捷宣言：更重視個體及互動而不是過程和工具，更重視可用的軟件而不是完整的文檔，更重視客戶合作而不是合同談判，更重視應對變更而不是遵循計劃。敏捷管理的目標，是通過盡早持續交付有價值的軟件來滿足客戶的需求。在理念上的敏捷，可以從以下幾個方面入手：

態度上，擁抱變化。

這個變化，包括市場的變化、需求的變化、項目過程中的變化，甚至是人員的變化，將變化視作常態，不懼怕變化。

擁抱變化不是一句口號，而是基于完善的應對方案的底氣。面對變化，在方案設計時，產品同學需要對所有的情況充分考慮，選擇最適合當時需求的方案，但也要對后續的調整有充分的認知，在變化發生時能靈活地應對，接受來自技術同學的“挑戰”——他們是不喜歡變化的，需要有足夠分量的理由去說服。對變化的應對需要做好變更管理，對變更有清晰的記錄，方便回溯和應對人員變化的情形。

團隊建設上，透明、溝通、共建。

不僅是為了提升效率，也是讓團隊成員獲得參與感和體現價值感。除有特殊保密需求的項目外，產品和項目所有的信息應該是團隊內透明共享的，消除權限管控的隔閡，方便實時獲取，也是讓各個角色的同學從前因后果、前后左右去完成各自的工作。

溝通上，因為變化無處不在，充分的、頻繁的溝通非常必要，一定要鼓勵團隊成員在發現問題的第一時間和相關人員溝通，所有的不清晰、不確定都在第一時間澄清。共建不僅僅是共同完成項目，更是共同承擔責任，產品出現問題時，積極解決、重視復盤，不互相推諉。

做到透明、溝通、共建，離不開一些工具的應用，如利用線上文檔分享信息，通過固定會議和隨時的響應促進溝通，利用投票、頭腦風暴等工具進行團體決策，組織定期的團隊內知識分享加強交流等。

目標確定上，價值為導向，通過經常的交付不斷實現價值。

將項目的目標定義為實現業務價值，就不僅僅是要求按時完成，而是注重效果，必要時甚至可以犧牲時間。

價值實現應該成為團隊內部共同的信仰，成為何時交付、如何交付、是否接受變更的依據。不斷實現價值，在互聯網的項目中可以通過不斷的版本迭代來實現，通常的迭代周期2-4周，最長不超過6周，太長的周期也會放大延期的風險。越早交付可用的版本，就能越早去驗證市場需求和業務邏輯，更靈活地應對變化，為業務獲得競爭優勢。

2. 過程可控：基于5個過程組的流程和工作項

過程可控體現在兩大方面。一是對于變更，盡管我們強調靈活，但要控制迭代周期之內的變更，盡量放到迭代之間。

在規劃最新的版本時，需求是否已經明確應該作為優先級排列的依據之一，還需要細化的需求可以放到后續的版本。在版本開發的過程中，盡量不插入新的需求，避免影響現有的開發節奏，如果一定要插入，需要明確是延長上線時間、還是增加資源去完成，項目的整體節奏要相應調整，所有變更及時和成員同步。

過程可控的第二個方面，是有完善的流程，從啟動-規劃-執行-監控-收尾的5大過程組入手，來拆解一個完善的互聯網項目管理流程需要的環節：

啟動階段——全思量、嚴論證，通過全面的考慮和嚴格的論證，為后續的工作開一個好頭。

具體有兩個環節，調研和立項。通過充分的調研，建立對市場、用戶、競品的全面了解，闡明是什么、為什么、怎么樣的問題，調研的結論是立項的依據。在通過立項評審、成功立項后，產品就可以進入規劃階段，其實在多數情況下，啟動階段已經完成了一部分規劃的工作，不過啟動階段的規劃，多是宏觀層面的預期的業務目標、大的產品發布節奏、技術和產品架構等等。

在進入規劃階段前，如果是涉及到跨部門合作的項目，建議組織一次開工大會，拉齊所有關注項目、參與項目的人員的信息，獲得后續支持項目的承諾。

規劃階段——遠規劃、注細節，進入規劃階段，其實項目也就正式開始了，“凡事預則立，不預則廢”，一個好的規劃，應該是“十”字型的，既有橫向的長周期內的完整規劃，對項目的最終形態有設想，也包含了縱向的近期即將開展的工作和細節。

這兩部分對產品同學來說，對應兩個流程的工作：產品路線圖的設計，和具體版本的產品文檔的輸出。

產品文檔作為后續設計、開發、測試等環節的工作依據，需要細節完整、描述清晰。完成了產品文檔，就可以組織需求評審，需要全部相關同學參加，在評審會上提出產品和實現層面的相關問題，探討解決方案。

文檔的完善和評審可能是一個多輪循環的過程，除了產品方案評審外，還涉及到設計圖評審、技術評審、測試用例評審，由對應崗位的同學完成，產品經理協助組織評審會議。

評審會上確認后的各類文檔，可以作為排期的依據。如前文提到的，互聯網項目的參與人員往往是跨團隊、非專職，排期時，需要考慮到各個角色的可用時間、完成每個任務需要的工時，將突發情況充分考慮進去。

例如，前端同學完成這個版本需要5個工作日，但他同時負責多個項目，在本項目上的精力是50%，那前端需要的開發周期就是10個工作日。如果是涉及新技術或者有技術難度的項目，可以用三分法來預估時間：最快時間、最可能時間、最長時間，得出最終需要的時間。最終的排期可以繪制成甘特圖，預期和實際完成的時間用不同顏色表示，清晰地顯示進度。

執行階段——少變更、多關注，這6個字是送給產品同學的“6字箴言”。

執行階段的主要工作是設計、開發和上線，產品同學的主要工作是跟進進度，發揮項目管理的職責，溝通協調，同時在需要時去給各個環節的同學闡釋需求。這個過程中，不建議對各崗位專業領域的內容進行過多的干涉，例如手戳設計師的屏幕，質疑程序員的代碼不夠完美，都是不推薦的、有損“人身安全”的高危行為，要對大家的專業能力有基本的信任。

在進度的跟進中，應該注意跟進的節奏，把控好關鍵節點、又不過于頻繁，應該重視執行過程中的問題，要求大家在風險發生的第一時間同步，以便及時探討解決方案、判斷是否要調整原有的需求或排期。

監控階段——重質量、擔責任，重質量是對質量的重視，擔責任是產品同學也要為最終結果負責，而不僅僅是測試、質量等崗位的同學的工作。

質量意識應該貫穿整個項目的始終，從規劃時對質量標準的設定、測試文檔的撰寫，到執行中為滿足質量標準進行的工作，以及監控環節的質量控制和測試。

監控階段的工作和執行環節是交叉的，開發完成后需要提測，測試環節中發現的問題需要修復直至通過測試。整體的監控階段的工作是需要全部角色參與的，開發先自測、再提測，測試人員通過后，產品進行驗收，而且建議上線前后分別在測試和線上環境雙重驗收。

收尾階段——有始終、控節奏，完成上線并不是一個版本的項目工作的結束，收尾的工作包括向業務部門交付上線的版本，更新相關的使用文檔，此外還要對整個項目進行復盤，項目周期較短的可以簡單總結，回顧產品和項目執行中的問題，提出后續的改進方案，不斷完善產品和開發流程。

此外，按照互聯網產品逐個版本迭代的節奏，這個版本的收尾意味著下一個版本的開啟，控制好中間的銜接關系，適當預留時間等待業務和用戶側反饋問題、決定是否在下個版本優先處理，有時候是非常必要的。

如果此前的多個版本因為需求變更、周期緊張等原因，導致技術實現方案不夠完善，可能影響后續的使用，也建議在版本規劃時，在需求的節奏不那么緊張的情況下，適時考慮償還技術債，將此納入新的版本規劃甚至安排獨立的版本完成該項工作。

3. 回看互聯網項目管理的5個問題

介紹完了流程，再回頭看之前第二部分，產品同學可能困惑的互聯網項目管理中的5個問題：

1. 規劃，做不做？需要做到什么程度？
2. 決策，早或晚？盡早做決策、方便制定方案，還是盡可能晚做決策、應對變更？
3. 文檔，寫不寫？需要寫哪些、需要多詳細？
4. 需求，變不變？變更對已經完成的工作和排期造成影響如何處理？
5. 排期，延不延？需求不能按時完成怎么辦？

上述“理念敏捷、過程可控”的流程，其實已經包含了這5個問題的答案，但我們來進一步詳細說明一下。

規劃，做不做——肯定是要做的，這個毋庸置疑。

上文的規劃階段的工作流程，也闡明了規劃要做“十”字型的，橫向的長周期內的完整規劃，加縱向的近期即將開展的工作和細節。

進一步來做一些說明，規劃是要解決是什么、為什么、怎么做的問題，去幫助決策，對于是什么——要提供一個什么樣的產品或者服務，為什么——為什么要去做，需求未被滿足？市場空間巨大？戰略部署和探索？這兩個問題，要盡可能全面的考慮，這樣才能輔助決策者做出正確的決策，和為“怎么做”提供依據。

對于怎么做，建議有粗略的時間點即可，僅對近期要開展的工作項做細致規劃，這其實也貼合了項目本身漸進明細的特點，這么做有兩個好處，一是可以縮短規劃周期，盡快啟動項目，獲得先發優勢；二是需求是變化的，一開始做完所有的規劃，往往很難按照規劃執行，必然會經歷變更，那就如不邊做邊規劃。

決策，早或晚——要看決策的影響范圍。

影響范圍大、變更難度高的、變更可能性小的決策，要早做，如影響到了技術路線、頂層設計、頂層架構等技術層面的規劃，早做的原因，是這依賴這些決策結論需要盡早開展技術調研，且決策周期內不會產生很大的技術突破，沒有變更的空間，就可以早決定、早啟動。

而影響范圍小、變更相對簡單、且變更可能性大的決策，可以晚做，如功能和需求點這一類的業務規劃，這些對技術調研的要求不高，隨時可以開始，晚做決策不影響整體進度，反而可以進行充分的需求論證。

例如在項目立項時，對用戶數量、數據量級、數據更新頻率等會影響存儲和計算方式的決策，需要早期確定，方便技術調研和產品規劃同時開展。而一些諸如功能的優先級、模塊的呈現方式、交互方式等決策，可以晚做。偷偷地講，給客戶做方案，到頭來對方可能覺得還是第一版好，所以不妨壓縮一些決策的周期。

文檔，寫不寫——一定要包含必要的文檔。

產品同學要提供哪些必要的文檔？從上述的5個過程中進一步總結一下。

啟動階段，如果是從0到1的項目啟動，產品需要完成項目文件，例如《市場需求文檔》、《競品調研文檔》、《產品規劃文檔》等，作為項目的“頂層設計”，這些文檔除了是項目立項的保障，也是促進項目成員達成共識的工具，讓大家對項目的重要性、規劃有完整的認知。

規劃階段，產品同學需要完成整體的《產品路線圖》，每一個版本的《產品需求文檔》，以及評審之后的《排期表》，這幾個文檔用來確定各個版本的范圍和進度，《產品需求文檔》也是技術和測試同學產出《技術方案文檔》、《測試用例文檔》的范圍依據，規劃階段的文檔是必不可少的。

執行和監控階段，需要的文檔主要是《變更記錄》，以及上述《產品需求文檔》的更新，要盡可能及時、詳細地對變更和調整進行記錄，便于拉齊信息，團隊協作。

收尾階段，交付時通常需要提供和版本相匹配的《使用手冊》，復盤的前后也提供相應的《項目總結》文檔。

需求，變不變——控制需求變更，變更盡可能少影響當前的開發工作。

在“過程可控”的第一方面就強調了，對變更一定是要有控制的，無休止的變更就意味著項目永不結束。

不必要的變更是誰都不喜歡的。在項目正式開發前，也就是啟動和規劃階段，是完全的“理念敏捷”——擁抱變化、團隊開放、價值導向，這些階段中的需求變更，其實是通過充分的論證形成思想的碰撞，盡可能考慮到所有的因素、得到最佳的方案，為后續的“不變更”奠定基礎。

在這里需要把控的，就是時間問題，確保所有的論證在可控的時間內完成，不影響項目開始執行的時間。在項目進入執行階段后，變更應當盡量減少，新的需求如果合理就加入待辦列表，等下個版本規劃和排期時一起評估。

由于一些問題，如技術難以實現等，需要修改產品或者技術方案的，也盡量第一時間提出；如果是一定要緊急上線的功能，在評估影響可控可執行的情況下，也不要忘記對現有的排期和需求范圍做出相應調整。

排期，延不延——合理預估工作量，盡可能保障按時上線。

在一些情況下，項目的按時上線就是項目成功的重要標志之一，延期必然是不好的。

如何避免項目的延期，需要在排期預估的環節就進行把控，時間的預估要合理，對完成任務需要的時間、可用于開發的時間、其他影響因素等充分考慮，一旦形成排期，就是承諾，盡量不延期，在預設好的時間內完成對應的工作。

當然，合理即包括不過分壓縮，也包括不過分預留，不能為了“按時上線”就預留一個“充分得過頭”的時間。在項目過程中，一定會遇到需求變化、技術難度預估不足等問題可能導致延期，那就要在發現問題時盡早提出，以便盡早提供解決方案——增加人力、調整需求、還是延期，在上線的前一天通知大家項目會延期是不能接受的。

五、總結

通過對項目管理的介紹、互聯網項目的特點的分析、項目管理范式的選擇，本文給產品同學工作中與研發等角色進行溝通、推進項目上線提供了一套可用實踐——“理念敏捷、過程可控”。

學習理論不難，在實際的工作中，最困難的部分在于，如何讓項目團隊內的成員都接受這一套方法，尤其如果公司和團隊沒有明確的研發流程、發版制度的情況下。

那沒有管理職位，卻要進行管理職責的產品經理，要和技術崗位的同學們“和諧共處”，保護自己的“人身安全”，就需要通過潛移默化的影響，推進產品上線的流暢，于“潤物細無聲“處影響團隊，這考驗的就是產品經理項目管理的“軟實力”了。

實踐的落地是循序漸進的，所有流程的前提，不要忘記理念上的敏捷——注重個體、注重溝通，方法是拿來用的，指導和優化實踐，不是用來與人爭論的，不能強行灌輸“擁抱變化“的理念，也要說服開發同學放下”不能變更”的執念，大家共同的目標是，通過不斷的迭代盡可能快速地實現業務價值。

希望本文能和產品同學在項目管理上產生一些共鳴，愿世界和平、沒有延期。

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

題圖來自Unsplash，基于CC0協議。