作為產品經理，如何做好項目管理？
本文為平台特約稿件，未經許可，禁止轉載
全文共 12786 字 16 圖，閱讀超過 30 分鐘
———— / BEGIN / ————
不管你身處大公司大環境，還是小公司創業團隊，相信你一定見過各種項目的問題，也見過很多失敗的案例。
所謂成功的項目，一定是在有限的條件下，達成預期的目的。
想要管理好一個項目，必須尊重基本的客觀事實，對項目想要完成的功能範圍、所需要消耗的資源和時間成本，必須有一個清醒的認識；一顆對產品、對技術、對用戶的敬畏之心，是一個項目可能成功的基礎。
一、敬畏之心
對任何項目項目而言：
時間緊迫，活兒就只能湊合了；
資源有限，人手不足，就往後拖吧；
東西做不完，就只能趕緊砍內容，別弄那麼多。
範圍、時間、成本、質量，環環相扣，任何一個環節都帶來極大的挑戰，都可能引發極大損失。
老闆們都想項目完成的時間要快，完成的成本要低，完成後的質量要好。
但能夠完美做到以上三個要素的項目，少之又少，我基本沒有見過。
反倒是，我見過最讓人感到震驚的狀況。
一種是多產品多項目的並行開發，最後發現沒有一個產品可用。還有一種就是引發極大的質量問題，造成重大的損失。
而事實上，這都是可以預計和預防的。
有的時候，真是人心不足蛇吞象，想法足夠大膽，但投入捉襟見肘。
要知道：任何罔顧基本規律的做法，必然遭受現實的打擊，造成不可估量的損失。
作為PM（項目/產品經理），一定要把這個金三角的關係牢記於心。
為了縮短項目時間，就需要增加項目成本（資源）或減少項目範圍；
為了節約項目成本（資源），就需要減少項目範圍或延長項目時間；
如果需求變化導致增加項目範圍，就需要增加項目成本（資源）或延長項目時間。
甚至，對質量的追求，都是一個度量的平衡。
不管你用什麼管理的方法方式，都不能繞過這一基本原則。
因此，在做預算的時候，必須面對現實，而且一定要掌握一個原則：預留一定的彈性空間。
產品經理應該用一種「悲觀」的視角看待項目，用樂觀的途徑去解決問題。
但事實上，產品經理們最容易犯的錯誤，就是在完工日期的預測上，為了討好客戶或者上司而過於樂觀，或者依據簡單的經驗數據來做出決定。
魚與熊掌之間，是一道三角難題。
項目計劃是一個多次反覆的過程，也是一個不斷修正的過程，一定要時刻保持基本的敬畏之心，重複考慮各種因素的相互協調。
想要在三角之間找到一個平衡點，一定要弄清楚什麼是「好」，什麼是「快」，什麼是「便宜」。
最忌諱的就是盲目的追求「快」，最可怕的是過於樂觀承諾「好」。
所以，對於產品（項目）經理而言：
第一條規則是：讓你的老闆認可和接受金三角法則；
第二條原則是：你始終在受限的環境下管理你的產品（項目）。
二、產品&項目的異同
「項目」這個概念，其實時刻都在我們身邊發生，火箭上天是一個項目，家庭裝修也是一個項目，他們共同的特性就是都有完全不同的開始、結束時間，也都產生完全不同的結果。
有的項目很長影響很大，甚至流芳百世，比如修建三峽。
有的項目僅僅是你的私事，比如追求心中的女（男）神。
1. 產品 vs 項目，兩個世界的追求
隨著「互聯網思維」的遍地開花，我們看到一種現象，項目經理這一角色似乎越來越被削弱，產品經理大有取而代之的趨勢，甚至很多互聯網公司都沒有專職項目經理。
這是錯覺還是必然，兩者之間是否必然會被過渡？
但兩者其實是完全不應該有混淆和爭議。
產品，是指能夠供給市場，被人們使用和消費，並能滿足人們某種需求的任何東西（百科定義）
項目，是為創造獨特的產品、服務或成果，而進行的臨時性工作（PMP定義）
這個定義已經很清晰的界定了一個產品是由N個項目組成的，產品輸出實際的東西，而項目對應產生產品的過程。
也就是：產品經理對結果負責，項目經理對過程負責。
對一個企業來說：
產品經理強調的是：做一個什麼東西，通過什麼方式可以賣給誰，賺到多少錢。
項目經理考慮的是：需要多少時間，投入多少資源把東西做出來。
比如對面有一個山頭。
產品經理想的是：把旗幟插到對面山頭上去。插一面大旗還是小旗，是一面綠旗還是紅旗？是不是要用混凝土加固下，啥時候再發起下一個項目。
項目經理想的是：怎麼去那個山頭，誰抗旗，抗多久，扛不動怎麼辦？至於旗幟插上去下一步怎麼辦，會不會倒，項目經理並不關心。
2.1.1 關注點不同
產品經理的側重點向外，關注用戶和市場
市場機會和競爭格局
用戶需求和用戶溝通
解決的是做什麼，賣給誰，賺誰的錢的問題。
項目經理的側重點朝內，關注資源和進度
資源調配
資源效率
項目進度
解決的是如何用有限的資源在限定的時間內，按照質量要求把東西做出來。
2.1.2 交付物不同
產品經理交付的是產品成果，最終交付給用戶的產品，關注產品的成本、質量和體驗，以及產品通過運營後轉化的企業收益。
項目經理交付的是管理成果，最終交付管理層的工作報告， 關注團隊的士氣、效能、成本，以及企業整體的生產效率的提升。
2. 禍起蕭牆，根源到底在哪
理論上來說，項目經理和產品經理是不應該存在爭議的，但事與願違。
為什麼會出現「我到底是「產品經理」還是「項目經理」」的困惑呢？
首先，產品經理是搶著項目經理的飯碗而復興的。
儘管產品經理很早就誕生了（來源於寶潔，故事可百度），但在IT領域並沒有受到重視，在那個年代，對於看不見摸不著的軟體，用戶是沒有概念的，只能是企業自己決定自己要做什麼，以自己的技術推動用戶往前走。
在2010年前後，技術的普及也帶來了用戶的覺醒，傳統強調時間、進度的軟體工程的思維越來越具有局限性，「寶潔的故事」事實上在重演，產品經理再次「橫空出世」，一直到後面的「人人都是產品經理」，是一種徹底的思維轉向。
也就是：產品經理試圖分解和分擔過去項目經理的職責和工作，把傳統軟體工程的項目概念，重新回歸到產品本身來，從強調企業內的項目交付，轉為面向用戶的成果交付。
了解目前的「甲乙方項目」就能夠感受得到，交付給甲方的成果，其中之一就是龐大的過程資產，甚至試圖在儘可能的還原過程，「我就是按照你的思路和要求一步步做出來，你就老老實實的簽字畫押」吧。
所以，「甲乙方項目」、「外包項目」極容易脫離用戶需求，因為面向管理過程。
第二，產品經理和項目經理存在難以逾越的鴻溝
事實上，對用戶而言，一個產品是怎麼做出來的，他完全不關心。加了多少班，熬了多少夜他也不感興趣，他只關心這個產品是不是他想要的，有沒有價值則直接決定他是否願意付費。
你說你這個軟體可以約妹子，他就試試能不能約到妹子？你說你這個app買東西便宜，他就試試比別人便宜多少？除此之外「多說無益」。
對用戶來說，當物質豐富，用戶有可選餘地；他一定選擇他喜歡的，滿意的產品。只要他不開心，他除了卸載，還是卸載。
而傳統軟體工程思維，是與此相背離。
作為項目經理，如果一個東西，能夠按質按量按時的生產出來，是難以評判它的失敗。完美的過程管理，更是能帶來企業管理效率和人員能力的提升。
遺憾的是，這些對用戶而言都是無效的。
產品經理來說，「雞飛狗跳」都是次要的，用戶開心比什麼都重要，所以他首要解決的是用戶、市場和競爭性的問題。而把內在的過程放在其次，「需求很簡單，怎麼做我不管」在一定程度上並沒有錯。
子非魚，用戶思維，和我們自己的思維是存在天然的鴻溝的。
站在地球上，我們始終看到的是太陽繞著我們轉；而站在月球，站在太空呢？
這也是以用戶為中心往往很難落地的一個原因——用戶思維是一種反向思維，反人性。
產品和項目在這個維度上存在對立關係。
任何一個產品，越強悍越完美，越有可能讓用戶開心，但對企業來說就可能是災難，項目過程必須採取折衷的辦法。打造完美的產品，意味著投入更多的額外資源，形成事實上不必要的光環。
第三，產品經理和項目經理剪不斷，理還亂
對一個將軍來說，我只知道要拿不下這個山頭，留多少血我不感興趣。
但你並不能這麼做。
軟體開發過程中，就必須遵循基本的規則和規律，一個媽媽生一個寶寶要10個月，不能直接換算為10個媽媽生一個寶寶只要一個月。
當一個東西，決定要做的時候，就開始牽涉到複雜的資源、進度、質量和範圍的問題，而這四個形成一個互相角力。
比如範圍擴大，就勢必引發進度和資源問題：
很多時候常能聽到並行，同步的字眼，多想想10個媽媽生寶寶的故事。
項目的過程有其複雜的機制和邏輯，同一個項目，在不同的模式下，極可能消耗的資源，進度，質量都會完全不一樣，項目的過程管理有科學的依據和成熟的體系。
比如工作任務的分解、關鍵路徑的跟蹤等等。
產品經理其實非常的依賴項目過程的管理，不管這個角色被定義為項目經理還是自身的兼顧，都會對產品的工作帶來影響。
所以我們常常見到兩種產品經理，一種是以市場、用戶為天職的產品經理，看上去牛皮轟轟響，可東西沒出來，還有一種是事無巨細過程很完美，但市場反饋差一點。
3. 相輔相成，方能互相成就
項目經理和產品經理的爭議嚴格來說並沒有意義。
個人的主張是，理應各司其事，特別是更加複雜的競爭環境下，想要真正的以用戶為中心，勢必進一步加強用戶的溝通和研發，把更多的精力放在對市場的靈敏反饋上。
同時，產品的過程管理也極為重要，它反過來反作用於用戶。
清晰的業務方向，準確的市場反饋，以及完善的項目過程管理，才是真正無望而不利的。
對企業來說，小團隊可以產品經理兼任項目精力，在一定程度上需要分設不同的角色，應對更為激烈的市場競爭。
對產品經理和項目經理而言，彼此之間有清晰的定義，但從來都只有模糊的邊界。
三、項目環境決定成敗
作為一個產品經理，我們都曾心懷改變世界的夢想，期望一己之力為用戶帶來「無上」的價值。
現在的情況是，夢想談完了，模式說清了，想要搞出一個什麼東西也明白了，是要真正見到「產品」的時候了。
可是，你可能就那麼幾桿槍，怎麼辦？
磨刀不誤砍柴工，在真正親自下戰場操刀之前，關於項目的幾個核心概念一定要搞清楚。
你的身份現在應該切換到項目的角色。
不要再談理想，也不要再說體驗故事，先把東西做出來再說。
1. 項目生命周期
談產品和項目的時候有一個清晰的定義——項目一定要有開始和結束的時間。
所以，任何一個項目一定都一個生命周期，或長或短。
任何一個項目，規模、複雜度都不同，但無論大小，都一定具備一個通用的生命周期結構：
啟動項目；
組織和準備；
推進具體的工作；
結束項目。
也就是任何一個項目，都有一個通用的項目階段：
啟動——計劃&執行&控制——收尾
任何一個項目，最輕鬆的開始階段，反正啥都好說；最難受的是推進的過程，不是甩鍋就是撕逼，打架都正常；最尷尬的是收尾，對方不簽字的時候想要跪下去叫爺爺，收了錢老子就是天下第一。
這是一句玩笑話，但在「甲乙方」的項目過程中，司空見慣。
所以，項目開始的時候，醜話要說在前頭，開弓沒有回頭箭，開始沒講清楚的事情，到了後面就講不清楚。先做惡人，才可能有機會做好人。
不能實現的功能一定要拒絕，當前不能滿足的需求一定要明確，能達成什麼樣的指標一定清晰。
這個叫項目目標，所有後續的功能只能圍繞這個目標來執行，任何要推翻目標的項目行為，都不能被直接接手，必須啟動相應的機制和流程。
無數的項目證明，這是基本的定律。
項目目標和範圍是兩位一體的事情，只打30層樓的地基，就絕對不能去蓋50層的樓。
想要修改目標和範圍，一定要「重啟全新」的項目。
項目的坑往往就是在這個時候挖下來而不自知。
而後期接手的人，根本沒有任何辦法理清楚過去的糾葛矛盾，它會演變成一出N角戀——二手項目很容易爛尾。
失敗在所難免。
也就是：項目在開始和執行以及收尾的過程中，一定會要投入不同的資源，並催生各種需要控制管理的風險。
越是早前不確定性最高，甚至隨時都可以關閉，但損失可能小，越後後期越難控制，損失往往無法估量。
在項目的早期，一定要儘可能的預知風險，比如做硬體的，一定要明白，可能結構不行，材料不能準時到位，做軟體的也一定要知道技術的瓶頸在哪裡，而且，軟硬體要及時同步。
遺憾的是，我們常能見到硬體設備已經出來，軟體工程師還沒有入場，然後就發現各種「貨不對板」，彼此埋怨。
而硬體項目是不能像軟體一樣快速迭代甚至推倒重來。
3. 項目治理環境
項目早期的坑，最多是一個開胃菜，進入到項目之後，每個雷一旦引爆都可以逼停一個項目，這個環節最大的不可控因素就是人的因素——項目的環節因素。
沒有人可以逃過環境的影響，也沒有一種項目管理的方式可以超脫於外。
一個項目能否管好，不一定取決於你的努力，更多的是裁剪一個恰當的方式，符合這個環節的一種節制，和你所把控的那個節奏。
這是非常難的一件事，越是大的項目越難，在這種大項目裡面，對事不對人是絕對錯的，搞不定人一定搞不定這個項目。
環境因為包括組織的文化、結構、區域位置、行業標準、人事制度、授權機制，甚至法律法規等，任何一個項目都受其中的一些因素所影響。
在其中最具有直接影響力（殺傷力）的就是人，在項目裡面叫做干係人。
有的人對項目有積極影響，有的是消極影響。
比如拆遷經常會釘子戶，也有的時候，只要張三同意，李四就一定反對，諸如此類的情況比比皆是，所以搞清楚一個項目會涉及倒那些人以及什麼利益關係，比啥都重要，否則誰都可以是項目經理了，都可以發號施令了。
老實說，這個圖一定用都沒有，所謂分析項目干係人，其實就是找出那些對項目施加影響的人，特別是那些負面影響的人，背後捅刀子的人，得了便宜還賣乖的人，那些不按常理出牌的人，作為項目經理你可以給一個大家都可見的關係圖，但自己私下還要再準備一個。
所有的人和事，往往都是利益的事情。
搞清楚了關係，就要真正開始組織團隊了，這個叫項目團隊。
組成一個項目的人，都是各有所長（各懷鬼胎）的，作為項目經理就一定要分清楚職責職權，這裡面又會涉及團隊內部人的溝通，分享問題，以及各種獎勵懲罰機制。
這個圖是不是看著很官僚的樣子。
官僚就對了，這種結構的設計，就是為了保證項目組內的有序可控，對外有統一的出口，對內有穩定的次序。
不要隨便誇海口，更不要隨便瞎承諾，只有項目經理才可以享有足夠的權力，才能保證團隊內部的健康，和項目的健康，否則就變成一鍋粥。
每個人都有自己清晰的職責和許可權，「按部就班才可保平安」。
3. 項目過程資產
說完了，人和事。下一步就是物了。
如果說項目的環境因素可以讓一個項目萬劫不復。一旦管不好過程資產，那就一定黃土加身了。
這個資產，指的是一個項目在它整個生命周期裡面所有產生的，使用到的全文文件文檔，包括來自任何人，任何組織所涉及到的知識，文件，記錄的。
為什麼常說項目裡面那麼坑，有一部分原因就是沒有管理好這些「資產」，比如產品經理輸出的原型，業務流程不清晰，還沒有存檔。
所以，寫好一份文檔的極為關鍵的，管理好這些文檔是第二重要的是。
在過程資產裡面還有一些特殊的內容需要特別投入精力：項目本身的文檔。
項目計劃書、里程碑節點、變更控制流程、財務控制程序、缺陷管理程序等等，任何一個環節都足夠展開一個宏大的篇幅細說它的故事。
從這裡開始，熱身運動做完，可以開始埋雷挖坑了。
四、合適的人與靠譜的計劃
幾乎每個項目都有人吐槽，太坑太扯淡。
實際上，項目之所以會扯皮，往往在前期就埋了下巨坑，隨著項目的進程問題越來越嚴重，直到不能收場。
在上文我們已經釐清了項目的幾個核心概念 ，我們知道要想做好一個項目首先要搞清楚項目利益相關方，組建合適的項目團隊，然後我們需要分解我們的項目任務，制定一個清晰的項目計劃，才能指導和推動項目的進展。
我們現在從案例來還原項目前期的挖下的坑：
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的過程裡面，產品經理必須深刻的理解整個過程的艱巨，要能與團隊一起致力於整個項目的成功。
至此，本系列從項目和產品的概念出發，到項目環境的分析，以及對項目過程的幾大巨坑一一做了闡述，也許你還需要一些工具，或者模板來提高項目過程管理的效率。
———— / END / ————
TAG:人人都是產品經理 |