起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識以產品經理的視角看待項目，以及如何管理項目（下）
對很多產品經理而言，特別是身處創業團隊，往往都是一身挑幾職，產品和項目，理不清理還亂。從本文開始，以產品經理的視角看待項目，以及如何管理項目。
接上篇。
四、合適的人與靠譜的計劃
幾乎每個項目都有人吐槽，太坑太扯淡。
實際上，項目之所以會扯皮，往往在前期就埋了下巨坑，隨著項目的進程問題越來越嚴重，直到不能收場。
在上文我們已經厘清了項目的幾個核心概念?，我們知道要想做好一個項目首先要搞清楚項目利益相關方，組建合適的項目團隊，然后我們需要分解我們的項目任務，制定一個清晰的項目計劃，才能指導和推動項目的進展。
我們現在從案例來還原項目前期的挖下的坑：
A公司目前正在為一個醫院開發一套系統，現在項目按時間開發完成了，也做好了相關的培訓工作，但始終無法驗收，醫生說不好用，而且還有三個需求要變更，開發工程師下個月要離職了，各種問題層出不窮……
假設你是這個項目的項目經理，我們一起來看看你踩的雷。
1.?項目第一坑：“人”才是最坑的
你從銷售經理那里獲悉，這個項目是內科的科長最開始發起的，副院長也很支持。
你很開心，感覺這個項目牽涉的人比較少，就開始了這個項目，并且定期發送相關的進度報告：
隨著在醫院的了解越來越多，你發現醫院的關系越來越復雜，各種不配合扯皮的現象——很多沒必要的需要變更，培訓的效果也沒有看上去理想。
你認為這是院長負責的項目，一定大家都會支持；你以為給內科做了一次培訓，大家都會使用；沒想到培訓完之后他們還是反饋說系統不太好用。
這些問題，本質上就是項目開始階段想得太簡單，沒有能搞清楚相關方的利益關系。
這是項目的第一步，也是項目的關鍵一步。
多數情況下，一個項目有支持者，往往就有反對者；項目的支持者能讓項目錦上添花，但反對者往往決定成敗。
如果在項目開始階段，沒有找出那項目能夠施加積極和消極影響力的人，注定整個項目會很艱難。
同時，你還需要找到一個最具有推動力的關鍵人，對內爭取更多資源，對外擺平各種關系。
所以，這個項目的干系人需要更完整：
越是大型的項目，人的因素影響越大，也越難以把控。
那些決定項目成敗的，能出力的人，都應該是你的項目組成員，還有一些人，你需要TA掛一個虛職，并告訴及時告訴TA進展。
我們常常見到一個項目進行了一半，才臨時通知或者征調其他部分的人參與，帶來的問題就是溝通成本非常的高，過程完全不可控。
2.?項目第二坑：只有任務，沒有成果
項目的第二步，是要分解項目的具體工作任務，也就是要分配張三、李四分別要完成的工作。在PMP體系中這個叫WBS，在Prince2的體系中則強調的是PBS。
最直接的做法，通常都是根據“事項”來分解；畢竟我們需要把任務分配給不同的人來執行，并根據這個任務來估算時間，確定進度。
所以最常見的分解方法就變成這個樣子：
但為什么這種分解方式會導致項目做到一半就會人員流失，士氣低下呢？
根源在于這種任務分解只關注了過程，沒有確定到底要做成什么樣，沒有邊界和具體的目標。
沒有驗收的標準，沒有衡量的指標，所有的人都在忙，忙到最后發現客戶不買賬。
比如項目計劃里面UI設計的是10天，為什么不是9天或者11天呢？要輸出多少個頁面？
科室培訓是培訓一天就可以了嗎？還是1小時就可以結束而且所有人都能熟練掌握？用戶向要在用戶登錄模塊里面添加一個找回用戶名的功能，要不要增加？
諸如此類的問題，隨時可能發生。
因為這種結構是沒有辦法落實到具體一個功能需要的耗時，所以會不會打亂整個計劃就說不太清楚。
僅僅知道什么時候做什么，對項目的成敗而言是沒有意義的，關鍵是結果是什么，沒有成果的努力，都是一種自嗨。
回顧前文? “?如何用Axure輸出高質量的PRD？”，為什么會強調“故事”呢?
基于“用戶故事”來分解這個項目的任務——構建一套以用戶需求驅動的PBS，才能滿足用戶的需求，也才能真正估算一個可行的項目計劃，雙方也才能在一直的目標下推進具體的功能。
這是一個項目成果的護身符，當任意發起與PBS相違背的變更都會影響到項目的進度，界定了項目的邊界，為日后的項目進度規避了許多不必要的障礙。
因為在這種結構下，任何的變更都可能導致整個路徑的紊亂，從而項目失控。或者為了項目進度，投入更多的資源，或者友好協商推遲項目的進度。
搞不定人事，理不清邊界，是項目失敗的最關鍵因素，作為項目經理（有一些情況下是產品經理直接帶項目）務必保持清醒的頭腦。
五、項目節奏和潛在的風險
我們搞清楚了項目的利益相關方，理清楚了項目的范圍，要做什么工作也已經妥當的安排好了專人負責，然而項目依然還會失控。
原因何在？
展開話題之前，先回顧一下我曾經的一個項目。
大概在12~13年左右，我有幸參與了一個大型的項目，負責整個平臺的搭建，這是一個從0到1的過程，公司和客戶都沒有過類似的項目實踐。
這個項目，看上去“沒有想象中的復雜”，關于是接單、派單、回單的過程，所有人都很樂觀，整個項目氛圍特別的輕松，3個月拿下完全沒有問題。
然而，隨著項目的推進，直到整個項目真正上線，前后耗時8個月。
項目開始前，當你能描繪一個美好藍圖的時候，所有人都會被感染，然后所有人都很樂觀，被這種情緒感染的時候，每個人都會高估自己的產出，并且“有意識的”低估項目的復雜度。
甚至直到項目被徹底拖垮后，人們并不愿意承認這種盲目自大的情緒最終會給項目造成危害。
在項目過程中，所有輕松的氛圍下，極其容易帶來錯誤的判斷，低估項目復雜度，低估項目的資源消耗，在商業行為上會演變為低估項目價值，從而埋下巨大的隱患。
所以，對PM來說，關注和把握好團隊的氛圍非常的重要，深刻的發現和傳遞項目價值，爭取相對于的資源是極為重要的。
1. 合理制定計劃，更需恰當的控制節奏
路易十四把你抓為俘虜，要求你替他做一個計劃，為他的城堡添加三個新地牢：
- 小的地牢很難設計（最快要12周），但是容易建 成（1周）
- 中等的地牢是典型的，設計（5周），施工（6周）
- 大的地牢容易設計（1周），但是很難建造（9周）
你是這個項目的項目經理，你有一個設計師和一個建筑師，但你的設計師不會建造而建造師不會設計。
你會怎么制定項目計劃？
在做這個計劃前，根據我的經驗，最好還是重新檢查一遍項目的任務分解情況，其中往往暗藏風險，一定要讓你的項目是根據結果導向來反推工作事項，才能真正估算每一個結果的產出所需要的工作量。
正確的工作量預估，才能帶來可行的項目計劃。
所以，最直接的方式就是“物盡其用”，根據工作量估算直接安排項目計劃，每個人的工作看上去都安排很飽和。
但實際上，整個工程工期太長，資源消耗過多。
既然老板們不同意，那我們就必須尋找更好的辦法來壓縮工期。
1.加班。
在項目范圍不變的情況下，加班是一個壓縮項目周期的途徑，但很容易導致項目團隊的氛圍下降，進而引發質量的下降。
對于加班，我們先不去做過多的討論，但我想強調的是：項目中要把握好節奏，只加有意義的班，而不以加班為樂。
2.加人。
加人這個辦法只適合項目早期，而且是越早越好——這其實意味著要在項目的早期爭取到更多的資源。
而在項目過程中，團隊穩定才是關鍵的，往往不等于加人就可以壓縮周期，甚至只會適得其反。
把新人直接塞進項目，多少情況下不是好的選擇。
1個媽媽生一個寶寶要10個月，10個媽媽生一個寶寶，能不能是一個月？
還有一種辦法，就是通過關鍵路徑法。
既然造房子要先做好設計，那就可以把設計和建造的工作進行“分離”，先排出項目事項的優先級，說白了就是資源的投入順序。
再找到一條完成整個項目最短可行的任務路徑，這個叫做“關鍵路徑”。
這個表，就很清晰的知道整個項目需要耗費的時間和資源，也很清晰的看到，什么時候什么資源應該投入項目。
也就是這每一個關鍵節點（里程碑）上都有真正的成功輸出，管理好每一個關鍵節點，并準備好下一個節點的資源投入，項目總體的進度會比較有序可控。
而且，這里有一個非常重要的工作——項目計劃一定要實時更新。
一個過時的計劃表，等于項目沒有計劃。
2. 風險往往存在于不經意之間，一定要頭腦清晰
假設一個公司有多個項目并行在展開，意味著全公司的資源能夠交叉的完成的不同的項目，看上去多個項目在并行開展。
效率很高。
但這種方法卻是最難管理的，而且還帶來額外的管理風險。因為我們難以準確的估算每一個工作環節的工作量，也難以確保項目進度沒有其他因素的占用時間——比如某一個技術難點帶來的某個節點的時間延期。
在這種交叉的項目環境下，項目非常容易失控。
很多時候，我們常能聽到說并行開發，實際上是對整個資源的過度自信和對項目的認識不足?？瓷先ロ椖慷紗恿耍|量、進度難以保障。
同時干幾件事情的美好愿望最終導致一系列的糟糕局面。
四處救火的局面，應該盡可能的少發生。一定要能學會找出項目最重要的事情，而少去干緊急的事情。
理論上來說，在項目進入到整個階段，作為項目經理只需要定期檢查里程碑的節點輸出即可。
在路易十四的項目中，如果你仔細再看這個表，你一定發現建筑工人有兩周的空閑時間。
兩周的時間，建筑工人無所事事，整天游手好閑——某一天路易十四巡視工地發現建筑工人睡大覺，還引起設計師的極大不滿。路易十四認為你的計劃有問題，浪費資源。
所以他直接把資源調走，理由是：建筑師并沒有完全被使用或者沒有全情投入。
你怎么辦？
這個就叫項目風險。
所謂風險，就是不確定的事情。你不能完全的規避風險，有些時候你還需要把一些風險利用起來推動項目的進展。
通常的做法是：在項目的開始階段列出一個風險清單，提醒相關的人員注意可能的狀況，防患于未然。
也就是，在項目過程有一項關鍵的節點，就是搞一個正式的儀式——召開一個項目啟動會。講清楚項目的價值、背景，需要的資源和進度，影響的范圍以及可能的風險。
把所有好的結果畫一個大餅給所有人，把所有壞的局面講清楚給所有人。
這個會上，不僅僅是傳遞信息，也是爭取資源和權力的關鍵時刻。那些資源是必須保障的，那些事情是需要經過審批的，那些事情是需要注意，都需要講清楚。
必須確保整個項目有一個完整的可行的規則。
如果你只想做個老好人，沒有通過一個正式的儀式來獲得相應的權限，這個項目會變成非常的難以推進。
首當其沖的就是需求的變更。
要知道牽一發而動全身，一個小小的變更，甚至會引發整個項目的范圍、進度、質量、成本的大調整，甚至可能讓整個項目處于一個分崩離析的狀況。
六、期望與權力
任何項目都有一個特色，那就是項目之前群情激昂，至于過程和結果，有的怨聲載道，有的劫后余生，萬象叢生都很正常，越大的項目故事往往越多。
在前述的文章里面，我從項目的環境，復雜的各方利益，項目的任務分解和任務進度的制定，多個角度分析和闡述了根本原因，這些誘因最終會在項目過程中成為無休止的變更，從而讓整個項目陷入不可救藥的局面。
所以，需求的變動那是家常便飯，沒有變更往往不正常，而變更的管理和文檔的確實會進一步加劇這種現狀。
變更，分為兩種類型，其一是完全不可控因素，既是未知的，也是不能改變的。
比如，公司的經營方向發生了改變，導致項目的預算被削減（增加），從而影響項目的進度。特別是在創業型團隊，老板臨時改變注意，發現某個方向可能更有潛力，調轉槍頭也未可知。
作為一個項目的負責人（執行者），在項目啟動之后，唯一的使命就是促使項目成果，或者結束項目。對未知和不可控的任何局面，都無需過多的投入精力。你能做的，就是管理那些可以被管理的內容。
那些內容是可以被管理的？（如何管理）
可控的需求變更，無非三大類：
- 沒有細化清晰的項目需求
- 沒有明確清楚的項目邊界
- 存在設計缺陷的軟件結構
深究起來會發現，在項目已經啟動后，真正與客戶直接相關的就是第二條，由于沒有明確的項目邊界，從而導致用戶無休止的提出各種需求和變更。
而對需求本身的理解和軟件的設計，則考驗產品經理和整個團隊對業務的理解、把握和產品設計能力。這也是為什么我一再強調“用戶故事”的原因，而這種變更則需要團隊具備極強的消化能力。
1.?建立完整的流程變更機制并嚴格遵守
項目管理，本質就是對過程的管理，也就是要有完備的流程和堅決的執行，通過流程來規避可能的風險。
所以，項目的第一件就是設立一個需求變更機制（如果你還記得之前談到的項目啟動會，項目經理一定要借助這個會議讓項目的所有相關方知悉這個流程）。
這個流程有兩個核心觀念，也是你一定要能爭取到的權力：
所有人都可以提出需求變更的請求，但只有一個需求的入口——這個入口必須是你，如果你爭取不到這個權力，那整個項目一定會失控。任何都可以提出需求和變更，但你必須作為唯一的接口人和過濾器。
為此，你應該有足夠的心里準備，你需要面對N多方的壓力和“撕逼”。甚至，為了項目交付的這一終極目標，你需要有不惜得罪人的思想準備。越是大項目，越是牽涉多方的項目，風險和協調都會是指數級的放大。
只有當你具備這個權力的時候，你才能確保項目在預設的軌道上進行，也只有你才可以清晰的回答當前要做什么，能做什么，以及不能做什么。
只有評審過的需求才可以被執行。
“不要接到需求就直接動手”。這是項目的至理名言。
你需要讓整個項目團隊，包括上至老板、直到程序員，也包括外部的客戶，都認同、理解并遵守一個基本原則，那就是程序員不直接接受任何非PM的需求，不接收任何非經過評審的需求——所有未經過評審的需求，只可討論，不可執行，減少（避免）張嘴就來的非必要、非緊急、非合理的無效變更。
切記：不是所有的需求都要接受，也不是所有變更都要立刻修改，一定要能敢于拒絕需求。
作為產品經理，在需求變更收集上來之后，根據需求提出方的業務進行分析后，邀請需求方、技術、設計和測試多個環節進行分析，從而判定需求對于項目的影響如何，確定是否接受變更并將變更排列優先級。
但最終一定要你拍板，這是你需要爭取到的第二個權力。你不能最終決定一個需求的價值，對你而言，項目已經離失控不遠了。
當然，你可以適當根據需求的范圍大小，決定評審的范圍，甚至可以決定需要告知的對象，這沒有標準，需要靈活把握。
這里其實是有一個例外，那就是技術本身驅動的變更；比如有更好的實現方案可以帶來性能的提升，這個情況，需要根據整體項目狀況，結合技術本身的能力判斷。
一定要爭取到合適的權限范圍，才可能有序的推進項目進程。
2.?建立完善的文檔管理機制并落實到位
俗話說“好記性不如爛筆頭”。
項目過程中，文檔是極為重要的工具，雖然管理文檔費時費力。對于產品經理（創業團隊還是兼任項目經理）而言，一定要持續的追蹤項目的所有需求文檔，變更記錄。
一定要所有的文檔，形成版本機制并同步到到團隊的沒有給成員，你可以借助一些在線工具來幫助你完成這項功能。
要知道，但凡失控的項目里面一定有一條就是找不到需求的出路，不知道為什么要這么做，也不知道誰要求這么做，反正就是做了，然后誰也講不清楚由來。
任何需求，都必須記錄在案，甭管是否執行，需求的第一個動作就是備忘，第二步才是決定是否執行。一定要專人負責需求的梳理，跟蹤和進度的反饋。
完整的需求變更記錄文檔將有助于你了解整個項目情況，包括執行的需求，被拒絕的需求，你需要一個“需求池”統一管理來自業務端、技術端的需求，并針對項目中出現的資源、時間等因素可以合理的進行調配。
3.?張弛有度，控制項目的節奏
你確定了規則，梳理好了邊界，甚至也形成了流程。下一步，你得控制好整個產品的推進節奏，合理的控制和調節需求、變更的優先級，以及資源的投放力度：什么時候該投入多少資源，什么時候該做什么事情，什么是關鍵路徑，什么是關鍵角色，你必須門兒清。你得想方設法讓你的項目，在你所能控制的范圍內進行，一旦超過邊界，你可能需要啟動后備資源予以干預，而且是在苗頭開始之際。
你所有的干預手段，預防機制，都是為了確保項目按照一定的規則和秩序推進；也只有基于可控的節奏，你才能確保整個過程的質量，以及最終交付的質量。當過程不可控的時候，往往結果會很糟糕。
最后，一定要深刻的理解，需求是不斷的演進和變化的，合理的規避不合理的變更方為上策。
有些時候，無論你怎樣控制，由于市場的壓力，總會碰到各種“無理”要求，如何看待這樣的問題，就不是簡單的控制問題了，這就需要更高的層面去權衡利弊，如果確實不值得，也只能放棄。
寫在系列收尾處
產品經理作為引路人，就是盡可能的讓不確定性的因素，變為確定的，可被執行的流程、方案。
不管你是否兼任“項目經理”的角色，在一個產品從0到1的過程里面，產品經理必須深刻的理解整個過程的艱巨，要能與團隊一起致力于整個項目的成功。
至此，本系列從項目和產品的概念出發，到項目環境的分析，以及對項目過程的幾大巨坑一一做了闡述，也許你還需要一些工具，或者模板來提高項目過程管理的效率。
#專欄作家#
杜松，公眾號：產品微言，人人都是產品經理專欄作家。專注于人工智能方向，擅長產品規劃和架構設計。
本文原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖由作者提供
佩服閣下的神更速……
要調整一下節奏了。
作者能將自己工作所感用文字清晰表達出來，很是佩服?，F在國內大部分企業都覺得聘用專業的項目管理人員是浪費錢，所以要么是產品經理兼職，要么是開發leader兼職。畢竟，項目管理能帶來企業管理效率和人員能力的提升，卻無法讓人一眼看穿有形的可以轉化成金錢的價值。誠然，如果這些優秀的員工，兼顧自己份內事的同時，還能熟諳項目管理之道，對公司來說無疑是賺了。但是，通常情況下，這些兼職做一做的人，在自己的專業領域是佼佼者，但沒有經過專業的項目管理教育或培訓，沒有系統的項目管理思維，更沒有豐富的可以成體系的項目管理經驗，單憑著零星的碎片化的項目管理認知，就開始沖鋒打仗。這，對整個產品線或項目團隊來說是個巨坑，特別是涉及各種軟硬件控制、媒體協議等技術含量高有較多技術難關需要攻克的研發項目，不搞清楚技術邊界和項目邊界就開工，更是個巨巨坑。
市場人員在競標和合同簽訂時，目標是掙錢，事先基本不會深入充分地了解研發的技術邊界，并根據技術邊界做正確的風險評估、除外責任定義。這中間，缺少一個人在競標時和簽訂合同時，根據各項條款，評估投入和收益等，考慮所有干系人的意見，進而評估接與不接此項目。
合同到了研發，甚至很多時候團隊成員連合同都沒見到，只是聽領導口頭傳達一下，開個簡單的項目啟動會，研發就心急火燎開工。這中間，缺少一個人收集所有項目文件，制定項目章程，制定項目管理計劃、收集需求，定義項目范圍和需求邊界，創建WBS及各項活動，排列活動順序、估算資源和持續時間，制定進度計劃，甚至還得估算成本、制定預算、制定成本管理計劃、質量管理計劃、人力資源管理計劃、溝通管理計劃、風險管理計劃、采購管理計劃、干系人管理計劃等。這個人還不能按部就班死腦筋，還得根據具體情況靈活地對項目管理流程進行裁剪，提升團隊效率。
項目執行過程中，需要一個人，控制質量、控制進度、控制成本、控制范圍、識別和控制風險等，出現了風險或變更，進行風險定性定量分析，制定應對策略。
項目收尾時，需要一個人，有條不紊地結束采購、結束項目，避免因為各種風險和需求變更導致爛尾。
這個人，說的就是項目經理。
以上所說，不盡全面，項目經理的工作遠比以上描述的既定流程復雜的多。因為項目管理中涉及到較多管理人的工作，涉及人的工作是最多變數的工作，這個人今天要請假，那個人下月要離職，快到了交付時間點有個人反應說之前評估工作量有誤，因為出現了隱性風險難以解決等。這些，都需要項目經理盡快去協調，要么加班趕工，要么加人快速跟進，可能需要跟其他項目組搶資源，還要向大boss匯報階段性進展和成果等等。這些絕不是一個敲代碼的或者畫原型的就能兼職干了的工作。當然，除非是特別優秀的員工，樣樣精通，又能左右兼顧。
你的留言寫得很有深度和具體，看得出來，你有豐富的實戰經驗。??
過獎過獎，實際我是一位交互設計師，項目管理方面的經驗暫時不多，還在慢慢學習。當時寫了這么長的評論，是因為氣憤我們研發總監，總是隨便拉個程序猿或者設計師就讓去跟進項目，給戴上項目經理的帽子。如果沒管理好或出了紕漏，就馬上換其他研發人員跟進，把前任的帽子摘掉，周而復始。這種做法簡直就是拿公司那么多項目當兒戲。我覺得我們公司好多研發項目不順利的癥結就是公司不肯花錢請專業的項目經理。哪怕花重金請一個，能帶起來一批，多劃算啊。
這是一個意識和認知問題，需要潛移默化的轉化觀念
（下）篇寫的更好，有作者自己的思考，認同，鎖定關鍵干系人、以結果為導向的劃分WBS，控制項目節奏和風險中產品經理必須有的權力。只是，經過評審的需求才可執行，實際中評審人員的組織也是具有很大的協調量。
是的，實際中，其實蠻難做到的。
深有感觸
寫的深有感觸，就是文中有幾個圖片打不開，可能失效了