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

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

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

1）何時立項

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

2）立項意義

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

既然如此，那麼傳統的項目啟動會是否必要？筆者建議，針對大型或重要的研發項，還是需要啟動會的。首先一件事情的成功，是需要大家的認可的，召開啟動會，可以體現事情的重要性與價值，凝聚人心；同時可以将大家對事項的認知拉齊，便于後續工作推進。

3）立項的判斷價值

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

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

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

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

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

每一個研發項，均有其目的與想要達到的效果，為了能在規定時間内完成該目的，故一般需要确定其内容（即範圍邊界）。

1）需求範圍

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

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

2）預期進度

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

3）幹系人

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

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

4）項目成本

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

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

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

在項目完成所有需求内容後，将進入研發階段，該階段有2個特點：

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

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

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

1）進度把控

常規的研發管理中，對進度管控是有專業技能的，如研發協助工具，站會例會等，但對于産品來講，沒必要對研發進度管控深入過多。

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

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

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

2）風險管理

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

3）變更控制

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

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

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

4）模拟測試

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

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

在研發完成後，産品終究是要交付給業務需求方，故在研發完成後，将進行項目交付。

1）上線準備

在内部研發完成後，此時所交付物（所研發的産品）将從内部研發團隊交付到外部業務團隊手中，故需要對2方面進行準備。

對業務團隊，進行操作培訓，确保業務部門能夠了解如何使用該産品，在上手後能立馬使用。

對研發團隊，上線時有些内容是需要提前準備的，如數據預處理、外部賬号申請等，這些在研發團隊評估後，也需要進行準備。

2）發版上線

在萬事具備後，将開始進行上線，上線的話主要是研發團隊的工作，研發團隊需要按照之前産品提供的方案以及上線計劃将代碼發布到生産環境。

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

當系統上線需要外部支持配合時，那麼也需要産品經理或項目經理提前協調配合，确保上線時外部的順暢。

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

3）上線跟進

上線後，在業務開始使用後，也需要跟進業務的使用情況，可以查看業務的使用數據，并于業務回訪獲得反饋，必要時可進行優化叠代。系統必然是在改進叠代中走向成熟。

在項目上線後，業務使用良好本項目獲得業務認可，也意味着本項目即将結束，因此需要考慮本項目的得失，沉澱經驗教訓，為給整個公司的後續發展帶來價值。

1）項目總結

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

做此項是為了後續能更好提高研發側的效率，加強彼此間的協作。是團隊的提升。此項一般可由項目經理或研發經理主持。

2）産品總結

在但産品之外，還需要對産品進行回顧，即分析産品設計與業務的契合度，回顧在完成需求時的曆程。此項是為了作為産品人，更好提升自身能力的。可以從以下幾個角度來進行複盤：

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

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

作者：王耑，職場産品人

本文由 @王耑 原創發布于人人都是産品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!