產品延期上線該怎么辦？本文作者結合自身經驗，并用一個公式與你探討此問題。enjoy~

本人本職為一只產品汪，由于公司工作需要，一人目前身兼三職產品，運營及項目管理。其實對于雙PM的崗位，大家應該見怪不怪了，如果不清楚，我在這邊來解釋一下：

（1）產品經理（Product Manager）

Product Manager的縮寫，意指產品經理（產品經理人），又稱品牌經理（Brand Manager）。是企業守門員、品牌塑造者、更是營銷骨干。它既是一套完善的營銷運作制度，更是博大精深的營銷操作。產品經理根據用戶需求，策劃并設計對應產品功能，通過用戶需求和反饋分析、數據分析、行業動態等途徑，做出產品功能和運營層面調整的崗位。

（2）項目經理（Project Manager）

項目經理（Project Manager)是負責項目管理的專業人員，項目經理負責一個項目的計劃，執行及結束關閉。目前，項目經理管理角色在多種行業中得到應用，尤其是在建筑、網絡技術、通信、軟件開發等行業發揮積極而重要的作用。

一般來說產品經理把PRD和原型圖交付給技術之后，就由項目經理介入，來管理產品的開發周期，保證按時上線，但是有些公司會由于人員匹配或者其他問題，直接讓產品經理兼任項目經理的角色，不過話說回來，把自己造的娃兒給生出來天經地義，義不容辭，所以承擔項目經理的職責也在情理之中，但是每每遇到產品延期，無法按照計劃準時上線，這對于整個產品線，甚至公司都是災難性的，因為可能就是由于這一次延期失去了用戶的口碑，由于這一次延期失去了市場的最佳窗口期，由于這一次的延期失去了投資人的信任導致資金鏈斷裂。

為了避免以上事故發生，下面我就把我個人這兩年多來的項目管理經驗，簡稱“填坑心得”分享給大家，絕對【獨家自創首發】的公式

項目任務量=開發時間*開發人數*工作效率

所以我們來看這個公式，如果我希望要保證項目不延期，那么我們可以從這4個維度去介入：

1. 增加開發時間
2. 增加項目開發的人數
3. 提高單位人員，單位時間內的工作效率
4. 減少項目任務量

關于前置條件

對于一個靠譜的產品經理來說，一般交付了PRD和原型文檔之后，在項目規定的期限內是不會去變更需求的，如果經常變更，那就說明你本身的產品工作沒有做到位，思考不周全。項目的任務量是由產品決定的，所以在項目開始正式開發之前，一定要開一個比較完成的需求評審會，這個會議盡量喊上以下幾組人員：

1. 運營人員，保證你給產品是符合市場預期的，同時他們也可以提前做好運營計劃
2. 開發人員，保證你想做的產品是在他們現有技術能力范圍之內的，不然到時候想的好實現不了就又得回頭來修改需求（尤其是后端的接口模塊化，前端的交互動態效果）
3. 測試人員，保證你產品上線后的可靠性，在全面理解完了你的產品方案之后，會出一份測試用例表，對功能，性能進行全方位的黑白盒測試

（PS：這邊一般和UI設計師一起把高保真交互效果圖出來之后再進行評審，所以該角色未出現）

這樣做的好處是，能規避很多項目后續開發中的風險，產品評審通過之后，各方也就基本都定下來了，不會有太大改動，產品定，則技術方案定；技術方案定，則開發工作量定，人員類型人數定；前面的這些定完，按照招聘進來的常規崗位效率，則開發時間也定了。

全部定完之后，上線的最終時間也就出來了，但是有時一個產品的上線時間，其實不是由開發時長來決定的，它是由市場時機決定的，所以這時就需要項目經理來從中協調和管理了，在這個公式中，其中最大的一個X因素，就是【工作效率】，大部分產品上線延期，都是由于這個因素導致的。接下來我將根據爆發頻度，對公式里面的這幾個因子進行逐一分析

工作效率

我個人將工作效率中的問題分為兩種，一種是個人本身的工作效率，還有一種是人與人之間的溝通效率。

（1）個人本身的工作效率，由自己的崗位技能，工作年限等所決定的，不是一朝一夕就能立馬進行提升

解決方案：

組織技術研討會，對于每次的技術難點問題，每個開發人員自己進行記錄，每人每次僅限上會1個問題（為了防止“猴子效應”，也即都指望他人給你幫助，而自己不會動腦子去思考）在組內進行討論，大家頭腦風暴提出可行的解決方案，若扔無法解決，由該組的技術leader將問題記錄并上報CTO進行解決，若CTO也無法解決，則會在我們私密的技術方案大牛會上采取懸賞任務的形式，請求外來高手幫忙解決。

（2）人與人之間的溝通效率，這個是可以完成通過團隊間的高效協作來彌補掉的

解決方案：

半開放式項目組，將從前端組，后端組，測試組抽調出來的開發人員，匹配在一起進行集中式開發，由于每個人可能身上有80%的任務是開發本項目，還有20%的任務是去修復bug或者是做其他項目的優化等，所以可以分成兩塊獨立的單位時間，比如早上9點到11點集中改bug，下午1點到晚上9點集中做新的項目，這樣做的好處是提高了每個人80%的時間內的溝通效率，不用再辦公室內到處穿梭，有什么事情可以當面直接喊話，同時發現他人開發有問題時，可以及早提醒，避免推翻重來，對于項目經理也可以一目了然，每天每個人的工作進度，對整體上線做到心中有數。

開發人數

如果遇到項目突然要求提前上線，則可能就會要求增加開發人數，但是這里最大的問題就是，往往一個項目做得快不快不是人數的問題，有些人進組之后也產生不了什么很大的效用，因為工作分的不細致，他無從寫起。；又或者項目組里的成員突然要離職，則項目可能就會延期。

解決方案：

1. 產品技術同步模塊化，產品在設計的時候，就注意模塊和模塊間的關聯度和靈活性，讓其結構化清晰，框架合理，技術leader在定技術方案時，前后端數據調用的方式方法，底層數據庫表結構的設計都要和產品思維一致，這樣便于后續開發人員理解和跟進。
2. 拆分到不能再分，技術leader把每個開發組員的工作人員清單列出來，細到后端多少個接口，前端多少種交互效果等，只有這樣每日工作才可量化，才知道每個技術人員加入之后，還有哪些事情可做。

開發時間

如果當你的效率和人員都已經優化到極值了，項目預計還是無法延期，那么就只能增加開發時間，說通俗一點講，就是要求開發人員加班了。但是加班是把雙刃劍，團隊氛圍好的時候，大家越干越有勁，都期盼這早日上線看到自己的工作成績；團隊氛圍不好的時候，則抱怨貶損，離職率大幅上升。所以如何搞定團隊的氛圍成了我認為的關鍵因素

解放方案：

給出一套公平，公正，公開的人性化長效機制

人性化：

1. 彈性工作制（晚上如果加班很晚，第二天可以晚些來，但是保證項目期內每日12小時工作時間，同時不影響其他開發成員聯調進度）
2. 餐貼福利，提供各種水果蔬菜增強加班人員的營養③包加班路費，可以坐的士回家，公司報銷④項目按時上線的團建活動，以及優秀個人公開表彰

公開：

每日早上會在公司系統上顯示團隊內個成員，每天工作實效，以及昨日完成內容及今天需要完成內容（每日走之前，會復查項目組任務清單）

公平：

1. 對于任務無法日清周結的開發成員，進行記點處罰，若在本周內能跟進補上進度，則取消扣點
2. 對于提前完成開發任務同時還幫助小組其他人員開發的，進行加點獎勵

公正：建立一套類似于游戲中打怪升級一樣的經驗成長體系，每次項目組完畢之后，就為每個人結算本次的項目點數，累計到自身的總體考核值上，到達指定額度即可完成升級，享受對應級別的工資和福利

項目工作量

如果以上三點都試過了，還是無法保證準時上線，那就只能使出雙PM的終極殺招【砍需求】了，由于是產品組里面最了解項目進度的人，項目組里面最了解產品需求的人，所以產品經理這個時候就可以拿出自己的需求池，拿出自己產品功能模塊框架圖，來進行分級處理了。

解決方案：

對功能進行分級，按照以下4種類型，根據開發的性價比和最終上線時間，進行數量和種類上的取舍吧，有些可能就只能放到二期里面對產品進行迭代了。

1. 主流程功能
2. 分支流程功能
3. 異常流程功能
4. 體驗升級功能

此時你還需要安慰自己和運營的同胞【沒有哪個產品是一上線就是完美，我們都是小步快跑，快速迭代的】（此處呵呵呵呵~~~~）

最后筆者只想大聲喊一句，“什么時候能給我做出一個不延期、無bug、高性能、優體驗的產品??！”

作者：囧囧有神，某上市公司產品經理，Team Leader，7年互聯網經驗。

本文由 @囧囧有神 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自 Pexels，基于 CC0 協議