對很多產品經理而言，特別是身處創(chuàng)業(yè)團隊，往往都是一身挑幾職，產品和項目，理不清理還亂。從本文開始，以產品經理的視角看待項目，以及如何管理項目。

接上篇。

四、合適的人與靠譜的計劃

幾乎每個項目都有人吐槽，太坑太扯淡。

實際上，項目之所以會扯皮，往往在前期就埋了下巨坑，隨著項目的進程問題越來越嚴重，直到不能收場。

在上文我們已經厘清了項目的幾個核心概念 ，我們知道要想做好一個項目首先要搞清楚項目利益相關方，組建合適的項目團隊，然后我們需要分解我們的項目任務，制定一個清晰的項目計劃，才能指導和推動項目的進展。

我們現(xiàn)在從案例來還原項目前期的挖下的坑：

A公司目前正在為一個醫(yī)院開發(fā)一套系統(tǒng)，現(xiàn)在項目按時間開發(fā)完成了，也做好了相關的培訓工作，但始終無法驗收，醫(yī)生說不好用，而且還有三個需求要變更，開發(fā)工程師下個月要離職了，各種問題層出不窮……

假設你是這個項目的項目經理，我們一起來看看你踩的雷。

1. 項目第一坑：“人”才是最坑的

你從銷售經理那里獲悉，這個項目是內科的科長最開始發(fā)起的，副院長也很支持。

你很開心，感覺這個項目牽涉的人比較少，就開始了這個項目，并且定期發(fā)送相關的進度報告：

隨著在醫(yī)院的了解越來越多，你發(fā)現(xiàn)醫(yī)院的關系越來越復雜，各種不配合扯皮的現(xiàn)象——很多沒必要的需要變更，培訓的效果也沒有看上去理想。

你認為這是院長負責的項目，一定大家都會支持；你以為給內科做了一次培訓，大家都會使用；沒想到培訓完之后他們還是反饋說系統(tǒng)不太好用。

這些問題，本質上就是項目開始階段想得太簡單，沒有能搞清楚相關方的利益關系。

這是項目的第一步，也是項目的關鍵一步。

多數(shù)情況下，一個項目有支持者，往往就有反對者；項目的支持者能讓項目錦上添花，但反對者往往決定成敗。

如果在項目開始階段，沒有找出那項目能夠施加積極和消極影響力的人，注定整個項目會很艱難。

同時，你還需要找到一個最具有推動力的關鍵人，對內爭取更多資源，對外擺平各種關系。

所以，這個項目的干系人需要更完整：

越是大型的項目，人的因素影響越大，也越難以把控。

那些決定項目成敗的，能出力的人，都應該是你的項目組成員，還有一些人，你需要TA掛一個虛職，并告訴及時告訴TA進展。

我們常常見到一個項目進行了一半，才臨時通知或者征調其他部分的人參與，帶來的問題就是溝通成本非常的高，過程完全不可控。

2. 項目第二坑：只有任務，沒有成果

項目的第二步，是要分解項目的具體工作任務，也就是要分配張三、李四分別要完成的工作。在PMP體系中這個叫WBS，在Prince2的體系中則強調的是PBS。

最直接的做法，通常都是根據“事項”來分解；畢竟我們需要把任務分配給不同的人來執(zhí)行，并根據這個任務來估算時間，確定進度。

所以最常見的分解方法就變成這個樣子：

但為什么這種分解方式會導致項目做到一半就會人員流失，士氣低下呢？

根源在于這種任務分解只關注了過程，沒有確定到底要做成什么樣，沒有邊界和具體的目標。

沒有驗收的標準，沒有衡量的指標，所有的人都在忙，忙到最后發(fā)現(xiàn)客戶不買賬。

比如項目計劃里面UI設計的是10天，為什么不是9天或者11天呢？要輸出多少個頁面？

科室培訓是培訓一天就可以了嗎？還是1小時就可以結束而且所有人都能熟練掌握？用戶向要在用戶登錄模塊里面添加一個找回用戶名的功能，要不要增加？

諸如此類的問題，隨時可能發(fā)生。

因為這種結構是沒有辦法落實到具體一個功能需要的耗時，所以會不會打亂整個計劃就說不太清楚。

僅僅知道什么時候做什么，對項目的成敗而言是沒有意義的，關鍵是結果是什么，沒有成果的努力，都是一種自嗨。

回顧前文 “ 如何用Axure輸出高質量的PRD？”，為什么會強調“故事”呢?

基于“用戶故事”來分解這個項目的任務——構建一套以用戶需求驅動的PBS，才能滿足用戶的需求，也才能真正估算一個可行的項目計劃，雙方也才能在一直的目標下推進具體的功能。

這是一個項目成果的護身符，當任意發(fā)起與PBS相違背的變更都會影響到項目的進度，界定了項目的邊界，為日后的項目進度規(guī)避了許多不必要的障礙。

因為在這種結構下，任何的變更都可能導致整個路徑的紊亂，從而項目失控。或者為了項目進度，投入更多的資源，或者友好協(xié)商推遲項目的進度。

搞不定人事，理不清邊界，是項目失敗的最關鍵因素，作為項目經理（有一些情況下是產品經理直接帶項目）務必保持清醒的頭腦。

五、項目節(jié)奏和潛在的風險

我們搞清楚了項目的利益相關方，理清楚了項目的范圍，要做什么工作也已經妥當?shù)陌才藕昧藢Ｈ素撠煟欢椖恳廊贿€會失控。

原因何在？

展開話題之前，先回顧一下我曾經的一個項目。

大概在12~13年左右，我有幸參與了一個大型的項目，負責整個平臺的搭建，這是一個從0到1的過程，公司和客戶都沒有過類似的項目實踐。

這個項目，看上去“沒有想象中的復雜”，關于是接單、派單、回單的過程，所有人都很樂觀，整個項目氛圍特別的輕松，3個月拿下完全沒有問題。

然而，隨著項目的推進，直到整個項目真正上線，前后耗時8個月。

項目開始前，當你能描繪一個美好藍圖的時候，所有人都會被感染，然后所有人都很樂觀，被這種情緒感染的時候，每個人都會高估自己的產出，并且“有意識的”低估項目的復雜度。

甚至直到項目被徹底拖垮后，人們并不愿意承認這種盲目自大的情緒最終會給項目造成危害。

在項目過程中，所有輕松的氛圍下，極其容易帶來錯誤的判斷，低估項目復雜度，低估項目的資源消耗，在商業(yè)行為上會演變?yōu)榈凸理椖績r值，從而埋下巨大的隱患。

所以，對PM來說，關注和把握好團隊的氛圍非常的重要，深刻的發(fā)現(xiàn)和傳遞項目價值，爭取相對于的資源是極為重要的。

1. 合理制定計劃，更需恰當?shù)目刂乒?jié)奏

路易十四把你抓為俘虜，要求你替他做一個計劃，為他的城堡添加三個新地牢：

• 小的地牢很難設計（最快要12周），但是容易建 成（1周）
• 中等的地牢是典型的，設計（5周），施工（6周）
• 大的地牢容易設計（1周），但是很難建造（9周）

你是這個項目的項目經理，你有一個設計師和一個建筑師，但你的設計師不會建造而建造師不會設計。

你會怎么制定項目計劃？

在做這個計劃前，根據我的經驗，最好還是重新檢查一遍項目的任務分解情況，其中往往暗藏風險，一定要讓你的項目是根據結果導向來反推工作事項，才能真正估算每一個結果的產出所需要的工作量。

正確的工作量預估，才能帶來可行的項目計劃。

所以，最直接的方式就是“物盡其用”，根據工作量估算直接安排項目計劃，每個人的工作看上去都安排很飽和。

但實際上，整個工程工期太長，資源消耗過多。

既然老板們不同意，那我們就必須尋找更好的辦法來壓縮工期。

1.加班。

在項目范圍不變的情況下，加班是一個壓縮項目周期的途徑，但很容易導致項目團隊的氛圍下降，進而引發(fā)質量的下降。

對于加班，我們先不去做過多的討論，但我想強調的是：項目中要把握好節(jié)奏，只加有意義的班，而不以加班為樂。

2.加人。

加人這個辦法只適合項目早期，而且是越早越好——這其實意味著要在項目的早期爭取到更多的資源。

而在項目過程中，團隊穩(wěn)定才是關鍵的，往往不等于加人就可以壓縮周期，甚至只會適得其反。

把新人直接塞進項目，多少情況下不是好的選擇。

1個媽媽生一個寶寶要10個月，10個媽媽生一個寶寶，能不能是一個月？

還有一種辦法，就是通過關鍵路徑法。

既然造房子要先做好設計，那就可以把設計和建造的工作進行“分離”，先排出項目事項的優(yōu)先級，說白了就是資源的投入順序。

再找到一條完成整個項目最短可行的任務路徑，這個叫做“關鍵路徑”。

這個表，就很清晰的知道整個項目需要耗費的時間和資源，也很清晰的看到，什么時候什么資源應該投入項目。

也就是這每一個關鍵節(jié)點（里程碑）上都有真正的成功輸出，管理好每一個關鍵節(jié)點，并準備好下一個節(jié)點的資源投入，項目總體的進度會比較有序可控。

而且，這里有一個非常重要的工作——項目計劃一定要實時更新。

一個過時的計劃表，等于項目沒有計劃。

2. 風險往往存在于不經意之間，一定要頭腦清晰

假設一個公司有多個項目并行在展開，意味著全公司的資源能夠交叉的完成的不同的項目，看上去多個項目在并行開展。

效率很高。

但這種方法卻是最難管理的，而且還帶來額外的管理風險。因為我們難以準確的估算每一個工作環(huán)節(jié)的工作量，也難以確保項目進度沒有其他因素的占用時間——比如某一個技術難點帶來的某個節(jié)點的時間延期。

在這種交叉的項目環(huán)境下，項目非常容易失控。

很多時候，我們常能聽到說并行開發(fā)，實際上是對整個資源的過度自信和對項目的認識不足。看上去項目都啟動了，但質量、進度難以保障。

同時干幾件事情的美好愿望最終導致一系列的糟糕局面。

四處救火的局面，應該盡可能的少發(fā)生。一定要能學會找出項目最重要的事情，而少去干緊急的事情。

理論上來說，在項目進入到整個階段，作為項目經理只需要定期檢查里程碑的節(jié)點輸出即可。

在路易十四的項目中，如果你仔細再看這個表，你一定發(fā)現(xiàn)建筑工人有兩周的空閑時間。

兩周的時間，建筑工人無所事事，整天游手好閑——某一天路易十四巡視工地發(fā)現(xiàn)建筑工人睡大覺，還引起設計師的極大不滿。路易十四認為你的計劃有問題，浪費資源。

所以他直接把資源調走，理由是：建筑師并沒有完全被使用或者沒有全情投入。

你怎么辦？

這個就叫項目風險。

所謂風險，就是不確定的事情。你不能完全的規(guī)避風險，有些時候你還需要把一些風險利用起來推動項目的進展。

通常的做法是：在項目的開始階段列出一個風險清單，提醒相關的人員注意可能的狀況，防患于未然。

也就是，在項目過程有一項關鍵的節(jié)點，就是搞一個正式的儀式——召開一個項目啟動會。講清楚項目的價值、背景，需要的資源和進度，影響的范圍以及可能的風險。

把所有好的結果畫一個大餅給所有人，把所有壞的局面講清楚給所有人。

這個會上，不僅僅是傳遞信息，也是爭取資源和權力的關鍵時刻。那些資源是必須保障的，那些事情是需要經過審批的，那些事情是需要注意，都需要講清楚。

必須確保整個項目有一個完整的可行的規(guī)則。

如果你只想做個老好人，沒有通過一個正式的儀式來獲得相應的權限，這個項目會變成非常的難以推進。

首當其沖的就是需求的變更。

要知道牽一發(fā)而動全身，一個小小的變更，甚至會引發(fā)整個項目的范圍、進度、質量、成本的大調整，甚至可能讓整個項目處于一個分崩離析的狀況。

六、期望與權力

任何項目都有一個特色，那就是項目之前群情激昂，至于過程和結果，有的怨聲載道，有的劫后余生，萬象叢生都很正常，越大的項目故事往往越多。

在前述的文章里面，我從項目的環(huán)境，復雜的各方利益，項目的任務分解和任務進度的制定，多個角度分析和闡述了根本原因，這些誘因最終會在項目過程中成為無休止的變更，從而讓整個項目陷入不可救藥的局面。

所以，需求的變動那是家常便飯，沒有變更往往不正常，而變更的管理和文檔的確實會進一步加劇這種現(xiàn)狀。

變更，分為兩種類型，其一是完全不可控因素，既是未知的，也是不能改變的。

比如，公司的經營方向發(fā)生了改變，導致項目的預算被削減（增加），從而影響項目的進度。特別是在創(chuàng)業(yè)型團隊，老板臨時改變注意，發(fā)現(xiàn)某個方向可能更有潛力，調轉槍頭也未可知。

作為一個項目的負責人（執(zhí)行者），在項目啟動之后，唯一的使命就是促使項目成果，或者結束項目。對未知和不可控的任何局面，都無需過多的投入精力。你能做的，就是管理那些可以被管理的內容。

那些內容是可以被管理的？（如何管理）

可控的需求變更，無非三大類：

• 沒有細化清晰的項目需求
• 沒有明確清楚的項目邊界
• 存在設計缺陷的軟件結構

深究起來會發(fā)現(xiàn)，在項目已經啟動后，真正與客戶直接相關的就是第二條，由于沒有明確的項目邊界，從而導致用戶無休止的提出各種需求和變更。

而對需求本身的理解和軟件的設計，則考驗產品經理和整個團隊對業(yè)務的理解、把握和產品設計能力。這也是為什么我一再強調“用戶故事”的原因，而這種變更則需要團隊具備極強的消化能力。

1. 建立完整的流程變更機制并嚴格遵守

項目管理，本質就是對過程的管理，也就是要有完備的流程和堅決的執(zhí)行，通過流程來規(guī)避可能的風險。

所以，項目的第一件就是設立一個需求變更機制（如果你還記得之前談到的項目啟動會，項目經理一定要借助這個會議讓項目的所有相關方知悉這個流程）。

這個流程有兩個核心觀念，也是你一定要能爭取到的權力：

所有人都可以提出需求變更的請求，但只有一個需求的入口——這個入口必須是你，如果你爭取不到這個權力，那整個項目一定會失控。任何都可以提出需求和變更，但你必須作為唯一的接口人和過濾器。

為此，你應該有足夠的心里準備，你需要面對N多方的壓力和“撕逼”。甚至，為了項目交付的這一終極目標，你需要有不惜得罪人的思想準備。越是大項目，越是牽涉多方的項目，風險和協(xié)調都會是指數(shù)級的放大。

只有當你具備這個權力的時候，你才能確保項目在預設的軌道上進行，也只有你才可以清晰的回答當前要做什么，能做什么，以及不能做什么。

只有評審過的需求才可以被執(zhí)行。

“不要接到需求就直接動手”。這是項目的至理名言。

你需要讓整個項目團隊，包括上至老板、直到程序員，也包括外部的客戶，都認同、理解并遵守一個基本原則，那就是程序員不直接接受任何非PM的需求，不接收任何非經過評審的需求——所有未經過評審的需求，只可討論，不可執(zhí)行，減少（避免）張嘴就來的非必要、非緊急、非合理的無效變更。

切記：不是所有的需求都要接受，也不是所有變更都要立刻修改，一定要能敢于拒絕需求。

作為產品經理，在需求變更收集上來之后，根據需求提出方的業(yè)務進行分析后，邀請需求方、技術、設計和測試多個環(huán)節(jié)進行分析，從而判定需求對于項目的影響如何，確定是否接受變更并將變更排列優(yōu)先級。

但最終一定要你拍板，這是你需要爭取到的第二個權力。你不能最終決定一個需求的價值，對你而言，項目已經離失控不遠了。

當然，你可以適當根據需求的范圍大小，決定評審的范圍，甚至可以決定需要告知的對象，這沒有標準，需要靈活把握。

這里其實是有一個例外，那就是技術本身驅動的變更；比如有更好的實現(xiàn)方案可以帶來性能的提升，這個情況，需要根據整體項目狀況，結合技術本身的能力判斷。

一定要爭取到合適的權限范圍，才可能有序的推進項目進程。

2. 建立完善的文檔管理機制并落實到位

俗話說“好記性不如爛筆頭”。

項目過程中，文檔是極為重要的工具，雖然管理文檔費時費力。對于產品經理（創(chuàng)業(yè)團隊還是兼任項目經理）而言，一定要持續(xù)的追蹤項目的所有需求文檔，變更記錄。

一定要所有的文檔，形成版本機制并同步到到團隊的沒有給成員，你可以借助一些在線工具來幫助你完成這項功能。

要知道，但凡失控的項目里面一定有一條就是找不到需求的出路，不知道為什么要這么做，也不知道誰要求這么做，反正就是做了，然后誰也講不清楚由來。

任何需求，都必須記錄在案，甭管是否執(zhí)行，需求的第一個動作就是備忘，第二步才是決定是否執(zhí)行。一定要專人負責需求的梳理，跟蹤和進度的反饋。

完整的需求變更記錄文檔將有助于你了解整個項目情況，包括執(zhí)行的需求，被拒絕的需求，你需要一個“需求池”統(tǒng)一管理來自業(yè)務端、技術端的需求，并針對項目中出現(xiàn)的資源、時間等因素可以合理的進行調配。

3. 張弛有度，控制項目的節(jié)奏

你確定了規(guī)則，梳理好了邊界，甚至也形成了流程。下一步，你得控制好整個產品的推進節(jié)奏，合理的控制和調節(jié)需求、變更的優(yōu)先級，以及資源的投放力度：什么時候該投入多少資源，什么時候該做什么事情，什么是關鍵路徑，什么是關鍵角色，你必須門兒清。你得想方設法讓你的項目，在你所能控制的范圍內進行，一旦超過邊界，你可能需要啟動后備資源予以干預，而且是在苗頭開始之際。

你所有的干預手段，預防機制，都是為了確保項目按照一定的規(guī)則和秩序推進；也只有基于可控的節(jié)奏，你才能確保整個過程的質量，以及最終交付的質量。當過程不可控的時候，往往結果會很糟糕。

最后，一定要深刻的理解，需求是不斷的演進和變化的，合理的規(guī)避不合理的變更方為上策。

有些時候，無論你怎樣控制，由于市場的壓力，總會碰到各種“無理”要求，如何看待這樣的問題，就不是簡單的控制問題了，這就需要更高的層面去權衡利弊，如果確實不值得，也只能放棄。

寫在系列收尾處

產品經理作為引路人，就是盡可能的讓不確定性的因素，變?yōu)榇_定的，可被執(zhí)行的流程、方案。

不管你是否兼任“項目經理”的角色，在一個產品從0到1的過程里面，產品經理必須深刻的理解整個過程的艱巨，要能與團隊一起致力于整個項目的成功。

至此，本系列從項目和產品的概念出發(fā)，到項目環(huán)境的分析，以及對項目過程的幾大巨坑一一做了闡述，也許你還需要一些工具，或者模板來提高項目過程管理的效率。

#專欄作家#

杜松，公眾號：產品微言，人人都是產品經理專欄作家。專注于人工智能方向，擅長產品規(guī)劃和架構設計。

本文原創(chuàng)發(fā)布于人人都是產品經理。未經許可，禁止轉載。

題圖由作者提供