編輯導(dǎo)語：產(chǎn)品經(jīng)理要如何推動項目的順利完成，協(xié)調(diào)好團隊內(nèi)關(guān)系，助推產(chǎn)品落地？這要求產(chǎn)品經(jīng)理發(fā)揮職能，做好項目管理。那么，產(chǎn)品經(jīng)理如何才能做好項目管理？本文作者結(jié)合案例進行了詳細解讀，一起來看一下吧。

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

一個段子說，程序員開大會，產(chǎn)品經(jīng)理還能安安穩(wěn)穩(wěn)地坐著，是因為外面有安保。

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

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

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

一、項目管理簡述

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

1. 概念

項目是指為創(chuàng)造獨特的產(chǎn)品、服務(wù)或成果而進行的臨時性工作，項目是為了組織的經(jīng)營需要與戰(zhàn)略目標(biāo)服務(wù)的（PMBOK指南）。

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

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

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

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

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

1）在項目啟動和規(guī)劃時

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

2）在項目執(zhí)行過程中

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

3）在團隊建設(shè)中

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

……

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

3. 項目管理4種類型

如何把項目管理的十大領(lǐng)域組織起來，建立恰當(dāng)?shù)墓芾砹鞒毯腕w系？項目管理理論也提供了4種項目管理生命周期的類型（PMBOK指南）：

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

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

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

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

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

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

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

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

• 數(shù)學(xué)老師希望你在暑假期間進行了練習(xí)就可以，要求的是總量；
• 語文老師希望你完成一篇優(yōu)秀的作文，會通過過程的監(jiān)管要求質(zhì)量；
• 英語老師希望你每天練習(xí)一點，確保英語的語感和保持持續(xù)學(xué)習(xí)的習(xí)慣；
• 科學(xué)老師希望你不斷突破創(chuàng)新，提升創(chuàng)造力。

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

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

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

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

“知己知彼，百戰(zhàn)不殆”，想要管理互聯(lián)網(wǎng)項目，還是先看看互聯(lián)網(wǎng)項目的特點。

二、淺談互聯(lián)網(wǎng)項目

1. 特點

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

互聯(lián)網(wǎng)的項目管理，由于行業(yè)、產(chǎn)品和用戶特征，具備以下3個方面的特點：

1）節(jié)奏上，“小步快跑、快速迭代”是大多數(shù)互聯(lián)網(wǎng)項目的共識。

風(fēng)口的瞬息萬變、市場的迅速搶占、競爭的分秒必爭都要求互聯(lián)網(wǎng)的項目需要快速推進、實時反饋和迅速調(diào)整，要勇于“擁抱變化”。

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

例如小米的MIUI系統(tǒng)，操作系統(tǒng)每周更新，根據(jù)米粉的使用意見快速調(diào)整，第二個周五再推送一個新的版本，如此往復(fù)，幾乎從不間斷。這也是此前很熱門的概念“互聯(lián)網(wǎng)思維”的內(nèi)涵之一。

2）周期上，互聯(lián)網(wǎng)的項目往往和運營分不開，這里的運營不是指用戶運營、內(nèi)容運營、活動運營等，是指產(chǎn)品本身的運營。

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

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

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

同時，不同角色的開發(fā)人員，前端、后端、算法、測試、運維、質(zhì)量等，分屬不同的組或者部門，是再正常不過的現(xiàn)象。雖然項目管理本身就需要協(xié)調(diào)項目人員所屬的職能部門與項目之間的關(guān)系，但互聯(lián)網(wǎng)行業(yè)這種產(chǎn)品經(jīng)理要承擔(dān)項目管理的工作但往往沒有明確授權(quán)、項目參與人員所屬職能部門繁雜的情況，也是獨具特色。

2. 互聯(lián)網(wǎng)項目管理要解決的問題

傳統(tǒng)的項目管理要解決的問題，互聯(lián)網(wǎng)的項目管理中也會遇到，那個性化的問題會有哪些呢？用“互聯(lián)網(wǎng)”的語言，來轉(zhuǎn)化一下互聯(lián)網(wǎng)項目管理中、產(chǎn)品經(jīng)理需要聚焦的問題：

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

相信回答好這些問題，并且就問題的解決辦法與開發(fā)同學(xué)達成一致，產(chǎn)品經(jīng)理就可以和開發(fā)同學(xué)建立一段平等的關(guān)系，開啟安全系數(shù)高、甩鍋扯皮少的幸福工作時光。

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

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

基于互聯(lián)網(wǎng)項目的這些特點，哪種生命周期類型更適合產(chǎn)品經(jīng)理去進行項目管理呢？

三、互聯(lián)網(wǎng)項目管理范式選擇

1. 預(yù)測型生命周期管理與敏捷型生命周期管理

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

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

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

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

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

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

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

客戶合作而不是合同談判

應(yīng)對變更而不是遵循計劃

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

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

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

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

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

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

敏捷在10大知識領(lǐng)域中的應(yīng)用：

2. 范式的選擇

那互聯(lián)網(wǎng)的項目管理到底是選擇敏捷還是預(yù)測？

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

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

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

互聯(lián)網(wǎng)產(chǎn)品的項目管理，混合可能是常態(tài)，完全的預(yù)測型或者完全的敏捷，也有一些適用場景。預(yù)測和敏捷最根本的差別，是需求是否明確，需求能否明確的原因，是項目追求的價值。

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

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

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

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

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

四、項目管理實踐

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

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

1. 理念敏捷

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

態(tài)度上，擁抱變化。

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

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

團隊建設(shè)上，透明、溝通、共建。

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

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

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

目標(biāo)確定上，價值為導(dǎo)向，通過經(jīng)常的交付不斷實現(xiàn)價值。

將項目的目標(biāo)定義為實現(xiàn)業(yè)務(wù)價值，就不僅僅是要求按時完成，而是注重效果，必要時甚至可以犧牲時間。

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

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

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

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

過程可控的第二個方面，是有完善的流程，從啟動-規(guī)劃-執(zhí)行-監(jiān)控-收尾的5大過程組入手，來拆解一個完善的互聯(lián)網(wǎng)項目管理流程需要的環(huán)節(jié)：

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

具體有兩個環(huán)節(jié)，調(diào)研和立項。通過充分的調(diào)研，建立對市場、用戶、競品的全面了解，闡明是什么、為什么、怎么樣的問題，調(diào)研的結(jié)論是立項的依據(jù)。在通過立項評審、成功立項后，產(chǎn)品就可以進入規(guī)劃階段，其實在多數(shù)情況下，啟動階段已經(jīng)完成了一部分規(guī)劃的工作，不過啟動階段的規(guī)劃，多是宏觀層面的預(yù)期的業(yè)務(wù)目標(biāo)、大的產(chǎn)品發(fā)布節(jié)奏、技術(shù)和產(chǎn)品架構(gòu)等等。

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

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

這兩部分對產(chǎn)品同學(xué)來說，對應(yīng)兩個流程的工作：產(chǎn)品路線圖的設(shè)計，和具體版本的產(chǎn)品文檔的輸出。

產(chǎn)品文檔作為后續(xù)設(shè)計、開發(fā)、測試等環(huán)節(jié)的工作依據(jù)，需要細節(jié)完整、描述清晰。完成了產(chǎn)品文檔，就可以組織需求評審，需要全部相關(guān)同學(xué)參加，在評審會上提出產(chǎn)品和實現(xiàn)層面的相關(guān)問題，探討解決方案。

文檔的完善和評審可能是一個多輪循環(huán)的過程，除了產(chǎn)品方案評審?fù)?，還涉及到設(shè)計圖評審、技術(shù)評審、測試用例評審，由對應(yīng)崗位的同學(xué)完成，產(chǎn)品經(jīng)理協(xié)助組織評審會議。

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

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

執(zhí)行階段——少變更、多關(guān)注，這6個字是送給產(chǎn)品同學(xué)的“6字箴言”。

執(zhí)行階段的主要工作是設(shè)計、開發(fā)和上線，產(chǎn)品同學(xué)的主要工作是跟進進度，發(fā)揮項目管理的職責(zé)，溝通協(xié)調(diào)，同時在需要時去給各個環(huán)節(jié)的同學(xué)闡釋需求。這個過程中，不建議對各崗位專業(yè)領(lǐng)域的內(nèi)容進行過多的干涉，例如手戳設(shè)計師的屏幕，質(zhì)疑程序員的代碼不夠完美，都是不推薦的、有損“人身安全”的高危行為，要對大家的專業(yè)能力有基本的信任。

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

監(jiān)控階段——重質(zhì)量、擔(dān)責(zé)任，重質(zhì)量是對質(zhì)量的重視，擔(dān)責(zé)任是產(chǎn)品同學(xué)也要為最終結(jié)果負責(zé)，而不僅僅是測試、質(zhì)量等崗位的同學(xué)的工作。

質(zhì)量意識應(yīng)該貫穿整個項目的始終，從規(guī)劃時對質(zhì)量標(biāo)準的設(shè)定、測試文檔的撰寫，到執(zhí)行中為滿足質(zhì)量標(biāo)準進行的工作，以及監(jiān)控環(huán)節(jié)的質(zhì)量控制和測試。

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

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

此外，按照互聯(lián)網(wǎng)產(chǎn)品逐個版本迭代的節(jié)奏，這個版本的收尾意味著下一個版本的開啟，控制好中間的銜接關(guān)系，適當(dāng)預(yù)留時間等待業(yè)務(wù)和用戶側(cè)反饋問題、決定是否在下個版本優(yōu)先處理，有時候是非常必要的。

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

3. 回看互聯(lián)網(wǎng)項目管理的5個問題

介紹完了流程，再回頭看之前第二部分，產(chǎn)品同學(xué)可能困惑的互聯(lián)網(wǎng)項目管理中的5個問題：

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

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

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

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

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

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

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

影響范圍大、變更難度高的、變更可能性小的決策，要早做，如影響到了技術(shù)路線、頂層設(shè)計、頂層架構(gòu)等技術(shù)層面的規(guī)劃，早做的原因，是這依賴這些決策結(jié)論需要盡早開展技術(shù)調(diào)研，且決策周期內(nèi)不會產(chǎn)生很大的技術(shù)突破，沒有變更的空間，就可以早決定、早啟動。

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

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

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

產(chǎn)品同學(xué)要提供哪些必要的文檔？從上述的5個過程中進一步總結(jié)一下。

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

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

執(zhí)行和監(jiān)控階段，需要的文檔主要是《變更記錄》，以及上述《產(chǎn)品需求文檔》的更新，要盡可能及時、詳細地對變更和調(diào)整進行記錄，便于拉齊信息，團隊協(xié)作。

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

需求，變不變——控制需求變更，變更盡可能少影響當(dāng)前的開發(fā)工作。

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

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

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

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

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

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

如何避免項目的延期，需要在排期預(yù)估的環(huán)節(jié)就進行把控，時間的預(yù)估要合理，對完成任務(wù)需要的時間、可用于開發(fā)的時間、其他影響因素等充分考慮，一旦形成排期，就是承諾，盡量不延期，在預(yù)設(shè)好的時間內(nèi)完成對應(yīng)的工作。

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

五、總結(jié)

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

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

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

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

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

本文由 @小小晶 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議。