高效推進B端項目進度方法總結

　　總結是把一定階段內的有關情況分析研究，做出有指導性結論的書面材料，它可以明確下一步的工作方向，少走彎路，少犯錯誤，提高工作效益，讓我們一起來學習寫總結吧。但是卻發現不知道該寫些什么，下面是小編為大家收集的高效推進B端項目進度方法總結，僅供參考，大家一起來看看吧。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　產品設計與業務的契合度，可以分析是否完成了解了業務的含義，在整個過程中是否有偏差，如果有偏差，偏差在哪里，發生偏差的原因是什么，在下次遇到問題如何分析會更好。此時更多是可以提升對業務的理解。

　　從接到需求到完成整個方案中，是否存在卡點（磕磕絆絆不順利），如果有的話分析下是否經常在不同項目中會碰到這個事情，如果是那就是個人的短板，需要針對性強化，如果不是，那這次卡的原因是什么該如何解決。 此時更多是可以完善產品工作流，提升個人的產品技能。

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

　　人人都是產品經理（是以產品經理、運營為核心的學習、交流、分享平臺，集媒體、培訓、社群為一體，全方位服務產品人和運營人，成立11年舉辦在線+期，線+場，產品經理大會、運營大會50+場，覆蓋北上廣深杭成都等20個城市，在行業有較高的影響力和知名度。平臺聚集了眾多BAT美團京東滴滴360小米網易等知名互聯網公司產品總監和運營總監，他們在這里與你一起成長。

【高效推進B端項目進度方法總結】相關文章：

項目進度計劃方案06-26

項目進度管理制度09-18

市衛生項目推進方案范文優選09-26

高效課堂總結10-15

高效課堂總結08-21

施工進度計劃進度保證措施05-19

小學高效課堂總結05-16

推進方案05-11

施工進度計劃08-05

高效課堂經驗總結08-19