起點課堂會員權(quán)益
職業(yè)體系課特權(quán)
線下行業(yè)大會特權(quán)
個人IP打造特權(quán)
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導(dǎo)直播
12場專業(yè)技能直播
會員專屬社群
榮耀標識復(fù)盤：B端產(chǎn)品經(jīng)理快速提升法
盤就是一個系統(tǒng)化思考的過程，當我們的知識體系結(jié)構(gòu)化了、系統(tǒng)化了，我們才能舉一反三，融匯貫通，提升自己的綜合能力。
一、為什么要做復(fù)盤？
產(chǎn)品經(jīng)理沒有專業(yè)，也沒有科班之說，學(xué)計算機的，法律的，設(shè)計的……只要想做，都可以成為產(chǎn)品經(jīng)理。正因為人人都是產(chǎn)品經(jīng)理，我在剛開始做產(chǎn)品經(jīng)理的時候，心里很沒底。還特地請教了幾位大佬：怎樣才能提高產(chǎn)品能力呢？要看哪些書呢？
結(jié)果，答案很一致：經(jīng)驗積累。
我以為不停的做功能，做上個三五年，自然就成熟了。然而，埋頭苦干了2年，發(fā)現(xiàn)自己還一直在門外徘徊。
不止是我，很多人都不愿意去復(fù)盤。覺得功能上線就是終點，其實，這只是個開始。每一次復(fù)盤時對自己的批判和肯定，逐漸構(gòu)建了自己的知識體系。知道哪邊可能會有坑，知道如何最小成本試錯，知道怎么找到用戶需求和開發(fā)成本之間的平衡點，知道怎么推動項目，知道怎么和其他團隊協(xié)作…..
毫不夸張的說，復(fù)盤比不停的做功能更加有效，對我來說，絕大部分的能力提升，都來源于復(fù)盤。
二、什么時候需要做復(fù)盤？
時時刻刻。
是的，你沒有看錯，當發(fā)現(xiàn)問題時，就可以去復(fù)盤，總結(jié)經(jīng)驗，需要行動的就快速落實。
但這種復(fù)盤是不全面、不系統(tǒng)的。我們可以先把日常零散的點記著，再在這些重要的節(jié)點上做全面的復(fù)盤：
- 新功能上線半個月后，每1個月后，直到非常穩(wěn)定。
- 年中，以及年終對整個系統(tǒng)的全面復(fù)盤。
三、如何做好全面復(fù)盤？
復(fù)盤要從用戶的使用情況入手，通過真實的數(shù)據(jù)和回訪來分析。功能設(shè)計肯定是我們重點關(guān)注的，但內(nèi)部的項目協(xié)作方面也不能忽視。下面就來說說具體復(fù)盤的內(nèi)容。
1. 用戶使用情況分析
這步收集和分析主要是為了下面的功能分析。
1）實際使用者數(shù)量是否達到預(yù)期？
我們在做功能的時候，會先進行用戶調(diào)研，這部分用戶就是我們的潛在使用者。功能剛上線時，他們可能是最先開始使用的。在針對新功能剛上線復(fù)盤時，我們會先看這些用戶是否已經(jīng)使用起來，使用情況如何。如果這部分用戶都不能用起來，那功能設(shè)計可能存在很大的問題，整個方案都可能是錯誤的。
在后面使用的一段時間內(nèi)，持續(xù)的關(guān)注用戶數(shù)量。如果沒有增長，那很可能這個功能是一些特殊用戶的偽需求。如果穩(wěn)定的在增長，說明這是一個合理，且有價值的功能。
2）用戶對功能的整體評價如何？
有時候新功能上線了，不怕用戶提一堆優(yōu)化，就怕沒人提。一點反饋都沒有，要么就是沒人用，要么就是沒問題。但后者可能性還是很小的。
我們會先統(tǒng)計出用戶對功能的使用量，選擇數(shù)據(jù)量大的一些用戶進行回訪。題目設(shè)置如下：
- 實際場景中是否能用起來這個功能？
- 有哪些細節(jié)場景不滿足使用？
- 對這個功能打幾分？
回訪樣本足夠多時，我們對功能的理解和迭代規(guī)劃就會有更深層次的思考。
2、產(chǎn)品功能驗證
很多時候，B端產(chǎn)品經(jīng)理并不是用戶，沒有B端業(yè)務(wù)的親身經(jīng)歷，做功能的時候常常感到很虛，就怕需求調(diào)研不充分，被部分用戶帶偏；也怕功能設(shè)計不合理，做出來以后沒人用。
通過上面的用戶使用情況調(diào)研分析，我們可以有理有據(jù)地來分析下功能層面的問題了。
1）整體方案是否合理？
這其實考驗的是需求調(diào)研和功能設(shè)計能力。在調(diào)研階段，有沒有挖掘到用戶的真實需求？在功能設(shè)計時，有沒有基于用戶的使用場景？
這時要反推這幾點：
- 調(diào)研的是否是目標用戶？
- 調(diào)研的是否是功能實際使用者？
- 調(diào)研對象是否具有代表性？
- 調(diào)研樣本量是否充足？
- 是否獲得了用戶的真實需求？
- 是否是基于用戶的實際場景給出的解決方案？
- 是否走通了功能的閉環(huán)？
- 是否全面考慮了對系統(tǒng)其他模塊的影響？
如果這是一個成功的功能，那么那些調(diào)研過的用戶，可以歸到我們的vip庫里，下次有類似功能需求時，可以先聽聽他們的意見。
如果很不幸，這是一個失敗的功能，那么我們需要分析下，到底是上面的哪幾點導(dǎo)致了失敗。是因為調(diào)研的用戶數(shù)太少？還是用戶根本就不典型？那下次在選取調(diào)研對象時需要謹慎。
或者是因為設(shè)計能力差，沒有弄清用戶真實所需，那下次做完產(chǎn)品設(shè)計后，一定要內(nèi)部多討論，集大家的智慧。在產(chǎn)品原型出完后，多調(diào)研一些用戶，請他們看方案是否合理。
前置環(huán)節(jié)做的越足，開發(fā)時就越順利。功能做錯了，后面再在那上面修改，或者推倒重來，成本是非常高的。特別是產(chǎn)生了一些數(shù)據(jù)后，不得不考慮老數(shù)據(jù)的兼容問題。
目前來說，基本上不會遇到整體方案不正確的情況。關(guān)于如何做需求調(diào)研，之前在”人人都是產(chǎn)品經(jīng)理“上講過直播課，大家可以去看看。
具體功能整體設(shè)計，可以看看之前寫的這2篇：《全面解析：就診預(yù)約應(yīng)如何設(shè)計？》《叫號系統(tǒng)設(shè)計指南》
2）有哪些細節(jié)沒有考慮到？
細節(jié)多少都是會有點問題的，但不是所有問題下次都可以規(guī)避的。這里要分2部分來看。
特殊的正常場景沒考慮到
這就屬于那種難以規(guī)避的類型。他屬于正常的業(yè)務(wù)場景，但是屬于正常場景中的異常流程。除非很了解B端業(yè)務(wù)，否則調(diào)研的時候，這類問題很難調(diào)研到。
比如說輸液臺。正常流程就是醫(yī)生開輸液單->藥房發(fā)藥–>護士輸液。此時的特殊場景就是：醫(yī)生開了3天的藥，輸了1天，第二天換藥了，如何提醒護士不要輸錯了？
還有一種更想不到的：因為護士扎針沒扎好，患者生氣，早上不輸了，藥品都被扔了，然后下午又來輸液了，如何告訴護士，3天的輸液量，2天輸完了，還沒有結(jié)束輸液，不是系統(tǒng)的bug？
要想減少這種場景的考慮步驟，最好的辦法找?guī)讉€用戶看原型，先體驗功能。在功能上線后，短期內(nèi)及時跟進。如果對這項業(yè)務(wù)不熟悉，心理沒底，一定要多問用戶。
產(chǎn)品設(shè)計細節(jié)考慮不周
這部分的能力是可以提升的，甚至做到基本不出現(xiàn)設(shè)計層面的缺陷。一方面是當前功能的設(shè)計細節(jié)。另一個最大、隱藏最深的問題就是對現(xiàn)有功能的影響考慮不周。
往往體現(xiàn)在這幾方面：
- 當前功能細節(jié)不明。比如說統(tǒng)計報表中，最長的時間篩選跨度是多長？文本字段中，字數(shù)限制是多少？
- 和原有功能有沖突。比如說在做叫號功能的時候，需要增加預(yù)約后就給號的模式，但這和原來的預(yù)約模式產(chǎn)生了沖突，無法協(xié)調(diào)，只能二選一。
- 原有功能同步不到位。比如說增加了患者在手機端填寫體重、血壓等指標數(shù)據(jù)的功能，但是這些數(shù)據(jù)沒有記錄到系統(tǒng)的病人指標庫里面，導(dǎo)致數(shù)據(jù)缺失。
遇到這類問題的時候，隨時記下來，多復(fù)盤，下次在做功能的時候，就會很敏感，哪些地方可能有坑。對其他功能影響考慮不周，還有個笨辦法就是，一頁頁去看原型，看看是否有哪一點被忽略了。
3）功能迭代計劃是否合理？
我們都懂MVP這個道理，但是做的時候，可能就把握不好度了，一不小心就做多了。產(chǎn)品經(jīng)理很多都有完美心理，以為做的越多，功能越豐富，用戶使用就越滿足。恰恰相反，做的越多，錯的越多。在確認功能價值前，要懂得規(guī)劃。
如果功能上線后，能被正常使用，且沒有多余的，這是最理想的狀態(tài)。比如叫號雖然復(fù)雜，有登記給號模式，預(yù)約給號模式，但都能被用戶用到，且模式的占比差不多是1：1，就不適合做模式的分割迭代了。
如果功能上線后，有多余用不到的，或者急缺的。那首次的規(guī)劃就不合理。比如說優(yōu)惠券功能，實際上用戶每次都只使用一張，但做到了多張疊加使用的程度，就造成了浪費。
需求優(yōu)先級怎么劃分，可以看下我之前寫的這篇《B端產(chǎn)品的需求優(yōu)先級選擇》。
3、開發(fā)過程回顧
團隊項目的協(xié)作，難度一點都不低于產(chǎn)品設(shè)計，甚至是產(chǎn)品經(jīng)理更加頭痛的事情。明明我設(shè)計的很好，是開發(fā)沒有做到位；我文檔很早就給了，但開發(fā)沒有按期交付。為什么都要我背鍋？
產(chǎn)品經(jīng)理不只是用戶和產(chǎn)品的黏合劑，也是各部門的黏合劑。開發(fā)過程的回顧，不僅要看開發(fā)功能實現(xiàn)上的問題，還要看項目管理上的問題。
1）功能實現(xiàn)不了怎么辦？
開發(fā)說的最多的一句：這個做不了。
是不想做還是做不了？
剛開始的時候，開發(fā)說做不了，我們就以為真的沒辦法做。時間長了就會發(fā)現(xiàn)，做不了的功能很少很少。我們?yōu)榱斯δ苣茼樌暇€，就要對癥下藥。
如果是不想做，那就整理讓他做的對策：
- 時間緊來不及。——這期不上線，慢慢做，下期或者下下期上線。
- 覺得麻煩不想做?！宜I(lǐng)導(dǎo)，要么做，要么換人做。
如果是做不了，也有做得了的對策：
- 能力有限不會做?！o他找能解決的人指導(dǎo)。
- 底層設(shè)計如此，確實做不了?！姨娲桨浮?/li>
2）項目中的介入節(jié)點是否合理？
項目周期截點有這幾個：需求調(diào)研–>初評–>詳評–>設(shè)計稿–>靜態(tài)頁面完成–>聯(lián)調(diào)完成–>測試驗收–>產(chǎn)品驗收–>上線。
正常需要產(chǎn)品經(jīng)理介入的環(huán)節(jié)是這幾個：需求調(diào)研，初評，詳評，設(shè)計稿，產(chǎn)品驗收。
如果是小功能，產(chǎn)品最后驗收一下就行，也不會有很大的問題。但如果功能比較大、比較復(fù)雜，我們需要注意介入的時間截點。盡量把工作都提前，以防上線時發(fā)現(xiàn)錯誤很多，來不及改。
我們在做大功能時，就會增加靜態(tài)頁面和聯(lián)調(diào)后的驗收。先把控頁面字段對不對，功能有沒有漏，等后面產(chǎn)品驗收時就主要看流程通不通就行了。
產(chǎn)品經(jīng)理最終要對產(chǎn)品負責，如何分散風(fēng)險，保質(zhì)量是需要在實踐中不斷調(diào)整的。
3）各部門的合作方式是否需要改進？
涉及到合作，最大的問題就是信息不同步，以此產(chǎn)生互相推鍋。
功能沒做，開發(fā)說是因為產(chǎn)品經(jīng)理需求有變更，我不知道。產(chǎn)品經(jīng)理說，我都當面和你說了，你怎么不認賬了呢……類似的扯皮可能每天都會發(fā)生。
我們必須把合作流程定下來，按照規(guī)定來執(zhí)行。如果執(zhí)行中又發(fā)現(xiàn)了其他問題，也要納入流程中，直到各方達成一致，不會有大問題出現(xiàn)。
比如說我們會要求設(shè)計出完一部分設(shè)計稿后，先同步給我們審查。需求變更的通知要在群里發(fā)送，@對應(yīng)的人，并私聊發(fā)送變動內(nèi)容，還會兩至三天發(fā)送變更郵件，確保大家都知道。
只要涉及到合作的部分，都建議規(guī)范化流程。這樣即使碰到人事變更，都一樣能有序進行。
總結(jié)
我們每天都在學(xué)習(xí)，在接收信息，也在積累經(jīng)驗。但為什么有的人能快速成長，有的人老是栽在同一個坑里？因為知識太零散，不能學(xué)以致用。
而復(fù)盤就是一個系統(tǒng)化思考的過程。當我們的知識體系結(jié)構(gòu)化了、系統(tǒng)化了，我們才能舉一反三，融匯貫通，提升自己的綜合能力。
再怎么忙，都要定時去復(fù)盤，特別是新功能上線后的一段時間內(nèi)。不僅要分析產(chǎn)品設(shè)計是否合理，還要反思開發(fā)過程中的協(xié)作問題。因為產(chǎn)品經(jīng)理不只是寫文檔、畫原型就可以了，溝通協(xié)作也是必備技能。
建議收藏此文，下次做復(fù)盤時參考下。
作者：司馬特小隊，丁香園高級產(chǎn)品經(jīng)理。微信公眾號：司馬特小分隊
本文由 @司馬特小隊 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載。
題圖來自Unsplash，基于CC0協(xié)議
講的很不錯哦，謝謝
溫故而知新 ?
受教了