編輯導語：一個研發(fā)項目包含了接到需求，到開始分析做方案，再推進到研發(fā)并上線的整個過程。本文作者從項目的角度出發(fā)，分析如何高效推進項目進度，希望能給你帶來幫助。

當我們開始接到一個需求，開始分析做方案，后面推進到研發(fā)并上線，那么這個過程可以當作一個研發(fā)項目。很多人在初入職場時，可能對整個推進方法不甚清楚，因此，本篇筆者從項目的角度出發(fā)，以一個項目的角色來看待分析，產品如何推進項目進度。請跟隨筆者的腳步往下看吧。

注：本文寫作思路借鑒了部分PMP的相關內容。

一、項目立項

1）何時立項

對于互聯(lián)網(wǎng)內需求而言，因一般采用敏捷方式，故每個功能點一般均不大，故一般弱化立項流程。那么我們可以認為，當團隊內決定做這個需求時，即該需求作為一個研發(fā)項目已經立項。

2）立項意義

對于傳統(tǒng)瀑布式流程而言，立項意味著內部工作的正式開始，開始投入人力、物力、財力去完成這件事情。但對于互聯(lián)網(wǎng)而言，喜歡小步快跑、快速試錯，因此其更多是一種方案提報的認可，同時同步告知相關人員，該項目啟動了。

既然如此，那么傳統(tǒng)的項目啟動會是否必要？筆者建議，針對大型或重要的研發(fā)項，還是需要啟動會的。首先一件事情的成功，是需要大家的認可的，召開啟動會，可以體現(xiàn)事情的重要性與價值，凝聚人心；同時可以將大家對事項的認知拉齊，便于后續(xù)工作推進。

3）立項的判斷價值

首先，與大家分享兩個成本，沉沒成本與機會成本。

因此在判斷是否值得立項的時候，可以從投入產出比，以及與戰(zhàn)略方向契合度的角度來進行考慮。

投入產出比指：當研發(fā)用時差不多的情況下，如何獲得收益更大的價值，一般使用北極星指標作為收益判斷準則或其余關鍵指標。

機會成本指：研發(fā)只能在一個時間段內干相對固定的工作，我干了一個就得舍棄另一個，但很多時候需求是各有各的道理，很多可能體現(xiàn)的價值維度方向不同，那么該如何抉擇呢，一般選用與公司戰(zhàn)略想符合的，這樣多部門形成合力從而取得最大化。

ps：如果決策層對投入產出比或公司戰(zhàn)略選擇經常錯誤，那么可能就需要考慮這艘船還能走多選的問題了。

二、項目啟動

每一個研發(fā)項，均有其目的與想要達到的效果，為了能在規(guī)定時間內完成該目的，故一般需要確定其內容（即范圍邊界）。

1）需求范圍

在開始項目前，一定要明確需求的目的，圍繞目的進行需求內容的確認。

詳情可以借鑒《高價值完成B端需求設計總結》的內容，在此不多做闡述。

2）預期進度

此處不是指研發(fā)側完成該需求的進度，指的是業(yè)務側推進與此研發(fā)側相關配套業(yè)務的時間點。為了保證業(yè)務的效果，那么一般需要與業(yè)務側的時間點打配合，從而調配內部的資源。

3）干系人

在推進研發(fā)側時間前，需要梳理清楚本需求涉及到的相關方。對于B端而言，如上線后是哪個部門負責推進，哪個部門進行執(zhí)行，甚至還會有對于此需求關心的負責人是誰，如果涉及到資金的還會有出資方是誰（預算在哪個部門）等等。

對于B端而言，內部體系比較復雜，決策人與使用人以及相關方均需要注意，在分析出干系人后，對推進整個事項均有好處。

4）項目成本

在除了研發(fā)成本外，還有一塊需要注意，每一個功能上線后，都要有配套的運營成本，甚至配套的成本不一定低。

對于B端而言，內部培訓推廣，新功能加入業(yè)務流程后的新調整新考核是需要宣導下去的，這塊內容雖然與產品人本身關聯(lián)不大，但對于整個研發(fā)項上線后的落地推廣，有一定的幫助。如果涉及到外部第三方的對接，那么梳理清楚關系人之間的關系后，梳理多方間的對接合作關系，對整個項目推進也是有幫助的（不同的商務關系，對于B端而言，往往會影響到對不同事情的處理態(tài)度）。

注：本模塊除了需求范圍外，其他可以理解為項目經理的職責范圍，但了解此模塊可以對整個研發(fā)項開好局，開頭不走偏有很大幫助。對于B端而言，需求一般比較復雜，研發(fā)工作量往往比較龐大，因此從開始定好方向很重要，可以極大降低后期變更帶來的影響。

三、項目進度

在項目完成所有需求內容后，將進入研發(fā)階段，該階段有2個特點：

1. 所需時間可評估，可對過程時間進行精準評估，過程可精細化管控
2. 此階段耗時占整個研發(fā)階段的占比較大，故此階段（從開發(fā)、聯(lián)調到測試）為進度的重點管控階段

注：對于產品人來講，整個研發(fā)過程應不是關注點，只需要知道需要什么時候能完成上線即可，但為了最終產出物的可控，需對進度有一定了解，故對該過程也需要一定了解。

下面筆者對認為重要的點進行闡述：

1）進度把控

常規(guī)的研發(fā)管理中，對進度管控是有專業(yè)技能的，如研發(fā)協(xié)助工具，站會例會等，但對于產品來講，沒必要對研發(fā)進度管控深入過多。

筆者建議，可以通過把握關鍵點的方式，對當前進度進行了解：

• 通過按照預估時間點，在研發(fā)50%，研發(fā)完成進入測試等時間點介入了解下
• 通過研發(fā)側的周報等方式進行了解
• 通過關鍵人物，如該項目的研發(fā)側牽頭人進行了解
• 通過研發(fā)群里，研發(fā)側的溝通內容進行了解，如測試開始測試等來了解（比較耗精力，不建議）

該模塊建議，可以通過產品與研發(fā)部門間的協(xié)調機制來解決該問題，如周報周會或者其他方式。

2）風險管理

在研發(fā)推進中，因為預期之外的各種，存在各種風險，作為產品人，最應該關心的就是外部風險，主要為業(yè)務側風險。業(yè)務側風險主要體現(xiàn)在業(yè)務變動帶來的需求變動，以及需要業(yè)務部門配合的點，是否能結合研發(fā)側節(jié)奏同步進行。

3）變更控制

在研發(fā)推進中，碰到需求調整是經常碰到的事情，但對于研發(fā)管理來講，需求的調整帶來了不確定性，因此是拒絕變更的。但我們作為產品人，是需要對所產出的最終產品的效果負責的，應當追求最大價值。

當碰到業(yè)務對需求提出優(yōu)化建議時，需進行分析，判斷該優(yōu)化點的價值，并且分析下對研發(fā)工作的影響，如果需求改動不大，并且價值度高，則應該推進本次改掉，如果改動較大，則贏進行評估是調整研發(fā)計劃還是放入下一版本。

按筆者個人建議，在進行調整時，當改動重要或較大時，需注意及時與領導匯報溝通（對產品效果的要求以及對研發(fā)成本的控制，是領導比較關心的事情）。

4）模擬測試

該處指的測試并非測試的專業(yè)測試，指的是在測試人員完成測試后，產品對所完成功能的業(yè)務檢視，同時UI也需要，主要是看與所設計的是否有偏差，是否能滿足業(yè)務訴求并帶來價值。

該事建議在完成測試第一輪跑通，基本流程跑通時進行，因為此時檢視基本可以全部走完，檢視發(fā)現(xiàn)的問題還能夠得到解決，若再晚進行檢視，發(fā)現(xiàn)問題會偏晚，導致發(fā)現(xiàn)的問題會讓技術重新調整后再提測，影響總體時間。

四、項目交付

在研發(fā)完成后，產品終究是要交付給業(yè)務需求方，故在研發(fā)完成后，將進行項目交付。

1）上線準備

在內部研發(fā)完成后，此時所交付物（所研發(fā)的產品）將從內部研發(fā)團隊交付到外部業(yè)務團隊手中，故需要對2方面進行準備。

對業(yè)務團隊，進行操作培訓，確保業(yè)務部門能夠了解如何使用該產品，在上手后能立馬使用。

對研發(fā)團隊，上線時有些內容是需要提前準備的，如數(shù)據(jù)預處理、外部賬號申請等，這些在研發(fā)團隊評估后，也需要進行準備。

2）發(fā)版上線

在萬事具備后，將開始進行上線，上線的話主要是研發(fā)團隊的工作，研發(fā)團隊需要按照之前產品提供的方案以及上線計劃將代碼發(fā)布到生產環(huán)境。

此時產品價值度比較低，但產品往往還是需要參與的，因為在發(fā)版時可能遇到不可預知問題，方便現(xiàn)場溝通現(xiàn)場解決。同時有些系統(tǒng)的話，可能還需要產品進行權限配置，或者其他一些配置內容。

當系統(tǒng)上線需要外部支持配合時，那么也需要產品經理或項目經理提前協(xié)調配合，確保上線時外部的順暢。

其中有個注意點，關于app應用市場審核，iOS與安卓不同，需經AppStore審核后才能安裝，故可以采用提前提交審核的方式來確保與安卓可一同發(fā)版。但若能做到兼容，便可靈活操作。

3）上線跟進

上線后，在業(yè)務開始使用后，也需要跟進業(yè)務的使用情況，可以查看業(yè)務的使用數(shù)據(jù)，并于業(yè)務回訪獲得反饋，必要時可進行優(yōu)化迭代。系統(tǒng)必然是在改進迭代中走向成熟。

五、項目總結

在項目上線后，業(yè)務使用良好本項目獲得業(yè)務認可，也意味著本項目即將結束，因此需要考慮本項目的得失，沉淀經驗教訓，為給整個公司的后續(xù)發(fā)展帶來價值。

1）項目總結

在完成后，應當組織對項目進行復盤，回顧整個流程，對項目中好的點進行總結，對出現(xiàn)的一些問題進行回顧，并總結教訓與改進方法。對于新的方法，可以納入原有的流程中，對于新發(fā)現(xiàn)的注意項，可以放入checklist，為后續(xù)自查避免問題做依據(jù)。

做此項是為了后續(xù)能更好提高研發(fā)側的效率，加強彼此間的協(xié)作。是團隊的提升。此項一般可由項目經理或研發(fā)經理主持。

2）產品總結

在但產品之外，還需要對產品進行回顧，即分析產品設計與業(yè)務的契合度，回顧在完成需求時的歷程。此項是為了作為產品人，更好提升自身能力的?？梢詮囊韵聨讉€角度來進行復盤：

• 產品設計與業(yè)務的契合度，可以分析是否完成了解了業(yè)務的含義，在整個過程中是否有偏差，如果有偏差，偏差在哪里，發(fā)生偏差的原因是什么，在下次遇到問題如何分析會更好。此時更多是可以提升對業(yè)務的理解。
• 從接到需求到完成整個方案中，是否存在卡點（磕磕絆絆不順利），如果有的話分析下是否經常在不同項目中會碰到這個事情，如果是那就是個人的短板，需要針對性強化，如果不是，那這次卡的原因是什么該如何解決。 此時更多是可以完善產品工作流，提升個人的產品技能。

以上是筆者對單個項目推進中，對階段的劃分以及如何推進的方法，各位在實際推進中會有自己的總結方法，希望能與各位多多探討，也希望本文能對屏幕前的你有幫助！

作者：王耑，微信公眾號：職場產品人

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

題圖來自Unsplash，基于CC0協(xié)議