產品經理怎麼管理項目進度？

01-05

比如10個需求，產品、設計、開發、測試，先分別評估了時間。在實際執行過程中，需求可能變動了；評估時間未如想像的准；臨時插進來其它的小修小改，雖然每個修改耗時不多，但數量多，總體耗的時間也不少；不少東西需要多方確認，一來二去花不少時間... 總之最後，10個裡面可能有4,5個沒按計劃完成，老闆就問下來了，怎麼沒完成，雖然有理由解釋，但總覺得有點無力

此回答不討論產品經理是否應該進行項目管理。

以前在一些公司裡面，還專門有設項目管理這個崗位，但現在是越來越少看到了。我對這個崗位並不熟悉，但印象中基本都是由以前干過開發的人擔任，而且最好是前端後端都懂，這樣能夠更好地把握各項需求的工作量。

我不是學程序出身的，但在 100 人以內的創業團隊里負責或參與過項目管理，或者更確切地來說是進度管理。

作為一個產品經理，沒有工程背景，怎麼做項目管理呢？以下是我的一些個人實踐：

▎產品策劃提前兩到三個版本

產品的迭代是有一條循環的流水線的：需求發掘-版本規劃-方案策劃-方案評審-UI 設計-開發-測試-發布。一般而言，為了效率最大化，我們都會爭取做到相鄰的兩次迭代之間能夠無縫對接。也就是流水線上每一個環節的人在完成了當前版本的工作後，就能立即執行下一個版本的需求。

產品策劃提前兩到三個版本的好處是，當開發過程中發現有餘量時，可以把後續版本中的一些小的需求提前穿插到當前版本。

為什麼不提前策劃更多版本？很簡單，避免閉門造車、紙上談兵或構築空中樓閣。極端的案例是提前策劃無限個版本，這樣明顯是有問題的（相關回答：關於發現需求、篩選需求和設計產品，有哪些成體系的方法論？ - 鄭堅義的回答）。

▎明確每個版本的重點

一般而言，在一個版本裡面，我只會設置一到兩個重點的需求，其餘需求皆屬於可調整範圍內。 版本的重點不是看某個需求體量的大小，而是看這個版本的產品目標是什麼。每個版本的產品目標，都是在進行版本規劃時已經明確下來的了。比如我會把電商類產品的需求分為四大類：拉新、留存、活躍、銷售，在所謂的資本寒冬時，由於推廣成本居高不下，在短期的一兩個版本內，我可能會更加關注拉新和留存類的需求（在剛過去的 2015 年，當到處都是 VC 的錢時，很多初創企業只關注廣告層面的拉新，而且重量不重質，在投放精準度上極為粗獷，總之人傻錢多見效快，那就砸唄）。

這樣的話，在碰到開發時間不足，而又要確保產品如期上線的情況，就可以輕易地對需求做出取捨。

▎對開發成本的感知

雖然我不是學程序出身的，但也上過一些前後端的基礎課程，對「程序是如何發揮作用的」有著抽象的理解。因此，和工程師協作多了，基本自己都能大致地判斷每個功能是否好做，做的話大致需要多長時間。況且，除非產品的體量已經非常大，否則一般也不會有宏大和複雜到難以估量開發成本的功能。另外，在方案評審的時候，肯定也會和工程師確認開發成本如何。

有了對開發成本的感知後，每個版本能做哪些需求也就基本瞭然於胸。不至於出現原本以為做得完，後來卻發現時間遠遠不夠的情況。

▎MVP 原則

最小化產品原則其實很多人都知道，但在工作上真正用到的人卻不多。怎樣才算最小化？這個邊界我們很難定一個標準，但也沒有必要摳得這麼緊。只要明白「在做一些很大的功能時，有時沒有必要一個版本搞定」就行了。當然，這句話說得簡單，但如果前期沒有進行全局性的思考，忽略擴展性的話，可能一不小心就埋了大坑。

在常規的迭代中運用 MVP 原則，除了基於其低成本快速試錯的內涵外，其實也是為了更好地控制項目的開發周期（相關回答：產品設計的「節奏感」該如何把握？ - 鄭堅義的回答）。

▎精簡而有效的文檔

文檔太冗長，所有人都不想去看。沒有文檔的話，人的腦子又沒那麼好使，溝通會變得反反覆復，工作流不停地被打斷，大大降低工作效率。怎樣的文檔才是精簡而有效的？基本上交互的流程圖及頁面的元素說明得有，一些基本和關鍵的實現邏輯、判斷流程也得有。而且文字得簡練、客觀、規範。這樣一來，可以減少很多臨時性或重複性的溝通，確保時間都花在了做事情上。

▎少改需求

指的是開發的階段要少改需求，甚至盡量凍結需求。因為每一次改需求都需要同步變化，而及時、準確地同步變化並不是一件容易的事情。更糟糕的是因為需求的變更，導致之前已經完成的一些工作要推導重來。這樣不僅增加了不在計劃內的工作時間，還影響協作的情緒。

要做到少改需求，只能要求在方案評審的時候更仔細，把各方的意見和疑問充分地溝通清楚。

▎充分利用好協作工具

協作工具確實是能夠明顯地提升項目管理的，比如說通過統一溝通渠道從而節省時間、避免重複溝通，自動同步信息等等。國內外可供選擇的協作工作不算多也不算少。雖然有些確實明顯地比另外一些好，但如果由於某些原因導致團隊必須用某一個不是最好的協作工具時，問題也不會太大。因為基本所有協作工具都能滿足項目管理最核心的幾個需求，關鍵是你會不會靈活地使用（相關回答：你的團隊內部是如何進行項目管理和協作的？具體流程如何？使用什麼工具呢？ - 鄭堅義的回答）。

▎及時同步變化

如果需求的變化不能及時同步，將會導致溝通成本增加，以及不能通過驗收而需要返工。人少的時候，同步變化其實不是什麼困難的事情，但人多的時候就有難度了。雖然很多協作工具都有文檔更新通知，或者文檔本身就有修改記錄。但即便如此，也會有很多人忽略這些變動。在同步變化上，除了確保文檔及時修改、告知相關設計師、工程師和測試人員以外，我還會單獨召集各平台的 leader 進行簡單的站立會議，提醒其確認變更是否已安排執行，同時也相當於交接了監管的責任。

▎開發及測試進度 review

需求正式發布後，各平台 leader 都會拆分任務，將其指派給具體的個人，以及設定好完成時間。我會設置兩個開發進度驗收時間及兩個測試驗收時間。開發驗收時間主要是提前確認進入是否如期，如果有延誤的話，原因是什麼。如果是不可抗因素，則重新評估開發的進度計劃；如果是可抗的因素，則要求在後續想辦法趕上原計劃的進度。第一個測試驗收時間和開發驗收有點類似，主要是看進度是否能跟上，如果不能跟上的話，是需要及時調整還是加把勁追趕。而第二次驗收時間則是評估哪些問題可以暫時擱置，哪些問題必須解決。

這兩種驗收時間的設置親測十分有效，基本避免了快要到期卻發現發布無望時各方的各種理由及轉移責任。

以上是本人作為產品經理在項目管理（更多是進度管理）上的一些經驗和看法，歡迎交流或指教。

首先，這是一個仁者見仁的問題，儘管有不同的項目管理理念，但在實際開發中真正轉化為價值的都是各個公司和團隊，自己摸索的。另外，敏捷方式的開發，在中國其實鮮有完全敏捷的。

另外，需要弄清楚一個基本的概念就是將產品的管理和開發的管理最好不要混為一談。對很多中小團隊來說，可能形式產品和開發的是同樣的團隊和同樣的人，但在驅動產品和驅動項目這兩件事情上，最好還是有所差別。至少產品更關注的是產品、功能、方向和反饋；而項目則更關注進度、質量和測試等。

回到樓主的問題，我覺您關注的重點，其實是如何讓團隊適應項目開發從計划到落實的節奏。要做好這件事情，根據我們自己的經驗，其實重點是以下幾個方面：

做好評估。幾乎所有項目最終未按計劃執行，其最根本原因就是在項目開始階段，沒有對需求、技術、產品有足夠充分的了解，也就沒有後續開發中的可控力度。高估和低估都是有問題的，所以我們常用的做法就是非常重視前期的評估，寧願多花時間，並且對有模糊邊界或者有挑戰的問題，留足buffer。
將計劃落實到可執行的單元和可執行的人。有了評估，然後就是將計劃落實到足夠力度的任務，以任務驅動開發過程，任務落實到責任人，任務要標明截止日期。在此，通過一定的工具來管理，是十分必要而可控進度的。例如我們基於自主產品 Worktile 的任務驅動方式，就可以很好的將開發計劃落實到任務和可執行的人，而Worktile的簡報(我的任務簡報，讓自己的事一目了然)則會以直觀的方式來告訴負責人項目整體的狀態、執行者的情況、被delay的事情有哪些。總之，工具的輔助需要團隊開發想法的驅動。
小步快跑，不斷迭代。小步快跑，快速迭代，是已經被驗證的最好方式，只有在足夠小的粒度上設置里程碑，才不會造成整體的項目受到大的影響而被無限期延後，這是管理者需要非常清楚的。另一方面，快速迭代，也有助於發現問題，然後快速解決。

以上是我們自己在開發產品過程中的分享，可以分享我們之前的一篇經驗以供參考如何使用Worktile進行敏捷項目開發管理，總之，每個團隊都是不同的，結合團隊本身的特點量身定做是項目負責人非常重要的職責，了解產品、項目、團隊，然後細化可控的任務驅動，這是值得參考的經驗。

從描述中看，問題其實應該換成，產品經理應該怎麼拒絕突然更改的需求？

描述中描述的是由於需求的變動，增減，導致項目時間與評估時間不符。但反過來，有這麼個問題，

需求為什麼會變動？

是因為：

1、之前並沒有考慮妥當→以後要考慮妥當，對項目管理的進度把握就會更好；

2、突發奇想，想到更好的需求

3、商務、客服、技術等部門的建議

4、老闆的需求

2、3、4→先考慮這個突發奇想的需求是否非得在這個版本實現？要學會say no。版本控制是項目管理的基礎。減少突發需求往現在版本加。

其次，給一整段的時間周期，確定若干檢查點，將目標細化，更有利於時間節點的把控。

撇開你的問題，其次可以與技術實現人員加強溝通，比如技術開發需要的資源是否準時到位？他們有什麼問題導致工期的增長等等，從問題去剖析問題在哪裡，並把出現問題的點去fix，這些都有利於項目管理的。

-----------------------------------------------------------------完美的分界線------------------------------------------------------------

我的答案或許還是不夠完善，期待其他童鞋的補充，我也可以一併學習學習！

@徐海峰謝邀

其實作者所提到的是項目管理中最重要的過程：變更管理 Change Request。之所以大家不知道怎麼做變更管理，是因為很多產品經理身兼項目經理的職責，而產品經理本身對於項目管理了解的並不是很深。我們先來看一下實施變更管理過程中的幾個主要過程：

1. 提出：詳細記錄變更，可以把它看成是一個備忘錄或者收件箱，變更提出者要能夠非常容易的記錄下變更的詳細信息。

2. 審核：確認是否要實施該變更，在這個過程中需要對變更進行評審，確認是否需要變更，以及變更對已有部分所帶來的影響。

3. 實施：根據變更的詳細要求進行具體的實施，其中可能涉及到產品、開發、設計人員的參與。

4. 確認：對變更的結果進行質量保證，確認變更的實施是正確的。

5. 度量：對變更的過程做度量分析，這個過程對於變更管理是非常重要的且有意義的，通過對這些變更的分析，就能知道當前項目的進展情況，以及存在的問題。

變更管理中每個流程之間互相影響，互相作用，並且需要對變更的結果進行度量分析，如果沒有選擇一款好的變更管理工具，其結果會非常糟糕。就會如問題的提出者所說的那樣：雖然有理由解釋，但總覺得有點無力！

我專門寫了一篇文章來說明這個問題：如何使用Worktile進行變更管理

題目有些大，但看內容，實際上還是被無數次提出的「如何管理變更」的問題。

一句話原則：只有成熟的變更才可被應用。

項目管理中，對於變更有專門的探討。其實有很多成熟的方法和經驗和參照。

在項目進行的整個周期中，對範圍的控制是無時無刻不在進行的。

面對不同的項目，不同的客戶，實施變更控制的方式各有不同。但歸根結底還是那個原則：

只有成熟的變更才可被應用。

具體來說，對於項目經理，首先需要具備「說不」的心理素質。一旦一個項目的範圍定義清楚，管理計劃確定，正常啟動，那麼對於收到的所有變更需求，從本能上應該先以「拒絕」為出發點。

然後，任何變更需求，需要進行完整的變更控制流程。這包括：

通知到主要人員，包括客戶，你的架構師，測試組Leader，上級Boss。
分析變更帶來的進度影響，成本影響，可能的風險等等。
給出你的專業建議，該變更的投入產出比。可控及不可控的風險。
結果有兩個

衡量投入產出之後，客戶放棄變更。
在充分分析了風險和成本，並據此調整了工作範圍和進度表之後，如果客戶和BOSS仍然堅持變更，那麼OK，請BOSS、客戶簽字認可變更（包括你調整後的範圍和進度表，以及需要額外投入的人力、資金投入申請，也許會有為了保證進度而放棄的其他特性）。

當然，如果你足夠有經驗，還應該從客戶的角度去分析這個變更的真實目的，是否有更好，更經濟的解決方案。這是題外話，這裡不展開了。

=== 補充 ===

@張達提到，項目經理是否需要了解項目中用到的技術。遷移評論中的回答如下：

如果只是為了盯進度，不了解技術其實問題不大。只要有可信任的團隊成員就行。但是項目經理常常需要給客戶解釋一些技術問題，了解技術還是需要的。同時，在實踐中，了解技術的項目經理更容易跟團隊溝通。

項目經理對技術的了解不需要很深入，能達到跟技術團隊溝通無障礙就好。

「項目經理主要是盯進度，不懂技術完全做不到保證進度符合日程。對設計要了解到非常細節，但是不了解技術完全無法了解到細節。」

這一點是個誤區。對於不直接參与技術工作的項目經理來說（直接參与的除外），技術背景只要不影響溝通就足夠了。項目經理的「技術」，就是各種項目的把控方法，溝通技巧等等。項目本身用到的技術，對於項目經理而言，就是個用來溝通的「工具」。

「懂技術」是無法在短期內實現的。所以我們一般來說，要求項目經理有一定的行業背景，對技術有一定程度的掌握。比如，你無法讓一個優秀的IT項目經理去指揮一個建築工程。

項目經理在面對團隊的時候，關鍵是溝通。無論從設計上，實現上，都必須能夠準確傳達你的意圖，反過來準確理解團隊反饋的信息。

所以，只要並非對技術一無所知，都不會影響到進度的掌控。畢竟，實現功能的是團隊，而不是項目經理。即使是一個真的完全不懂技術的項目經理，只要善於使用各種管理技能和工具，減少技術壁壘帶來的影響，也有辦法讓項目正常推進。

那麼，項目經理如何盯進度？

總體進度圖、控制圖、工作分解圖、燃盡圖、關鍵路徑法、PERT分析……

這些才是項目經理，尤其是專職的項目經理應該掌握的技能。

如果是專職項目經理，建議系統性的學習項目管理知識。這不是一兩個問答就能解決的問題。

如果是技術骨幹兼任項目經理，理論上說，不存在技術壁壘。同時，由於是技術骨幹，就在管理上具備了「專家權力」，算是最好使的一種權力。:)

最近一個月剛好在上面有一些自己的思考。

計劃，記錄，總結。

我設計部門的項目管理的流程可以拿出來讓大家批評指正。

首先我們要明確，為什麼要項目管理？項目管理的目標是什麼？

一，項目「可視化」。一個需求轉化為開發工作量，一個註冊登錄的流程，要產品設計多少工時；

二，明確和目標（老闆給的指標）的偏差，按照實際的需求選擇調整老闆的期望還是調整開發資源；

三，記錄項目中發生的問題，給予解決；確保項目在計劃中進行，如有問題及時對整體項目（開發資源）進行調整；

四，讓每一個崗位上的工作人員知道自己的工作目標，以及什麼時間點能有什麼資源做什麼事；

五，項目中的記錄和反饋，進行總結，對一些問題吸取經驗。

ok，如果我們在這裡達成統一的話，可以繼續看下去了。

項目，從單線程來看，可以看做是流程+工具

單線程的流程，我簡單整理如下

當有一個需求產生的時候，
1. 產品經理和設計開發先溝通對可行性有初步的預期（如果覺得需求不靠譜提出來），完成原型（原型由產品負責人確認），擬定初級項目計劃表（只是拆分功能，記錄產品預期節點和開始的時間）
2. 提前人員確定，各小組的負責人確認，項目小組成立
3. 項目小組人員參與需求評估，該會議的目的完成兩樣東西
① 把產品細節交代給設計和開發
② 明確需求之後設計和開發給出相應的開發計劃（如果允許給開發和設計充足評估時間，保證預期時間儘可能精準，時間維度盡量能夠被控制，項目節點控制在一周之內），產品經理協調之後最終確認項目進度計劃表
4.期間不斷溝通解決問題，每天早上項目例會，由項目負責人（產品經理）主持，明確每日進度，協調昨日工作的問題。一般就是產品和開發，設計看需求要不要參加。
5.項目節點通知相關人員參與評審
6.評審結果反饋，調整

有一段時間陷入了痴迷工具的狀態，但是工具是解決需求用的，是為了工作流服務的，進而提高效率，切不可本末倒置。

在1中，產品經理需要有一個初期的表，這個表上面用於記錄這個項目的開始時間，版塊拆分（難點在於分到多細，因為它沒有被量化的標準，目前我們的方向是控制在一周左右）

在2,3中，這個表裡面補齊相應版塊的負責人，以及各個版塊的重要節點預期。

在4中用到項目管理表和個人工作記錄表。每位成員每天下班之前，花十分鐘左右，記錄自己一天的工作任務在個人工作記錄表中，（有什麼需要產品經理或者項目組其他成員協調解決的內容，記錄在表裡。然後產品經理在第二天的上班第一時間查看一下各位的進度，沒有記錄在項目中的就記錄（複製）在項目管理表的相應位置，看一下有沒有什麼問題是需要在例會上解決的，整理後組織項目組例會，解決問題。

我們公司目前的項目管理工具一共有四樣：

微信群，Tower，Google doc，面對面。

微信群：

強迫公司的同事用了一段時間的釘釘，無奈放棄，很多人的工作和生活分不開，我有一段時間喜歡把微信當rtx用，後來習慣把所有群屏蔽之後一旦有群新消息就知道被拉新群了 (⊙﹏⊙)b。扯遠了，微信群方便快捷，我覺得對小公司太合適不過了。大公司可能需要有比較複雜的通訊錄，不發散了。

Tower：

Tower好用啊，我們之前的項目需求，bug，優化都放在上面，我給它的定位是處理詳細的需求，比如上面提到的註冊登錄功能，具體的原型圖，設計圖，開發的問題記錄，都在一個任務裡面能找到~當然同類的產品還有很多，就不一一列舉了。設計師的共享設計圖的平台是堅果雲官網 - 堅果雲，下載客戶端更新同步知會。

Google doc：

最近用Outlook和Google doc用的甚是開心。在如何利用Google doc上面花的時間比較多。Google doc主要是實現文檔在線共同編輯。

一個項目一張表。以目前我們手頭開發的Android移動版為例。

表頭：

底部的sheets：

其中的要點包括模塊的拆分；每一個參與項目的工作人員有兩欄，一欄計劃，一欄每天記錄；有一個需求池處理你的版本計劃。這裡不展開了。

面對面：

最後不要忘了我們還有面對面的溝通。在大公司可能從一個部門跑到另一個部門要花很長時間，更多人願意通過線上溝通，但是小公司有時候面對面的溝通更高效。我目前正在「強制」我們的項目小組進行每日例會。例會也是一個關鍵點。

以上基本就是我司單線程的項目管理的流程和用到的工具。很明顯的硬傷我也能夠看出來：工具太散了，未來還會繼續找符合我們公司開發流程的工具，指不定自己開發一個~

下面是多線程的。我覺得多線程終於可以講到「節奏」這兩個字。

多線程的問題來源於有限的開發資源和無限的項目網（縱向和橫向）之間的矛盾。

縱向的，版本的更迭：

需求是無限的，需要有一個「需求池」，一個一個需求就像是一道一道的菜肴一樣，要被裝好盤子，端到相應的賓客桌上。每個需求需要確認優先順序，然後把他們放到各個版本之中。需求+BUG基本就是下一個版本的changelog。

相隔兩到三個版本，因為流程問題不同技術人員之間存在時間差，用流水線的思路去想，就是為了保證「每個工人拿到的是一個可以加工的零部件」。

關於多線程目前我和我的小夥伴們也正在嘗試，總結。

另外從有如此強烈的覺得，產品經理應該多點設計能力+開發能力，感謝我司小夥伴的支持，理解和幫助。 @nekocode@Dennis Yang@李曈韞以及公司其他的小夥伴們。

因為產品無法按期或者延期上線有多方面的因素影響，boss，產品，開發，測試等，說白了，鍋可以背但是不能隨便背，或者背了也要明白。目前自己兼項目管理，我就說說自己目前在產品研發管理里的實踐：一些環節上的多方配合和調整我想對產品有序開發推進有一定的保障。下面是自己產品研發的流程，拋開收集需求階段，直接進入產品研發階段：

1，確定需求階段。這個階段需要跟boss敲定產品方案，產品方案主要是圍繞需求出發的解決方案，包括產品定位，功能線和目標產出。防止後期boss一拍腦袋變卦了。確定好之後依據產品方案繪製業務流程圖、低保真demo和需求文檔（如果時間緊迫，文檔可以後期彌補或者在低保真demo上備註詳細些）。注意在出低保真demo時最好能和視覺交互設計師一起，並達成共識。

PS：我將整體方案切割，梳理成不同的功能線。功能線是一個功能點集合，可以拆分成各個功能點。比如登錄註冊功能線，有登錄，找回密碼，註冊三個功能點，每個功能點包含不同的功能元素，比如獲取驗證碼。

2，需求評審。評審階段相信大家都很清楚：需求分析並確定工期。這個階段參與者包括老闆，設計師，前後台開發，測試，運營，市場。評審之後根據意見對流程和原型進行修改，最後得到一個大家都認可的確認版本（這是公認的版本，後面誰敢亂動基本上就是誰背鍋了）。然後讓前後台開發負責人和測試負責人根據功能點複雜度評估每個功能點的開發時間。然後出一個開發計劃表（如果有項目經理那就直接請他幫忙處理吧）。這個環節是考驗產品經理能力的時候，如何平衡各方面的利益並保質保量完成產品上線。

PS：每個功能點的開發時間能夠量化，每個功能線就能量化。這樣在後續執行的時候就能做到心裡有數，即使後續變化也能快速調整。

3，設計高保真效果圖階段，產品經理需要注意的就是對高保真效果圖進行評審，防止後續開發過程中被返工，」咦，這個設計不對啊，之前不是這麼說的！「。不過這個只需要產品經理和視覺交互設計師一起看看就行，如果碰到頁面特效方面的不確定性可以徵求前端開發的意見。

PS：在空下來的時間可以出一個相對於低保真的高保真的demo，移動端可以用墨刀、mockplus實現，讓大家能體驗到與真實產品更加接近的樣子。

4，開發階段，由前後端負責人更新開發計劃，確定一個固定早會時間（一周一次即可），對過程中的問題進行反饋並解決，因為我們之前對於工作量是按照功能線規劃，精確到功能點的，如果碰到人員調休還可以及時調整開發計劃。

5，提測。按照功能線開發並提測去操作（而不是瀑布式開發提測），完成一個功能線即可交付測試進行測試，這樣開發就能進入下一個功能線的開發並在空餘時間修改bug。

以上是個人實踐過程中一些點，當然每個項目都不能順風順水，很多時候計劃趕不上變化，那就及時應變

為啥要分別評估？拖部門負責人出來(第一次和受阻時)，老闆鎮場(第一次、最後和受阻時)；拖幹活的人出來(周會)，開會。

說明白需求1234分別針對什麼場景，解決什麼問題。會上讓老闆發話在幾月幾號上線。按上線日期倒推各部門完成時間，按進度每周一碰頭會(月交，周交每天會)，各部門彙報進度，完不成說明原因。

進程時間過半完成度滯後，屬於受阻，拖部門負責人和老闆群會。

記得會前溝通好，別一開會就吵架。

和老闆溝通好獎金，開會第一句：今天我給大家發福利，感謝x老闆的傾情贊助。過去的一周我們一起完成了123，現在還有456，預計幾號上線給大家發錢~現在距離發錢的時間就xx天了，大家進度上有沒有問題？沒問題散會。

我一般開會半小時到一小時。

超一小時，請反省會前資料與溝通的不足。

會議目標明確：讓大家一條心，獲知真實困難節點，攻克。按進度出成果。避免各部門間踢皮球。

老闆是鎮會神獸，進度很好和很不好都可以拿出來擺：啟動、受阻、慶功。

總結：陽光工程+借力

首先，我很反感需求評審沒有完成，就定義項目上線時間的行為，這種事情是極其不負責任的。如果老闆說上線時間是一定的，那麼pm要做的工作，就是清楚老闆務必保證的功能是哪些，盡量的完成功能，然後為後邊的兄弟節約時間。

把相對來說分支的功能做到二期，然後說服老闆接受。否則第一個大版本無比巨大，接下來你們怎麼升級？

向上管理，降低老闆對於第一期完美度的預期，是每個pm都要掌握的工作。

第二個確認。按照歷來的想法都是，郵件發送15分鐘，如果在一起就進辦公室給演示，如果不在一起就電話催。務必當天確認不能隔天。對於已經預定上線時間的項目，每一天都是寶貴的。

第三個。作為pm，技術兄弟們多挺你，就看你怎麼做人了。人心都是肉長的。他們只要明白，你不是為了壓榨他們向老闆證明你項目管理多牛逼，而是項目本來就是這麼緊急。他們會爆發出無窮的戰鬥力的。

最後，不要壓縮測試工程師的時間。測試前要求工程師冒煙自測。

樓主的問題看似是時間控制的問題，實際上是四個方面的問題。

第一，有可能是前期的需求分析做的不夠充分，導致某些主要項目干係人的需求沒有被充分挖掘（比如客戶或用戶的），導致後期開發時修改很多，導致時間不可控。

項目初期時，客戶往往不怎麼願意花時間分析自己的需求，有許多客戶甚至還不太清楚自己的需求。這個時候就需要項目經理「出手」，多花時間主動了解客戶的需要，挖掘客戶的需求，形成規範的文檔，讓客戶簽字。即使這個需求還不是很完善，也要讓客戶簽字。因為只有客戶簽了字，才能確定項目範圍，才能確定哪些是需要做的，哪些是不需要做的。然後根據這個範圍，製作一個WBS，也就是項目工作分解，接下來做具體的計劃，分配具體的任務，項目才能積極推進。這樣做，也契合契約社會「先說斷後不亂」的契約精神。項目在執行的後才可能減少被迫改變的囧境。

第二，是時間估算的問題。

這裡面還牽涉風險的評估，所以項目經理應該給團隊留出相應的時間冗餘來處理風險的問題。

第三才是時間控制的問題。

常用的方法有關鍵路徑和關鍵鏈等。

通俗介紹，請大家參照這段「水煮三國」中的文字

豬和老婆趕到前廳的時候，果然見唐僧和高老爺在爭吵著什麼，只聽得高老爺說：「我蓋了一輩子房子，卻要你這和尚來教訓我？」唐僧道：「我不是教訓你，我是在說明一個道理。」高老爺道：「有什麼道理好說，我的億科房地產現在不是蒸蒸日上？沒準明天我爬個月亮，做個登月第一人。」

豬邊走進來邊說道：「那是后羿，也輪不到你。人家比你更急切。」豬夫人拉了拉豬的衣服低聲道：「獃子，胳膊肘往外拐不想混了？」嚇得豬忙閉上嘴巴。高老爺見女兒女婿都來了，便道：「剛剛唐博士說我資源浪費，不懂計劃的執行，我們蓋房子都是憑經驗，你說的那洋玩意我們可不懂，可房子照樣還是蓋起來了。」猴子插話進來：「沒說你蓋不起房子，先進管理方式的運用可以節省成本，優化資源配置。我舉個簡單的例子來說。」猴子說著拉過白板畫起來。

一個點A是長安，一個點B是西天，現在我們師徒四人要從A到B，假如我們各自出發，我的筋斗雲比較快，一個跟頭就是十萬八千里，豬比較慢，師傅更慢，路上再不小心跟妖精聊聊家常，顯然到達B的速度回不同，但有個前提，必須我們四人全部到達B才能領取經卷，你說我們領到經卷的最短時間是誰決定的？

高老爺說：「是佛祖，他說什麼時候跟就什麼時候給！」猴子笑道：「你說的也沒錯，佛祖是我們的領導，當然有決定權，但我說的就這個事件本身，卻應該是由唐僧決定的。」高老爺困惑的問：「為什麼？」猴子道：「因為唐僧到達B的時間最長，也就是說我們領到經卷的最短時間是由耗費時間最長的人決定的，如果我們把四人到達B的路程當作路徑，那麼就是由最長的路徑決定最短完成任務的時間。」高老爺微微點頭，略有所思。

我告訴你這個有什麼用呢？我們蓋房子有不同的工序，可以劃分成不同的路徑，然後找到最長的路徑就是關鍵路徑，控制了關鍵路徑就控制了進度。高老爺問：「那我就拚命壓縮你說的關鍵路徑上的時間就好了？」猴子道：「我剛才說了有不同的路徑，你壓縮關鍵路徑到一定程度，另一些路徑可能又成為了關鍵路徑，所以你壓縮時間的時候要注意，我們要做的就是向關鍵路徑要時間，向非關鍵路徑要資源。」

高老爺點點頭道：「你這麼一說我就明白了，原來蓋房子的時候有很多線的，也就是你說的路徑，我需要對這些線進行仔細的辨別，才能提高我們蓋房子的效率。」猴子扶手大笑：「果然是老莊主，腦筋轉的就是快，明白了這一點你就明白了好鋼用在刀刃上這句話，做事情就抓住重點了。」高老爺又問：「你剛才說的向非關鍵路徑要資源指什麼？」猴子回答說：「資源指你可以用來加快進度的一切，比如你的預算，人力，物力等。」

高老爺一時好奇起來：「大聖能否再詳細點解一二？」猴子笑道：「肚中無糧，心裡發慌呀，能否吃點簡單的齋飯再敘？」高老爺哈哈大笑：「看我的腦子，只顧說話竟然把這個事情給忘記了，各位師傅快快有請。」眾人隨高老爺吃晚飯，一夜無話。

關鍵鏈可以較有效解決員工拖延的問題。（點擊下面的視頻參考）

第四章項目的執行-4.2項目的進度控制3關鍵鏈

最後一個問題是和老闆的溝通的問題

樓主說，最後老闆都不理解為什麼項目延遲了。這個責任在項目經理。和老闆的溝通不光是有問題才去找老闆。平時應該有常規的溝通計劃。

比如：對老闆，什麼時候溝通，以什麼樣的方式溝通，溝通的頻率是多少。採取的方式可以是一個月的報表，或者是面談，或者是項目的彙報會等等。對其他項目干係人，也存在同樣的問題，也要提前計劃溝通方式、溝通頻率，包括日常的溝通和特殊情況下的溝通。相關的信息收集上來後，經過整理加工，形成表格、圖片、統計圖等簡潔直觀的資料，定期報給相關人員，有問題提前說。很多領導很多客戶願意看到這些東西，特別是領導。這裡有一個問題，很多人在跟領導彙報工作時有一個「怕」字，怕和領導說話。其實沒有必要，領導實際上很願意你簡短地把問題講清楚：現在項目進入到什麼狀態，順利的地方是什麼，遇到的困難是什麼，下一步可能出現的風險是什麼。領導很喜歡聽這幾句話。聽了後，他會從他的角度對你的工作進行指導，對你很有幫助。也會對項目的最終結果有所理解。

1、需求要明確：不明確的需求對後期整個項目的管理可想而知。

2、目標要可行：需求有了，是一步到位還是分布實現？明天實現哪布需要從實際出發，執行切實可行的目標。將大的需求拆分成若干個小的里程碑，每個裡程碑拆分成若干個檢查站。

3、調研要充分：需求、目標都有了。怎麼做、做到什麼程度，需要進行充分的調研。需要聯合各個相關的部門，一起進行調研。調研是針對需求、以及未來可能的需求，還有開發的進度，各個部門的參與配合程度等等。

4、組織結構：是否成立項目組，是否以有利於項目開展的組織結構推進這項工作，是相當重要的。否則可能面臨推諉、責任缺失、跟進不到位、懲罰無依據等種種管理問題。有條件的單獨成立團隊管理，沒條件的可以組建矩陣團隊。

5、設定寬鬆期：在制定各個裡程碑、檢查站的時候，中間留一定的時間。作出一定的富裕。

6、資源保障：投入多少人、財、物去做，如何保證人、財、物及時到位的投入是對項目進程的有力保障。換個角度也可以理解為項目可行性分析。

7、項目負責人的經驗，管理能力：就是以上方面的綜合能力，是各個方面執行過程的監督以及質量把控，項目負責的一把手。

以上每個因素都會影響項目的進度以及質量。

其實客戶提出修改要求，你應該定期向老闆彙報，讓他知曉你有部分時間和資源花在變更計劃和調整執行上面。

同時如果有一些小改動是不必要的，合理拒絕是努力方向。

項目進度管理，偶也覺得好難，也沒做好，「人本身的因素太多了」。

項目進度受挫，原因可能有三：

1、需求管理和新加需求，優先順序沒有明確；

2、需求的耗時評估，沒有設計、開發的資深人士參與，考慮不夠全面；

3、團隊內部，包括開發和設計，對項目理解不夠（或者說，你的宣講不夠，大的項目，開始前要盡量確認每個成員，至少明白項目的用戶群體&<確保討論的是同一群用戶&>、商業價值&<跟項目獎金或個人成長有關&>）；

新加入需求，每個提需求的人，都需要填寫這個單子，確保其經過思考，針對外部門的高管，可以堵堵嘴。（表格系某本書提供，忘了出處）

目標用戶

這件事，是為誰而作的，一旦運營開始從這裡思考問題，就可以自己排除很多需求了

問題描述

目標用戶碰到的痛點，只說「何時/何地。怎麼難受」即可；驗證程度對問題嚴重程度的判斷，「高/中/低」即可，具體的判斷方法，可以根據用戶重要程度(這個比較主觀，需要團隊一起討論達成共識，我們的產品是為哪幾類用戶服務的，他們的優先順序排序是什麼，這是產品原則的關鍵內容)，問題出現的次數、頻率等因素(相對客觀，比較好辦)考慮; 現有方案

現在是如何解決此問題的，我會認為，一個值得解決的問題，通常已經有人著手解決了，所以也一定已經有一些解決方案，而沒有現有方案的問題，通常不嚴重;

建議方案

建議的產品改進，這點其實是借運營的腦幫助思考一下，產品不一定採納;

價值描述

改進方案帶來的額外價值，比如：省時間;能更精準的找到某某……

改進成本

建議方案的成本評估，「高/中/低」，同樣，僅供參考

性價比

嚴重程度/改進成本，問題(用戶需求)決定嚴重程度，解決方案(產品功能)決定改進成本

需求的耗時評估，要麼找技術高手，要麼找技術主管（他們給個耗時評估，是要對評估負責的）

關於項目進行中的各種溝通、各種bug，可以用worktile管理；代碼或版本管理，用coding。

（大家知道彼此的進度，互相監督，互相促進）。

以上

產品經理不要干涉太多關於產品進度方面的東西，你只需要讓項目經理定期把計劃執行情況發給你就可以了，比如project。

產品經理太多的關注，對項目執行的進度可能會有幫助，但是對於項目的質量，絕對是沒有任何幫助的。

在我做項目經理的過程中，如果客戶或者業務部過來詢問項目研發方面的東西，我會很認真的回來他們的問題。但是牽扯到進度方面，我盡量迴避。因為他們一旦談到進度，目的只有一個：趕緊給我估出來。因為他們對技術不是很懂，他們不知道技術難點在哪裡，哪裡有問題，怎麼解決，解決需要多長時間，解決了之後需要做怎樣的驗證後，才能給出樣品。

有時候，迫於壓力，我們只好臨時組裝出一台樣機給到客戶或業務，而質量情況，連我們自己都不清楚。因為只測試基本功能，很多軟體可能存在的BUG沒去檢測，硬體電流、信號、靜電等其他方面，壓根就沒仔細去核對。我們甚至出現過，寄出去的產品少打了兩顆螺絲。（因為我們的習慣是，對產品進行臨時固定，完整測試OK後再全部封死）但是那一次，測試完之後就直接被拿走了。

所以，產品經理千萬不要過多干涉產品進度。如果是他們不做，你可以利用你的權力去迫使他們行動起來。如果他們在做，你只需要讓他們給你報告進度以及階段性成果就可以了。這樣，項目人員才能按著一步步的計划去實施。才能保證產品按質按時地完成。

現在很多公司都有項目經理這一職位，由於內部結構的規劃也有可能是產品經理進行項目管理。

針對這個問題諮詢了我們豈安科技的項目經理阿木，答案如下：

首先我們來看看什麼是項目管理：

項目管理是管理學的一個分支學科，對項目管理的定義是：指項目的管理者在有限的資源約束下，運用系統的觀點、方法和理論，對項目涉及的全部工作進行有效地管理。即從項目的投資決策開始到項目結束的全過程進行計劃、組織、指揮、協調、控制和評價，以實現項目的目標。

項目管理的兩大主流管理模式分別是：傳統項目管理和敏捷項目管理。

但是不管是那種類型的項目管理模式，「事先計劃，事中控制，事後總結」的原則放在處理任何事情上都不會錯。

事先計劃：

在現實的項目管理過程中，其實可以根據項目的實際情況來制定相對完整的項目計劃，以軟體開發項目為例，項目計劃可以包括以下幾部分：

確認軟體的作用和主要功能
根據主要功能，明確軟體的功能範圍，包括限制條件和約束
根據功能範圍，創建開發任務
根據開發任務，評估開發周期和時長，安排資源和時間進度；還可以完成費用預算和風險評估（有時候風險評估也會單獨作為計劃中的一部分被考慮）
如果功能需要外包，可以把採購列入項目計劃中
安排溝通計劃
軟體的質量驗收流程和驗收指標
把以上所有的計划進行匯總整合，合理的安排資源和考慮其他因素，形成一份整體的項目計劃

如果計劃不全面，資源、成本和溝通都會成為項目過程中的潛在問題，整個項目團隊都是在到處填坑，疲於應付的狀態中。項目管理整體包括範圍、時間、成本、質量、人力資源、溝通、風險、採購和所有干係人管理，如果要把完整的項目管理系統搬出來，可以推薦大家看一本書，PMBOK。

事中控制

遇到過很懂計劃的項目經理，溝通能力和技術能力都很強，但是因為項目管理往往更容易傾向於技術實現，所以很容易忽視客戶的理解，這也是項目過程中經常會有客戶提出改變需求的原因之一。

所以，就算計劃做的再好，也會有被忽視或者不受控制的問題發生，這個時候只能盡量去控制問題的影響。

公司產品問題反饋的渠道會有很多種，銷售和運營可能是收集客戶問題的主要來源。

從銷售角度出發，產品問題的嚴重程度會影響到合同和業績；
從運營的角度出發，產品問題影響到的是部門的報告和數據的準確性。

大家都希望問題越少越好，解決問題的速度越快越好。但是售後技術支持團隊只有一個，所有人都恨不得把售後技術資源據為己有，優先解決影響到自己的問題。

這個時候項目管理可以做到的就是：好的幫助銷售和運營協調售後技術資源，把控問題處理的優先順序，以最小的損失處理最大價值的問題。

事後總結

在項目管理過程中，我會把問題總結分為兩個大類：一類是風險，一類是缺陷。

項目中，還沒發生但隨時可能發生的問題，在項目管理中叫識別的風險，會記錄在風險登記冊中，並給每個風險制定了應對計劃；
已經發生的問題經常容易被歸類成缺陷，被記錄成問題日誌，需要分析問題的根本原因，可以改善項目管理過程，避免同樣的問題重複發生，也可以為後面的項目提供經驗教訓。

一切問題的總結都是為下次更好的解決問題做準備，所以經驗教訓其實就是項目管理的一個重要成果。

「事先計劃，事中控制，事後總結」原則上升到管理學可以用一個通用模型來解釋——PDCA循環（戴明環），又叫質量環，特點是：周而復始，大環帶小環，階梯上升

項目管理其實就是一個大環，處理項目中每個問題都可以算一個小環，項目從無到有就是在不斷遵循PDCA循環，不斷在優化過程、提高質量水平和效率，為實現項目目標而努力。

更多乾貨請關注微信公眾號：bigsec豈安科技

這問題是一個非常大的問題，可以說其實是所有項目管理都會遇到這個問題。截止到目前為止，也沒有一套方案能真的解決問題。因為每一個項目的客戶，需求，領導，團隊都不一樣。

所謂優秀的項目經理或者項目的產品經理就是掌握一些基本原則，然後隨需而變，再加上點兒運氣，才能真的成功。

我今天想說的原則之一是：控制變更。

我在開始學習項目管理的時候，被教育的控制變更的方式是：

方法1，跟客戶簽訂合同，約定範圍，約束變更。

這是一個好方法。當有一個前提是你的客戶和你的老闆都能充分認識到變更的不利影響。

但是，我們必須明白另外一個事實，我們的環境在不斷變化中，我們自己也在不斷變化中，控制變更如果等於控制不變更（約束變更1），這就意味著我們無法適應當前的社會。

方法2，隨時響應客戶變更，客戶要什麼我們給什麼。

這是我一直夢想的團隊。就我個人來說，目前還沒有遇到這樣的團隊。並且，團隊越大，或者說你要做的事情越大，這種難度就會越高。

方法3，數字化變更。變更是必須的，隨時變化團隊又更不上，折中的策略就是產品經理（或者項目經理）做中間的緩衝帶，對外隨時響應變更，做變更分析，變更計劃；對內，必須保證迭代內團隊的任務或者說目標穩定。

這個需要產品經理有很強的分析能力、計劃及控制能力。就我身邊的人來看，很少有產品經理具備這樣的能力。怎麼辦？產品經理不能也不該對外說不，但是，往往把壓力轉移到團隊身上。而我個人建議的方式是產品經理必須當好緩衝帶，如果個人能力或者精力不夠，可以找到助手協助自己（如項目經理，研發經理，助理團隊）。

對於項目經理來說，如果你的產品經理沒有這個意識或者能力，你就必須站出來，做好緩衝帶，但前提必須是：接受所有客戶的變更，而不是對產品經理說不。

預告原則2：客戶溝通

產品經理不該進行項目管理

重要的事情說三遍。

產品經理不懂技術，所以技術上的排期和開發量應該由技術來決定。產品應當提出需求，盡量砍掉所有能砍的需求，充分溝通需求的優先順序和時間窗口，剩下的就看技術部門自己安排了。

很多產品經理承擔了替老闆壓榨技術的職能，美其名曰項目管理。其實是老闆不好意思自己出面要求技術加班，不想把關係搞僵，就讓產品經理來干這個事，等產品經歷遭人恨了再跑出來打圓場。。。當然從公司運營角度來講，這個也沒什麼好說的，但是產品經理從本身的專業技能角度來講，是不應該承擔項目管理的職責的。

作為一個產品，需求的變更應該是正常的，但是應該遵從如下原則：

1、不能偏離產品的設計初衷

2、深入的分析需求，做充分的調研和足夠的溝通

3、劃定每一次Release界限，確定好里程碑和階段目標

4、時間、進度、質量是最基本的

5、做好每次版本更迭的詳細記錄

如果以上方面都做好了，合理的需求變更就有條不紊了。

產品經理不管項目進度，除非你也是項目經理。如果不是項目經理，千萬別攬這個活干。

項目的開發進度不可能總是能夠像計劃那麼理想，所以，計劃的時候要能夠把風險考慮進去。這樣的話，就不會在遇到風險的時候，缺乏對策。

1.首先要給所有的需求優先順序，必須完成的需求是高優先順序，要投入優勢力量先做。

2.項目經理應該有每個需求狀態列表，要每天更新，至少要包含了每個需求的優先順序，工作量，開發人員，開發進度等等，隨時可以讓項目成員都看到。任何人有疑問，也可以提出來。保持信息同步很重要。

3.要控制需求的數量，保證有足夠的人力完成所有的需求。如果新增了需求，要評估工作量，並體現在需求列表中，如果沒有足夠的人手，要麼拒絕，要麼加人。

4.需要前後台配合，或者多個部門間配合的需求，要把溝通時間算入工作量，實際上，溝通非常耗時耗力。

5.一旦發現必須完成的需求進度延後了，投入更多的力量保證完成，甚至延長項目時間。

6.一旦發現非必須的需求的進度延後了，應當考慮投入更多力量或者將它放到下個迭代再完成。

7.要嚴格要求編碼人員，做好代碼審查，不能讓任何人提交的代碼嚴重影響整個項目代碼的穩定性。保證每個人的代碼提交到主分支以後，都能夠測試整個項目。不穩定的主分支代碼是災難！

scrum的每日站立會議，其實我倒覺得效果不是很好，每天開會的時候，大家常常非常沉默，改成兩天一次或者一周兩次的項目分享會議可能好點。實際上，如果是一個開發時間很長的項目(如半年)，改成周會都可以。

李國慶，phoenix_lzq 說的都很好。

補充一下：

1. 如果是給定時間內完成項目，則需要把各項任務的時間，優先順序安排好。

2. 如果可以稍自由的把握，則先搞定設計案，它是統領團隊工作的綱領。在根據它做出合理估算。

3. 不管怎麼樣，設計案優先順序放最高。它的時長可以事先估算，未完成前可先報告上級整體計劃要在設計案出來之後定奪。一定要講設計案的完成度做的儘可能的高，接近終版，才能精確控制時間。

4. 根據策劃案制定總體計劃，細分階段性計劃。途中遇到的零零碎碎，可以根據情況列入當前階段，或者下一個階段。總體時間仍然可控，多出來的任務要給階段計劃延時；新增的階段計劃則再估時間。當然有變化要記得報告上級。