多年前，我作為一名B端產品新人，牽頭負責公司SCRM平臺的定制化開發。在項目過程中不斷復盤，讓我的產品能力有了很大提升，在這里我總結了一些之前的復盤思考給各位B端產品新人，希望能給你帶來一些工作上的啟示。

一、為什么要做復盤？

1. 復盤是績效提升的關鍵一環

我認為復盤是 PDCA 戴明環里最重要的一環，對計劃P和執行D進行檢查C，輸出處理行動A，讓我們的工作形成持續優化的循環，提升工作的績效。

如果我們只是不停的做計劃，執行計劃，缺少了對工作的復盤，就很容易陷入一種低效的忙碌，無法提煉出優秀實踐經驗來指導未來的行動。

2. 復盤是個人成長的關聯路徑

復盤是個人或團隊對事件或項目，進行回顧、反思、重構的結構化的學習過程。

在復盤的過程中，我們從實踐中反思經驗，分析成功和失敗的關鍵，總結出規律進而形成個人經驗，提煉出高度抽象的方法論，進而提升我們解決問題的能力。

在《遠見》一書中，開篇就提到“可遷移技能”是三大職場燃料之一，而解決問題的能力是能讓你與他人拉開差距的可遷移技能。

二、具體項目實踐中的復盤思考

1. 項目應選取什么樣的生命周期類型？

多年前，我所在的公司是一家傳統制造業企業，計劃引入一款SCRM Saas產品進行私有化部署，并基于乙方公司標品的底層能力，進行深度的定制化開發，接入公司現有系統，以便于更好的滿足業務團隊個性化的需求。

由于當時公司還處于數字化轉型的初級階段，公司的IT采購流程要求必須需要給采購部門提供詳細并且明確的采購需求說明書，遵循嚴格的預算控制。

這給我們的新產品開發帶來了很大的難度，因為這個時候項目才剛成立，大家都不知道具體應該怎么做，業務方給到我們的需求也是非常籠統的，好在公司財大氣粗預算充足。我只好硬著頭皮，將寬泛空洞的需求說明書盡量描述清楚，在采購巨大的挑戰下完成了采購流程。

第一期產品耗時整整3個月才完成開發上線，功能上線后，業務方的運營重心已經開始轉變，已上線的功能價值遠不如提需求時的高。其次業務方還提出了大量的優化需求，當前功能已不符合當下的業務場景。

后面通過對項目管理的系統性學習，我逐步了解到，在項目管理中將項目的開發生命周期可分為預測型、敏捷型、迭代型、增量型，或者多種類型結合的混合型。

傳統制造業企業更關注計劃，按照采購的要求，明顯是要求我們項目的開發生命周期采取預測型，這確實也符合企業過往的業務流程，但在互聯網產品上就明顯不適用了，因為IT產品的有著非常強的靈活性，需求的變化調整也是非常高頻，在互聯網公司，基本都采取增量型或是敏捷開發的模式。

Action行動：

為此，第二期的開發我提出采取混合型的項目管理方案。采購層面仍然采用預測型，將可能涉及到的需求范圍盡量描述完整。而開發層面采取敏捷項目管理的Scrum 框架，每3周一個Sprint沖刺。

經過這樣的調整：

首先，產品功能價值得到了大幅提升。業務方提出的需求，可以保障3周內完成MVP的上線，業務方可以盡快用起來了。

其次，能更好地應對頻繁的需求變化。在沖刺期間內不做需求變更，業務方提出的新需求，評估可行后統一放到未來的 Sprint 進行開發，由于3周的時間對比過往3個月靈活很多，可以更好地貼合業務側的各種調整。

2. 收到業務需求后應該做什么？

最近看到一個段子，產品經理去面試，面試官問收到業務需求后應該做什么，產品經理回答進行需求分析，結果直接被淘汰。面試官給出的答案是要先看誰提出的，如果是老板提出的直接開始做。

看似是個段子，但是也確實反映了當時我們公司和其他很多公司產品經理的現狀。

當老板發現我們效率提升后，要求我們將一個 Sprint沖刺縮短到2周，并也開始給我們提出新需求。當業務側發現我們的開發效率提升后，也開始給我們提出更多的需求。

隨著一個又一個迭代的上線，功能越來越多，也開始出現一些功能，提出需求的時候非常急，但上線了又沒人使用的情況。這讓我開始反思，在需求分析環節，是不是還沒真正做到位。

Action行動：

我和團隊基于需求文檔，對已上線的功能，進行了系統性的復盤，共同輸出了需求分析的靈魂7問：

1. 您的落地場景是什么？
2. 您要達成的業務目標和要解決的問題是什么？
3. 使用這個功能的主體和對象是誰？
4. 上線之后如何驗證效果？
5. 假設功能上線了，您會怎么推廣這個功能讓用戶使用？
6. 配套的運營人員是誰？
7. 有哪些額外資源支持？

之后無論是誰提出需求，都要先和我共同完成這靈魂七問。能夠清晰回答出這七個問題，最起碼是一個經過認真思考的需求，后續再根據回答進行需求價值分析、定義優先級，讓我們的產品功能更加集中在解決核心業務問題上。后續我們還在此基礎上迭代更加系統的需求收集表，幫助我們更好地進行產品規劃和資源評估。

3. 產品經理要持續提升技術思維

第一期的SCRM平臺開發項目，基于服務商通過PHP語言開發的標品Saas，由服務商提供PHP開發人員進行定制化開發。

而我司內部的開發團隊只有Java的開發人員，并沒有PHP的開發和運維資源，這就意味著未來服務商質保結束后，我們的開發團隊還需要新增額外的PHP開發資源來專門進行這一個系統的運維。其次就是在一期產品上線后，出現常用功能頁面加載速度明顯過慢的情況。

出現這個問題，一是我作為產品經理在評估技術需求時過度依賴開發團隊，沒能更進一步多考慮下技術層面的內容。二是在項目初期，內部開發團隊人員較為混亂，核心成員計劃離職，沒有從技術層面進行更長遠的規劃。

Action行動：

首先，從第二期合作開始，我與內部開發團隊建立共識，要求服務商全部基于Java語言進行開發，并將第一期的內容進行Java重構。這里著實走了一些彎路，但我也問了一些做開發測試的朋友，說這種代碼重構項目他們公司也很常見。

其次，我與開發團隊將之前過于寬泛的技術需求文檔進行了重新梳理，對技術需求進行了更加細致的描述和要求，包括：開發語言、安全性、穩定性、可用性、易用性、可伸縮性、網絡要求、軟硬件要求等等， 詳細到最高能支持多少TPS并發、頁面響應時間的最高的毫秒數都做了更加細致的量化要求。

最后，我還針對易用性，輸出了B端系統設計規范，例如規范異常報錯的交互和提示文案。這里我非常推薦酸梅干超人的電話亭的《B端設計規范搭建全流程講解》，非常適合B端產品新人快速提升產品設計能力。

4. 出現需求的變更應該怎么辦？

我在上面項目生命周期類型選取中講到采取混合型的開發生命周期。

因為我們基于預測的計劃給到采購需求范圍，但基于Scrum敏捷框架積極擁抱需求變化，，在未來幾個Sprint沖刺后必然會出現需求變更，導致采購環節的需求范圍和實際開發的內容不一致，這在采購和審計環節是一件可大可小事，總歸來說不是一件好事。

Action行動：

老老實實的收到研讀公司的采購制度，嚴格做好需求變更管理。

1. 記錄：誰在什么時間點提出的、為什么要變更，讓變更發起方發起變更郵件，產品經理記錄在需求收集表中，做好留痕。
2. 評估：結合上文提到的需求分析方法，評估需求變更帶來的影響，確定做還是不做。如果做，結合優先級的高低，放到接下來哪個Sprint沖刺中。
3. 提交：在項目管理流程中，變更需要提交給到CCB（變更控制委員會）或是PMO(項目管理辦公室)進行批準，由于我們公司當時這兩個職能都沒有，直接給到老板和采購確認審核即可。
4. 更新：在需求收集表中更新這條變更需求的結果和狀態
5. 通知：涉及該需求的相關方都要做好知會，包括需求方、開發、采購、服務商等等。

5. 如何保持各個相關方之間的良好溝通？

在技術開發合作中，甲方與乙方間不僅僅是下需求然后開發交付這么簡單。無論是內部業務方、內部開發、采購、法務甚至是客服，如果有任何一方對服務商產生負面情緒，都是一件非常麻煩的事情。

我們項目在進行的過程中，業務方對服務商的問題處理速度出現不滿，最后的結果演變成對服務商極度缺乏信心，提出要更換服務商。

經過幾個月漫長的服務商招標、甄選等環節，成功更換了新的服務商。不久之后，IT團隊又開始對新服務商的開發質量出現不滿，又提出要更換服務商，來來回回，服務商的頻繁變動，給項目帶來很多負面的影響，比如說：

1. 服務商感受到不受信任和打壓，在合作末期會顯著降低交付質量和服務質量；
2. 項目成員的變動需要重新進行業務知識培訓，尤其是公司的業務規則特別復雜時，溝通成本會變得非常高。

Action行動：

這其中涉及的原因可能有很多，在這里我只分享一個最基本有效的行動，建立起良好的溝通：

首先，確保最基本的溝通順暢。建立好項目溝通群，邀請各相關方加入，如果日常溝通信息較多，在項目溝通群的基礎上，再進一步建立細分的小群。例如需求溝通群、故障缺陷群等等，確保溝通的高效。

其次，建立服務商的匯報機制。我讓供應商的項目經理，每周通過郵件的方式進行一次項目進度報告，發送給所有相關方，確保項目進度信息的同步，加強了對服務商的監督。

最后，促進多方高層之間的溝通。高層級的溝通對推動項目穩健發展尤為重要，至少每個季度召開一次階段性的項目成果匯報會議，如果有特別關鍵的里程碑可以額外增加。項目成果匯報會議邀請服務商的高層和我司各相關部門的高層領導參加，共同檢閱，提升領導們對項目的認可度。

6. 跨系統數據對接，不熟悉公司整體系統框架怎么辦？

項目剛開始的時候，公司的各個產品/系統東一個西一個，整體軟件產品系統架構特別混亂。

如果業務方的某個需求涉及跨系統數據對接，在需求分析階段的溝通成本巨高。

先是要分別向公司老同事打聽各系統負責人，再分別找對應的系統負責人溝通。有時各部門對同一個系統名稱的口徑還不統一，雞同鴨講眼碌碌。

Action行動：

我們開發的SCRM平臺里有一個核心的功能叫做“顧客檔案”，用于給銷售人員記錄并展示自己跟進的客戶信息。

首先，針對內部溝通的問題，我也建立了自己在公司內部溝通的同事檔案。包括同事姓名、所屬部門、負責哪個產品/系統、這樣下次需要對接時就可以查閱檔案快速找到對應的負責人。并基于這份檔案，逐步建立起自己對于公司整體系統框架的理解和認識。

其次，要積極向上管理，不斷和公司管理層反饋這個問題，拿著同事檔案給管理層提建議。后面領導逐步意識到了這個問題，牽頭成立了架構委員會，梳理出整體的系統架構字典，包括前中后臺的各個產品模塊、統一系統口徑名稱和負責人。

架構委員會也同步制定了詳細的管理規范，包括新產品上線前需要進行架構評審、接口評審、安全評審等等。每個環節的評審都會延長上線時間，在需求分析階段需要提前做好更全面的評估。

三、結語

項目管理能力、需求分析能力、溝通能力、技術思維和向上管理都是產品經理需要不斷打磨的基本功。

長期來看，通過對過往工作的復盤思考，關注有效的行動，提煉出自己工作的原則和方法是提升自我的關鍵。

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

題圖來自Unsplash，基于CC0協議

該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。