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

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

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

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

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

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

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

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

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

二、具體項目實踐中的復(fù)盤思考

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

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

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

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

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

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

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

Action行動：

為此，第二期的開發(fā)我提出采取混合型的項目管理方案。采購層面仍然采用預(yù)測型，將可能涉及到的需求范圍盡量描述完整。而開發(fā)層面采取敏捷項目管理的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 進行開發(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)理回答進行需求分析，結(jié)果直接被淘汰。面試官給出的答案是要先看誰提出的，如果是老板提出的直接開始做。

看似是個段子，但是也確實反映了當(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行動：

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

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

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

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

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

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

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

Action行動：

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

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

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

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

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

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

Action行動：

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

1. 記錄：誰在什么時間點提出的、為什么要變更，讓變更發(fā)起方發(fā)起變更郵件，產(chǎn)品經(jīng)理記錄在需求收集表中，做好留痕。
2. 評估：結(jié)合上文提到的需求分析方法，評估需求變更帶來的影響，確定做還是不做。如果做，結(jié)合優(yōu)先級的高低，放到接下來哪個Sprint沖刺中。
3. 提交：在項目管理流程中，變更需要提交給到CCB（變更控制委員會）或是PMO(項目管理辦公室)進行批準，由于我們公司當(dāng)時這兩個職能都沒有，直接給到老板和采購確認審核即可。
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)生負面情緒，都是一件非常麻煩的事情。

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

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

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

Action行動：

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

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

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

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

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

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

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

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

Action行動：

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

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

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

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

三、結(jié)語

項目管理能力、需求分析能力、溝通能力、技術(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é)議

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