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

一、為什么要做復(fù)盤？

1. 復(fù)盤是績效提升的關(guān)鍵一環(huán)

我認(rèn)為復(fù)盤是 PDCA 戴明環(huán)里最重要的一環(huán)，對計劃P和執(zhí)行D進(jìn)行檢查C，輸出處理行動A，讓我們的工作形成持續(xù)優(yōu)化的循環(huán)，提升工作的績效。

如果我們只是不停的做計劃，執(zhí)行計劃，缺少了對工作的復(fù)盤，就很容易陷入一種低效的忙碌，無法提煉出優(yōu)秀實(shí)踐經(jīng)驗(yàn)來指導(dǎo)未來的行動。

2. 復(fù)盤是個人成長的關(guān)聯(lián)路徑

復(fù)盤是個人或團(tuán)隊(duì)對事件或項(xiàng)目，進(jìn)行回顧、反思、重構(gòu)的結(jié)構(gòu)化的學(xué)習(xí)過程。

在復(fù)盤的過程中，我們從實(shí)踐中反思經(jīng)驗(yàn)，分析成功和失敗的關(guān)鍵，總結(jié)出規(guī)律進(jìn)而形成個人經(jīng)驗(yàn)，提煉出高度抽象的方法論，進(jìn)而提升我們解決問題的能力。

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

二、具體項(xiàng)目實(shí)踐中的復(fù)盤思考

1. 項(xiàng)目應(yīng)選取什么樣的生命周期類型？

多年前，我所在的公司是一家傳統(tǒng)制造業(yè)企業(yè)，計劃引入一款SCRM Saas產(chǎn)品進(jìn)行私有化部署，并基于乙方公司標(biāo)品的底層能力，進(jìn)行深度的定制化開發(fā)，接入公司現(xiàn)有系統(tǒng)，以便于更好的滿足業(yè)務(wù)團(tuán)隊(duì)個性化的需求。

由于當(dāng)時公司還處于數(shù)字化轉(zhuǎn)型的初級階段，公司的IT采購流程要求必須需要給采購部門提供詳細(xì)并且明確的采購需求說明書，遵循嚴(yán)格的預(yù)算控制。

這給我們的新產(chǎn)品開發(fā)帶來了很大的難度，因?yàn)檫@個時候項(xiàng)目才剛成立，大家都不知道具體應(yīng)該怎么做，業(yè)務(wù)方給到我們的需求也是非?；\統(tǒng)的，好在公司財大氣粗預(yù)算充足。我只好硬著頭皮，將寬泛空洞的需求說明書盡量描述清楚，在采購巨大的挑戰(zhàn)下完成了采購流程。

第一期產(chǎn)品耗時整整3個月才完成開發(fā)上線，功能上線后，業(yè)務(wù)方的運(yùn)營重心已經(jīng)開始轉(zhuǎn)變，已上線的功能價值遠(yuǎn)不如提需求時的高。其次業(yè)務(wù)方還提出了大量的優(yōu)化需求，當(dāng)前功能已不符合當(dāng)下的業(yè)務(wù)場景。

后面通過對項(xiàng)目管理的系統(tǒng)性學(xué)習(xí)，我逐步了解到，在項(xiàng)目管理中將項(xiàng)目的開發(fā)生命周期可分為預(yù)測型、敏捷型、迭代型、增量型，或者多種類型結(jié)合的混合型。

傳統(tǒng)制造業(yè)企業(yè)更關(guān)注計劃，按照采購的要求，明顯是要求我們項(xiàng)目的開發(fā)生命周期采取預(yù)測型，這確實(shí)也符合企業(yè)過往的業(yè)務(wù)流程，但在互聯(lián)網(wǎng)產(chǎn)品上就明顯不適用了，因?yàn)镮T產(chǎn)品的有著非常強(qiáng)的靈活性，需求的變化調(diào)整也是非常高頻，在互聯(lián)網(wǎng)公司，基本都采取增量型或是敏捷開發(fā)的模式。

Action行動：

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

經(jīng)過這樣的調(diào)整：

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

其次，能更好地應(yīng)對頻繁的需求變化。在沖刺期間內(nèi)不做需求變更，業(yè)務(wù)方提出的新需求，評估可行后統(tǒng)一放到未來的 Sprint 進(jìn)行開發(fā)，由于3周的時間對比過往3個月靈活很多，可以更好地貼合業(yè)務(wù)側(cè)的各種調(diào)整。

2. 收到業(yè)務(wù)需求后應(yīng)該做什么？

最近看到一個段子，產(chǎn)品經(jīng)理去面試，面試官問收到業(yè)務(wù)需求后應(yīng)該做什么，產(chǎn)品經(jīng)理回答進(jìn)行需求分析，結(jié)果直接被淘汰。面試官給出的答案是要先看誰提出的，如果是老板提出的直接開始做。

看似是個段子，但是也確實(shí)反映了當(dāng)時我們公司和其他很多公司產(chǎn)品經(jīng)理的現(xiàn)狀。

當(dāng)老板發(fā)現(xiàn)我們效率提升后，要求我們將一個 Sprint沖刺縮短到2周，并也開始給我們提出新需求。當(dāng)業(yè)務(wù)側(cè)發(fā)現(xiàn)我們的開發(fā)效率提升后，也開始給我們提出更多的需求。

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

Action行動：

我和團(tuán)隊(duì)基于需求文檔，對已上線的功能，進(jìn)行了系統(tǒng)性的復(fù)盤，共同輸出了需求分析的靈魂7問：

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

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

3. 產(chǎn)品經(jīng)理要持續(xù)提升技術(shù)思維

第一期的SCRM平臺開發(fā)項(xiàng)目，基于服務(wù)商通過PHP語言開發(fā)的標(biāo)品Saas，由服務(wù)商提供PHP開發(fā)人員進(jìn)行定制化開發(fā)。

而我司內(nèi)部的開發(fā)團(tuán)隊(duì)只有Java的開發(fā)人員，并沒有PHP的開發(fā)和運(yùn)維資源，這就意味著未來服務(wù)商質(zhì)保結(jié)束后，我們的開發(fā)團(tuán)隊(duì)還需要新增額外的PHP開發(fā)資源來專門進(jìn)行這一個系統(tǒng)的運(yùn)維。其次就是在一期產(chǎn)品上線后，出現(xiàn)常用功能頁面加載速度明顯過慢的情況。

出現(xiàn)這個問題，一是我作為產(chǎn)品經(jīng)理在評估技術(shù)需求時過度依賴開發(fā)團(tuán)隊(duì)，沒能更進(jìn)一步多考慮下技術(shù)層面的內(nèi)容。二是在項(xiàng)目初期，內(nèi)部開發(fā)團(tuán)隊(duì)人員較為混亂，核心成員計劃離職，沒有從技術(shù)層面進(jìn)行更長遠(yuǎn)的規(guī)劃。

Action行動：

首先，從第二期合作開始，我與內(nèi)部開發(fā)團(tuán)隊(duì)建立共識，要求服務(wù)商全部基于Java語言進(jìn)行開發(fā)，并將第一期的內(nèi)容進(jìn)行Java重構(gòu)。這里著實(shí)走了一些彎路，但我也問了一些做開發(fā)測試的朋友，說這種代碼重構(gòu)項(xiàng)目他們公司也很常見。

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

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

4. 出現(xiàn)需求的變更應(yīng)該怎么辦？

我在上面項(xiàng)目生命周期類型選取中講到采取混合型的開發(fā)生命周期。

因?yàn)槲覀兓陬A(yù)測的計劃給到采購需求范圍，但基于Scrum敏捷框架積極擁抱需求變化，，在未來幾個Sprint沖刺后必然會出現(xiàn)需求變更，導(dǎo)致采購環(huán)節(jié)的需求范圍和實(shí)際開發(fā)的內(nèi)容不一致，這在采購和審計環(huán)節(jié)是一件可大可小事，總歸來說不是一件好事。

Action行動：

老老實(shí)實(shí)的收到研讀公司的采購制度，嚴(yán)格做好需求變更管理。

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

5. 如何保持各個相關(guān)方之間的良好溝通？

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

我們項(xiàng)目在進(jìn)行的過程中，業(yè)務(wù)方對服務(wù)商的問題處理速度出現(xiàn)不滿，最后的結(jié)果演變成對服務(wù)商極度缺乏信心，提出要更換服務(wù)商。

經(jīng)過幾個月漫長的服務(wù)商招標(biāo)、甄選等環(huán)節(jié)，成功更換了新的服務(wù)商。不久之后，IT團(tuán)隊(duì)又開始對新服務(wù)商的開發(fā)質(zhì)量出現(xiàn)不滿，又提出要更換服務(wù)商，來來回回，服務(wù)商的頻繁變動，給項(xiàng)目帶來很多負(fù)面的影響，比如說：

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

Action行動：

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

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

其次，建立服務(wù)商的匯報機(jī)制。我讓供應(yīng)商的項(xiàng)目經(jīng)理，每周通過郵件的方式進(jìn)行一次項(xiàng)目進(jìn)度報告，發(fā)送給所有相關(guān)方，確保項(xiàng)目進(jìn)度信息的同步，加強(qiáng)了對服務(wù)商的監(jiān)督。

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

6. 跨系統(tǒng)數(shù)據(jù)對接，不熟悉公司整體系統(tǒng)框架怎么辦？

項(xiàng)目剛開始的時候，公司的各個產(chǎn)品/系統(tǒng)東一個西一個，整體軟件產(chǎn)品系統(tǒng)架構(gòu)特別混亂。

如果業(yè)務(wù)方的某個需求涉及跨系統(tǒng)數(shù)據(jù)對接，在需求分析階段的溝通成本巨高。

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

Action行動：

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

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

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

架構(gòu)委員會也同步制定了詳細(xì)的管理規(guī)范，包括新產(chǎn)品上線前需要進(jìn)行架構(gòu)評審、接口評審、安全評審等等。每個環(huán)節(jié)的評審都會延長上線時間，在需求分析階段需要提前做好更全面的評估。

三、結(jié)語

項(xiàng)目管理能力、需求分析能力、溝通能力、技術(shù)思維和向上管理都是產(chǎn)品經(jīng)理需要不斷打磨的基本功。

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

本文由 @Jack 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

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

該文觀點(diǎn)僅代表作者本人，人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務(wù)。