關于B端產(chǎn)品開發(fā)項目的「復盤思考」（b端產(chǎn)品開發(fā)流程）
多年前，我作為一名B端產(chǎn)品新人，牽頭負責公司SCRM平臺的定制化開發(fā)。在項目過程中不斷復盤，讓我的產(chǎn)品能力有了很大提升，在這里我總結了一些之前的復盤思考給各位B端產(chǎn)品新人，希望能給你帶來一些工作上的啟示。
一、為什么要做復盤？
1. 復盤是績效提升的關鍵一環(huán)
我認為復盤是 PDCA 戴明環(huán)里最重要的一環(huán)，對計劃P和執(zhí)行D進行檢查C，輸出處理行動A，讓我們的工作形成持續(xù)優(yōu)化的循環(huán)，提升工作的績效。
如果我們只是不停的做計劃，執(zhí)行計劃，缺少了對工作的復盤，就很容易陷入一種低效的忙碌，無法提煉出優(yōu)秀實踐經(jīng)驗來指導未來的行動。
2. 復盤是個人成長的關聯(lián)路徑
復盤是個人或團隊對事件或項目，進行回顧、反思、重構的結構化的學習過程。
在復盤的過程中，我們從實踐中反思經(jīng)驗，分析成功和失敗的關鍵，總結出規(guī)律進而形成個人經(jīng)驗，提煉出高度抽象的方法論，進而提升我們解決問題的能力。
在《遠見》一書中，開篇就提到“可遷移技能”是三大職場燃料之一，而解決問題的能力是能讓你與他人拉開差距的可遷移技能。
二、具體項目實踐中的復盤思考
1. 項目應選取什么樣的生命周期類型？
多年前，我所在的公司是一家傳統(tǒng)制造業(yè)企業(yè)，計劃引入一款SCRM Saas產(chǎn)品進行私有化部署，并基于乙方公司標品的底層能力，進行深度的定制化開發(fā)，接入公司現(xiàn)有系統(tǒng)，以便于更好的滿足業(yè)務團隊個性化的需求。
由于當時公司還處于數(shù)字化轉型的初級階段，公司的IT采購流程要求必須需要給采購部門提供詳細并且明確的采購需求說明書，遵循嚴格的預算控制。
這給我們的新產(chǎn)品開發(fā)帶來了很大的難度，因為這個時候項目才剛成立，大家都不知道具體應該怎么做，業(yè)務方給到我們的需求也是非?；\統(tǒng)的，好在公司財大氣粗預算充足。我只好硬著頭皮，將寬泛空洞的需求說明書盡量描述清楚，在采購巨大的挑戰(zhàn)下完成了采購流程。
第一期產(chǎn)品耗時整整3個月才完成開發(fā)上線，功能上線后，業(yè)務方的運營重心已經(jīng)開始轉變，已上線的功能價值遠不如提需求時的高。其次業(yè)務方還提出了大量的優(yōu)化需求，當前功能已不符合當下的業(yè)務場景。
后面通過對項目管理的系統(tǒng)性學習，我逐步了解到，在項目管理中將項目的開發(fā)生命周期可分為預測型、敏捷型、迭代型、增量型，或者多種類型結合的混合型。
傳統(tǒng)制造業(yè)企業(yè)更關注計劃，按照采購的要求，明顯是要求我們項目的開發(fā)生命周期采取預測型，這確實也符合企業(yè)過往的業(yè)務流程，但在互聯(lián)網(wǎng)產(chǎn)品上就明顯不適用了，因為IT產(chǎn)品的有著非常強的靈活性，需求的變化調整也是非常高頻，在互聯(lián)網(wǎng)公司，基本都采取增量型或是敏捷開發(fā)的模式。
Action行動：
為此，第二期的開發(fā)我提出采取混合型的項目管理方案。采購層面仍然采用預測型，將可能涉及到的需求范圍盡量描述完整。而開發(fā)層面采取敏捷項目管理的Scrum 框架，每3周一個Sprint沖刺。
經(jīng)過這樣的調整：
首先，產(chǎn)品功能價值得到了大幅提升。業(yè)務方提出的需求，可以保障3周內(nèi)完成MVP的上線，業(yè)務方可以盡快用起來了。
其次，能更好地應對頻繁的需求變化。在沖刺期間內(nèi)不做需求變更，業(yè)務方提出的新需求，評估可行后統(tǒng)一放到未來的 Sprint 進行開發(fā)，由于3周的時間對比過往3個月靈活很多，可以更好地貼合業(yè)務側的各種調整。
2. 收到業(yè)務需求后應該做什么？
最近看到一個段子，產(chǎn)品經(jīng)理去面試，面試官問收到業(yè)務需求后應該做什么，產(chǎn)品經(jīng)理回答進行需求分析，結果直接被淘汰。面試官給出的答案是要先看誰提出的，如果是老板提出的直接開始做。
看似是個段子，但是也確實反映了當時我們公司和其他很多公司產(chǎn)品經(jīng)理的現(xiàn)狀。
當老板發(fā)現(xiàn)我們效率提升后，要求我們將一個 Sprint沖刺縮短到2周，并也開始給我們提出新需求。當業(yè)務側發(fā)現(xiàn)我們的開發(fā)效率提升后，也開始給我們提出更多的需求。
隨著一個又一個迭代的上線，功能越來越多，也開始出現(xiàn)一些功能，提出需求的時候非常急，但上線了又沒人使用的情況。這讓我開始反思，在需求分析環(huán)節(jié)，是不是還沒真正做到位。
Action行動：
我和團隊基于需求文檔，對已上線的功能，進行了系統(tǒng)性的復盤，共同輸出了需求分析的靈魂7問：
- 您的落地場景是什么？
- 您要達成的業(yè)務目標和要解決的問題是什么？
- 使用這個功能的主體和對象是誰？
- 上線之后如何驗證效果？
- 假設功能上線了，您會怎么推廣這個功能讓用戶使用？
- 配套的運營人員是誰？
- 有哪些額外資源支持？
之后無論是誰提出需求，都要先和我共同完成這靈魂七問。能夠清晰回答出這七個問題，最起碼是一個經(jīng)過認真思考的需求，后續(xù)再根據(jù)回答進行需求價值分析、定義優(yōu)先級，讓我們的產(chǎn)品功能更加集中在解決核心業(yè)務問題上。后續(xù)我們還在此基礎上迭代更加系統(tǒng)的需求收集表，幫助我們更好地進行產(chǎn)品規(guī)劃和資源評估。
3. 產(chǎn)品經(jīng)理要持續(xù)提升技術思維
第一期的SCRM平臺開發(fā)項目，基于服務商通過PHP語言開發(fā)的標品Saas，由服務商提供PHP開發(fā)人員進行定制化開發(fā)。
而我司內(nèi)部的開發(fā)團隊只有Java的開發(fā)人員，并沒有PHP的開發(fā)和運維資源，這就意味著未來服務商質保結束后，我們的開發(fā)團隊還需要新增額外的PHP開發(fā)資源來專門進行這一個系統(tǒng)的運維。其次就是在一期產(chǎn)品上線后，出現(xiàn)常用功能頁面加載速度明顯過慢的情況。
出現(xiàn)這個問題，一是我作為產(chǎn)品經(jīng)理在評估技術需求時過度依賴開發(fā)團隊，沒能更進一步多考慮下技術層面的內(nèi)容。二是在項目初期，內(nèi)部開發(fā)團隊人員較為混亂，核心成員計劃離職，沒有從技術層面進行更長遠的規(guī)劃。
Action行動：
首先，從第二期合作開始，我與內(nèi)部開發(fā)團隊建立共識，要求服務商全部基于Java語言進行開發(fā)，并將第一期的內(nèi)容進行Java重構。這里著實走了一些彎路，但我也問了一些做開發(fā)測試的朋友，說這種代碼重構項目他們公司也很常見。
其次，我與開發(fā)團隊將之前過于寬泛的技術需求文檔進行了重新梳理，對技術需求進行了更加細致的描述和要求，包括：開發(fā)語言、安全性、穩(wěn)定性、可用性、易用性、可伸縮性、網(wǎng)絡要求、軟硬件要求等等， 詳細到最高能支持多少TPS并發(fā)、頁面響應時間的最高的毫秒數(shù)都做了更加細致的量化要求。
最后，我還針對易用性，輸出了B端系統(tǒng)設計規(guī)范，例如規(guī)范異常報錯的交互和提示文案。這里我非常推薦酸梅干超人的電話亭的《B端設計規(guī)范搭建全流程講解》，非常適合B端產(chǎn)品新人快速提升產(chǎn)品設計能力。
4. 出現(xiàn)需求的變更應該怎么辦？
我在上面項目生命周期類型選取中講到采取混合型的開發(fā)生命周期。
因為我們基于預測的計劃給到采購需求范圍，但基于Scrum敏捷框架積極擁抱需求變化，，在未來幾個Sprint沖刺后必然會出現(xiàn)需求變更，導致采購環(huán)節(jié)的需求范圍和實際開發(fā)的內(nèi)容不一致，這在采購和審計環(huán)節(jié)是一件可大可小事，總歸來說不是一件好事。
Action行動：
老老實實的收到研讀公司的采購制度，嚴格做好需求變更管理。
- 記錄：誰在什么時間點提出的、為什么要變更，讓變更發(fā)起方發(fā)起變更郵件，產(chǎn)品經(jīng)理記錄在需求收集表中，做好留痕。
- 評估：結合上文提到的需求分析方法，評估需求變更帶來的影響，確定做還是不做。如果做，結合優(yōu)先級的高低，放到接下來哪個Sprint沖刺中。
- 提交：在項目管理流程中，變更需要提交給到CCB（變更控制委員會）或是PMO(項目管理辦公室)進行批準，由于我們公司當時這兩個職能都沒有，直接給到老板和采購確認審核即可。
- 更新：在需求收集表中更新這條變更需求的結果和狀態(tài)
- 通知：涉及該需求的相關方都要做好知會，包括需求方、開發(fā)、采購、服務商等等。
5. 如何保持各個相關方之間的良好溝通？
在技術開發(fā)合作中，甲方與乙方間不僅僅是下需求然后開發(fā)交付這么簡單。無論是內(nèi)部業(yè)務方、內(nèi)部開發(fā)、采購、法務甚至是客服，如果有任何一方對服務商產(chǎn)生負面情緒，都是一件非常麻煩的事情。
我們項目在進行的過程中，業(yè)務方對服務商的問題處理速度出現(xiàn)不滿，最后的結果演變成對服務商極度缺乏信心，提出要更換服務商。
經(jīng)過幾個月漫長的服務商招標、甄選等環(huán)節(jié)，成功更換了新的服務商。不久之后，IT團隊又開始對新服務商的開發(fā)質量出現(xiàn)不滿，又提出要更換服務商，來來回回，服務商的頻繁變動，給項目帶來很多負面的影響，比如說：
- 服務商感受到不受信任和打壓，在合作末期會顯著降低交付質量和服務質量；
- 項目成員的變動需要重新進行業(yè)務知識培訓，尤其是公司的業(yè)務規(guī)則特別復雜時，溝通成本會變得非常高。
Action行動：
這其中涉及的原因可能有很多，在這里我只分享一個最基本有效的行動，建立起良好的溝通：
首先，確保最基本的溝通順暢。建立好項目溝通群，邀請各相關方加入，如果日常溝通信息較多，在項目溝通群的基礎上，再進一步建立細分的小群。例如需求溝通群、故障缺陷群等等，確保溝通的高效。
其次，建立服務商的匯報機制。我讓供應商的項目經(jīng)理，每周通過郵件的方式進行一次項目進度報告，發(fā)送給所有相關方，確保項目進度信息的同步，加強了對服務商的監(jiān)督。
最后，促進多方高層之間的溝通。高層級的溝通對推動項目穩(wěn)健發(fā)展尤為重要，至少每個季度召開一次階段性的項目成果匯報會議，如果有特別關鍵的里程碑可以額外增加。項目成果匯報會議邀請服務商的高層和我司各相關部門的高層領導參加，共同檢閱，提升領導們對項目的認可度。
6. 跨系統(tǒng)數(shù)據(jù)對接，不熟悉公司整體系統(tǒng)框架怎么辦？
項目剛開始的時候，公司的各個產(chǎn)品/系統(tǒng)東一個西一個，整體軟件產(chǎn)品系統(tǒng)架構特別混亂。
如果業(yè)務方的某個需求涉及跨系統(tǒng)數(shù)據(jù)對接，在需求分析階段的溝通成本巨高。
先是要分別向公司老同事打聽各系統(tǒng)負責人，再分別找對應的系統(tǒng)負責人溝通。有時各部門對同一個系統(tǒng)名稱的口徑還不統(tǒng)一，雞同鴨講眼碌碌。
Action行動：
我們開發(fā)的SCRM平臺里有一個核心的功能叫做“顧客檔案”，用于給銷售人員記錄并展示自己跟進的客戶信息。
首先，針對內(nèi)部溝通的問題，我也建立了自己在公司內(nèi)部溝通的同事檔案。包括同事姓名、所屬部門、負責哪個產(chǎn)品/系統(tǒng)、這樣下次需要對接時就可以查閱檔案快速找到對應的負責人。并基于這份檔案，逐步建立起自己對于公司整體系統(tǒng)框架的理解和認識。
其次，要積極向上管理，不斷和公司管理層反饋這個問題，拿著同事檔案給管理層提建議。后面領導逐步意識到了這個問題，牽頭成立了架構委員會，梳理出整體的系統(tǒng)架構字典，包括前中后臺的各個產(chǎn)品模塊、統(tǒng)一系統(tǒng)口徑名稱和負責人。
架構委員會也同步制定了詳細的管理規(guī)范，包括新產(chǎn)品上線前需要進行架構評審、接口評審、安全評審等等。每個環(huán)節(jié)的評審都會延長上線時間，在需求分析階段需要提前做好更全面的評估。
三、結語
項目管理能力、需求分析能力、溝通能力、技術思維和向上管理都是產(chǎn)品經(jīng)理需要不斷打磨的基本功。
長期來看，通過對過往工作的復盤思考，關注有效的行動，提煉出自己工作的原則和方法是提升自我的關鍵。
本文由 @Jack 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉載。
題圖來自Unsplash，基于CC0協(xié)議
該文觀點僅代表作者本人，人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務。
