本文作者依據(jù)工作中項目實踐的所思所想，結(jié)合案例等分享了B端管理后臺相關(guān)的知識，供大家一同參考和學(xué)習(xí)。

本人前App端測試，現(xiàn)產(chǎn)品新人一枚，有幸作為產(chǎn)品負(fù)責(zé)一個公司內(nèi)部的新平臺。經(jīng)過兩個多月時間，目前一期已上線穩(wěn)定運行，二期三期也陸續(xù)進(jìn)入開發(fā)階段。

鑒于后臺產(chǎn)品資料有限，盡管業(yè)務(wù)不同，做個復(fù)盤，即是個人的總結(jié)，也是小小的分享。經(jīng)驗尚淺，還請各位看官拍磚，不慎歡喜~

目錄

1. 產(chǎn)品簡介
2. 產(chǎn)品全周期
3. 階段分解
4. 總結(jié)

為避免公司敏感信息泄露，以下平臺名稱、功能名稱均為化名。

一、產(chǎn)品簡介

• 產(chǎn)品定位：合規(guī)相關(guān)、企業(yè)管理類的公司內(nèi)部后臺產(chǎn)品，代號為數(shù)據(jù)管理系統(tǒng)。
• 目標(biāo)用戶：主要用戶為公司GA（Government Affairs-政府事務(wù)），次要為GA的技術(shù)支持團(tuán)隊（也就是我們）；
• 痛點：因數(shù)據(jù)為線下化管理，操作門檻高，會造成以下占用研發(fā)核心資源，數(shù)據(jù)保存不當(dāng)，部門壁壘的等；
• 收益：通過線上、可視化平臺降低操作門檻，減少核心資源的投入和依賴，提升GA工作效率。

GA的核心是為企業(yè)保駕護(hù)航，主要職能是政府對接、政策研究、政策影響、危機(jī)應(yīng)對、政企合作。詳細(xì)內(nèi)容，請參考：https://zhuanlan.zhihu.com/p/32576810

二、產(chǎn)品全周期

圖2-1 產(chǎn)品全周期流程圖

以上是產(chǎn)品經(jīng)理的基本工作流程，從初期需求收集到中期的開發(fā)，再到上線后的效果評估，都可以看到產(chǎn)品汪的身影。產(chǎn)品經(jīng)理需要有一顆強(qiáng)大而堅定的心。

基于節(jié)點時間、主要內(nèi)容、相關(guān)方，將上述流程劃分為五個階段，分別是啟動-需求挖掘分析，規(guī)劃-評審，執(zhí)行&監(jiān)控-開發(fā)測試驗收，收尾-發(fā)布，收尾-最終效果評估。

三、階段分解

1. 啟動-需求挖掘分析

圖3-1 需求挖掘分析腦圖

需求挖掘分析對應(yīng)流程圖中的從開始至需求池部分，進(jìn)一步可拆解為需求分析、需求采集、需求管理。

（1）需求分析

需求分析需要特別關(guān)注用戶是誰，識別用戶角色（3個層級-決策層、管理層、執(zhí)行層），用戶特點（群體特征），用戶規(guī)模。

• 用戶角色：與C端不同，B端的決策者、購買者、使用者通常不會是同一波人，并且價值優(yōu)先級為決策層>管理層>執(zhí)行層，故在權(quán)衡決策產(chǎn)品時，不僅需要從多層級來進(jìn)行綜合平衡，同時關(guān)注對決策層和管理層的價值。決策層，可能是業(yè)務(wù)方的boss們，也可能是頂頭上司。
• 用戶特點：B端產(chǎn)品，特別是公司內(nèi)部、強(qiáng)業(yè)務(wù)相關(guān)時，群體特征會十分明顯。之前負(fù)責(zé)的KFZJ平臺，由于KF本身業(yè)務(wù)處于不斷變化中，普遍較年輕，用戶對平臺的包容性很強(qiáng)。本次產(chǎn)品的核心用戶是GA經(jīng)理們，他們長期和ZF打交道，特別關(guān)注平臺的穩(wěn)定，數(shù)據(jù)安全與權(quán)限控制。
• 其他：從場景、目標(biāo)、任務(wù)來分析，B端與C端類似，需要考量場景是否存在與頻次如何，直接目標(biāo)與間接目標(biāo)，需要做什么、有哪些方案以及最佳方案是什么。

（2）需求采集

從B端來出發(fā)，Top1類的需求是為了適應(yīng)業(yè)務(wù)發(fā)展的合規(guī)、提效、安全類的業(yè)務(wù)需求（也包含老板需求）。

當(dāng)平臺擴(kuò)展到一定規(guī)模時，會涉及到技術(shù)需求中的重構(gòu)、擴(kuò)展、安全。除了需求本身，也需要結(jié)合用戶特點，有利于提升產(chǎn)品的效果與收益；

B端帶有強(qiáng)烈的行業(yè)特征，產(chǎn)品經(jīng)理需要不斷地加強(qiáng)業(yè)務(wù)學(xué)習(xí)，提升自身判斷。多體驗，感知用戶、抱怨；多分析，感受形勢，分析結(jié)果；在觀察、學(xué)習(xí)中逐漸實踐，沉淀。

（3）需求管理

需求識別：在《人人都是產(chǎn)品經(jīng)理2.0》一書中，作者蘇杰強(qiáng)調(diào)，用心聽，但不要照著做。

在需求識別時尤其要注意這一點，通過全面的需求分析等方式杜絕不存在不合理的偽需求，造成無用的功能上線，導(dǎo)致資源的浪費。

對于用戶“異想天開”的需求、想法，更多的去挖掘背后的問題，而不是簡單粗暴地給烏鴉更多的石子。

圖3-2 烏鴉喝水 #來自網(wǎng)上

需求優(yōu)先級：可以用作優(yōu)先級的方法有很多，在這里推薦用戶等級分析法，金字塔模型法，MoSCoW排序法。

• 用戶等級分析法中，將用戶分為核心用戶，中間用戶，外圍用戶。除了考慮覆蓋用戶量，還要考慮覆蓋用戶類型。核心用戶的需求優(yōu)先級更高。B端的核心用戶，我認(rèn)為是管理層，因為這一層承擔(dān)著承上啟下的重要作用，下對執(zhí)行層負(fù)責(zé)，上與決策層的影響息息相關(guān)。
• 金字塔模型法，源自馬斯洛需求層次理論，從低到高對應(yīng)產(chǎn)品的層級為能用→易用→好用→愛用→傳播。雖然劃分了B端，C端，不過B端亦是由一個活生生的人而組成的，除了有口飯吃，也可吃得好，吃得爽。B端，特別是公司內(nèi)部產(chǎn)品，不缺用戶，做到能用是否就可以了？私認(rèn)為終極目標(biāo)依然是NPS達(dá)到8分及以上。

圖3-3 馬斯洛需求層次理論 #來自網(wǎng)上

• MoSCoW排序法，是英國項目管理PRINCE2中提倡的一種方法，其名稱是4個級別的首字母縮寫。這4個級別分別是：必須有–Must have；應(yīng)該有–Shoud have；可以有–Could have；可以做的/可以有的；現(xiàn)在沒有–Would not have for now。所有規(guī)定為必須有和應(yīng)該有的，是產(chǎn)品驗收時要達(dá)到的。

MoSCoW排序法的詳細(xì)介紹，請參照https://zhuanlan.zhihu.com/p/63863515

2. 規(guī)劃-評審

圖3-4 規(guī)劃-評審腦圖

圖1-1中的3個評審統(tǒng)一收在了規(guī)劃評審階段，包括立項評審，需求評審，技術(shù)評審。

（1）立項評審

立項，結(jié)合PMP中定義，可初步理解為公司授權(quán)啟動，確認(rèn)目標(biāo)收益和資源投入。

在公司立項評審會結(jié)果通曬中，立項申請包括項目名稱、立項結(jié)果（通過與否）、方向（項目+客戶+收益）、負(fù)責(zé)人、項目背景&痛點、范圍、時間&里程碑、目標(biāo)，ROI分析，關(guān)鍵資源（業(yè)務(wù)、運營、PM、技術(shù)、數(shù)據(jù)、設(shè)計、PMO、上線后移交方）。

• 內(nèi)部系統(tǒng)的收益常見為流程線上化，提升效率，保證準(zhǔn)確性；
• ROI分析為可量化數(shù)據(jù)，例如樣本覆蓋率0.3%提升至30%，節(jié)省人力成本X元；

立項評審，一般大項目&項目管理規(guī)范的部門會接觸到。目前我也只是在KFZJ項目中有收到過立項會邀和立項評審?fù)〞瘛?/p>

做為初級PM，一般不會參與到立項中，但每次發(fā)起需求時，也需要明確產(chǎn)品的價值，如何去衡量收益，是否與項目、公司目標(biāo)有關(guān)聯(lián)，是否一致。換位思考下，如果你是老板，是否會同意啟動這個項目。

（2）需求評審

需求評審包括了產(chǎn)品內(nèi)審、外部評審、UI交互評審；

• 一期的產(chǎn)品中，UI參與了首頁設(shè)計，其他頁面采用了Antdesgin這個UI框架，所以未涉及到UI交互評審，故僅針對首頁的效果、文案與業(yè)務(wù)方進(jìn)行了溝通確認(rèn)；
• 目前公司內(nèi)前端研發(fā)采用的框架也是Antdesgin，原型設(shè)計時也可參照這一框架，既規(guī)范也便于溝通交流，提升效率。

Antdesgin地址：https://ant.design/docs/react/introduce-cn

產(chǎn)品內(nèi)審、外部評審的主要區(qū)別在于是否涉及組外成員，包括業(yè)務(wù)方（需求方）、技術(shù)團(tuán)隊等。

• 在一個規(guī)模化的產(chǎn)品團(tuán)隊中，研發(fā)資源共用，版本時間固定時，產(chǎn)品內(nèi)審如其名，是產(chǎn)品團(tuán)隊內(nèi)部組織的評審，每個PM輪流簡述自己的需求。
• 外部評審則會涉及各相關(guān)方，包括運營、終端、后端、各方QA等。目前所在為技術(shù)團(tuán)隊內(nèi)部，所以產(chǎn)品內(nèi)審是團(tuán)隊內(nèi)部預(yù)審，包括我的老板，各技術(shù)同事，外部評審則會有業(yè)務(wù)方參與。

以目前來講，產(chǎn)品內(nèi)審是由產(chǎn)品經(jīng)理作為會議的組織者。為此需要做好充足的準(zhǔn)備，包括前期的會議室預(yù)定、評審資料分發(fā)，會中的時間、主題把控，會后的總結(jié)。

• 參照事不過三的俗話，內(nèi)審兩次為佳，可以留一些小尾巴，但不適宜還需要開第三遍內(nèi)審，否則會認(rèn)為產(chǎn)品能力太差……
• 評審+開發(fā)時，原型和PRD相比，都是圖（原型）優(yōu)于字（PRD），簡潔明了，研發(fā)們也是常常參照原型進(jìn)行coding；
• 會議紀(jì)要責(zé)無旁貸地是由產(chǎn)品經(jīng)理來負(fù)責(zé)的，包括達(dá)成一致的內(nèi)容和todolist。既方便后續(xù)回溯，也可幫助記憶，誰能保證一定記得前2個月都討論了什么呢。

圖3-5 原型截圖一角

外部評審，因技術(shù)團(tuán)隊可自閉環(huán)，故只涉及到業(yè)務(wù)方。外部評審中的重點是關(guān)鍵相關(guān)方參與，并進(jìn)行充分溝通。

• PMP中常有這么一問，如果相關(guān)方經(jīng)常變更，如何做比較好？答曰盡早請相關(guān)方參與。在產(chǎn)品設(shè)計和實現(xiàn)時也會遇到同樣的情況，平臺上線了，業(yè)務(wù)方反饋我不需要這個，這里XXX，可不可以XX。建議是在需求評審時，務(wù)必請業(yè)務(wù)方參加，當(dāng)他看到原型時，才能準(zhǔn)確地知道他要什么，不要什么。提前反饋，提早修改，提高可用性，降低改動成本。
• 充分溝通包括正式的會議，也包括非正式、一對一的溝通，涉及到產(chǎn)品經(jīng)理與業(yè)務(wù)方、產(chǎn)品經(jīng)理對現(xiàn)有業(yè)務(wù)的了解等等內(nèi)容。溝通是拉齊、統(tǒng)一，達(dá)成共識的載體，即使復(fù)雜，也請各位產(chǎn)品經(jīng)理在前期多花費些精力與時間。

溝通復(fù)雜度，即潛在溝通渠道的總量為 n*(n-1)/2，其中，n 代表團(tuán)隊的人數(shù)

正式的評審會議建議控制在2次，不僅僅是個人能力的問題，更涉及到所有參與的相關(guān)方（包括業(yè)務(wù)方、運營、研發(fā)）的時間成本。

（3）技術(shù)評審

技術(shù)評審是技術(shù)專業(yè)性很強(qiáng)的會議。雖然為前app端測試，有微弱的技術(shù)背景，但真正參與到其中依然有些吃力。但作為產(chǎn)品經(jīng)理，還是需要參與到技術(shù)評審中去的，應(yīng)該了解涉及的技術(shù)都有哪些方面，才能在排期中識別風(fēng)險，了解各依賴活動，確認(rèn)關(guān)鍵路徑。

圖3-6 關(guān)鍵路徑示例圖 #來自PMBOK

對于技術(shù)可行性，通俗來講就是好不好實現(xiàn)，需要多久開發(fā)完成。

雖然有時候可以靠刷臉搞定復(fù)雜需求，但更多的時候還是技術(shù)上存在一定的問題，或者是研發(fā)并未完全認(rèn)同產(chǎn)品設(shè)計，或是產(chǎn)品的價值；曾有開發(fā)反饋過費了好大力氣的需求，半年都未見到上線的效果。

基于排期和技術(shù)可行性會影響產(chǎn)品方案的最終落地，比如可實現(xiàn)但工時長，不可實現(xiàn)時要如何調(diào)整技術(shù)方案。

對于前者，需要產(chǎn)品經(jīng)理去把控優(yōu)先級，哪些必須實現(xiàn)，哪些后續(xù)進(jìn)行優(yōu)化迭代，對于后者建議產(chǎn)品經(jīng)理在制定方案時與研發(fā)進(jìn)行提早進(jìn)行非正式溝通。

3. 執(zhí)行&監(jiān)控-開發(fā)測試驗收

圖3-7 執(zhí)行&監(jiān)控腦圖

執(zhí)行針對的是開發(fā)、測試、驗收這3個方的主體按照預(yù)期進(jìn)行技術(shù)產(chǎn)出，監(jiān)控所指的是對于預(yù)期研發(fā)階段，由產(chǎn)品經(jīng)理進(jìn)行的進(jìn)度跟蹤等，從時間來看是否有延期風(fēng)險，從產(chǎn)品范圍來看是否存在頻繁變更，從質(zhì)量來看是否可達(dá)到上線標(biāo)準(zhǔn)。

在開發(fā)和測試階段，除了進(jìn)度跟蹤，產(chǎn)品經(jīng)理也需要做好支持工作。產(chǎn)品落地是一個漸進(jìn)明細(xì)的過程，隨著開發(fā)、測試的深入，或多或少會有問題需要確認(rèn)。

比如依賴的數(shù)據(jù)指標(biāo)無法如期產(chǎn)出，則不需要在本期中展示，比如初期定義的指標(biāo)維度在實現(xiàn)時進(jìn)行了擴(kuò)展，接下來要如何讓用戶可以感知。

驗收，會涉及到產(chǎn)品、UI&UE驗收。在一期的產(chǎn)品中，沒有UI&UE的人力資源，故未進(jìn)行后者的驗收，對頁面的整體要求是基本可看。

對于有視覺疑問的地方，因為做不到像素級的肉眼，沒有具體的優(yōu)化建議，比如說間隔X像素，雖看著有些別扭，仍未對前端同學(xué)進(jìn)行反饋。專業(yè)的人做專業(yè)的事，更能讓人信服。

在一期產(chǎn)品中由于QA資源有限，由我進(jìn)行了共計3輪的產(chǎn)品+功能的驗收與回歸。在驗收之時，同評審階段一樣，需要做好驗收紀(jì)要，特別是遺留問題和已完成內(nèi)容，便于后續(xù)轉(zhuǎn)交與迭代。

身為QA之時，看著PM驗收，總覺得ta們驗收的好快，發(fā)現(xiàn)的問題總是不一樣。以前不明白，現(xiàn)在些許懂得了一些。

• Q：功能測試，產(chǎn)品驗收的區(qū)別在哪里？
• A：前者關(guān)注功能是否可用，側(cè)重于局部與異常處理；后者關(guān)注的是否好用，著重于整體與用戶體驗。

4. 收尾-發(fā)布

圖3-8 收尾-發(fā)布腦圖

產(chǎn)品驗收達(dá)到上線標(biāo)準(zhǔn)時，會進(jìn)入到整個流程的收尾環(huán)節(jié)——發(fā)布。

App端經(jīng)常會用到白名單、灰度、ABtest等方法進(jìn)行小范圍試驗，然后開始逐步放量，用大量的數(shù)據(jù)來驗證效果，一般會進(jìn)行版本控制，這樣低版本的app則不會透傳無關(guān)內(nèi)容。

對于Web端的產(chǎn)品，因為沒有版本這一層限制與隔離保護(hù)，當(dāng)服務(wù)上線時，更需要產(chǎn)品經(jīng)理做好信息公告，用戶反饋的收集工作，特別是在服務(wù)遷移時更是如此，才能做好平臺與數(shù)據(jù)的平穩(wěn)過渡、快速應(yīng)對。

• 在之前的KFZJ項目中，以周為維度進(jìn)行功能上線，在信息公告這一塊做得不夠好。有大版本的新內(nèi)容時雖以郵件形式通知了全部用戶，但用戶是否查收，是否看到內(nèi)容，無法進(jìn)行一一收集。后續(xù)調(diào)整為以釘釘內(nèi)的消息通知關(guān)鍵相關(guān)方-各業(yè)務(wù)組長（管理層），但至執(zhí)行層的信息透傳仍然存在一定的遺失。
• 本次的一期產(chǎn)品，涉及到了服務(wù)遷移。從確認(rèn)需要遷移到遷移完成，前后共計2周，遷移方案中涉及了現(xiàn)狀概況，遷移步驟（數(shù)據(jù)錄入->單節(jié)點驗證->全量切換），備用計劃，人員安排（共4人），遺留問題同步。在遷移中，共發(fā)現(xiàn)7個問題，涉及產(chǎn)品，技術(shù)，業(yè)務(wù)，數(shù)據(jù)4個方面。

5. 收尾-效果評估

圖3-9 收尾-效果評估腦圖

效果評估和發(fā)布的前綴都是收尾，為何要拆分2個？首先，我們常常會忽略收尾，一個完結(jié)之后就迅速投入下一產(chǎn)品，也就是俗話說的虎頭蛇尾；其次效果評估是一個比發(fā)布艱難的事情。

對于效果評估，從3個層面來講：

1. 對于個人，逐漸形成屬于個人的最佳實踐和方法論的沉淀；
2. 對于團(tuán)隊，一個項目的成敗與團(tuán)隊成員息息相關(guān)，不論是經(jīng)驗，還是教訓(xùn)，都需要總結(jié)，避免重蹈覆轍；
3. 對于公司，考慮收益如何體現(xiàn)，以數(shù)據(jù)來說話的話，首先要有可測量的數(shù)據(jù)指標(biāo)。

可測量就是個比較復(fù)雜的東東，特別是非主流程的優(yōu)化。比如DiDi的彩色小車–乘客在app內(nèi)看到的地圖上小車icon會隨著接單車輛的顏色而變化。

這個小小的產(chǎn)品可以幫助乘客更直觀更快速的找到車輛，直觀、快速如何用數(shù)據(jù)來衡量？開個腦洞，比如從司乘的IM、電話等對話內(nèi)容來進(jìn)行數(shù)據(jù)對比，從輿論數(shù)據(jù)來進(jìn)行抓取。

圖3-10 彩色大車

四、總結(jié)

在這五個階段中，我認(rèn)為產(chǎn)品經(jīng)理的重點為啟動-需求挖掘分析與規(guī)劃-評審，前者對應(yīng)的產(chǎn)品的自身專業(yè)能力，而后者則是整體掌控能力的體現(xiàn)。

產(chǎn)品的實現(xiàn)，離不開團(tuán)隊協(xié)作。在一期時面對的是新團(tuán)隊、新業(yè)務(wù)方，有公司老員工、新入職員工、實習(xí)生、原ZF干部。

新團(tuán)隊處于動蕩期，彼此不熟悉，需要一定的磨合期，產(chǎn)品經(jīng)理如何做好其中的潤滑劑，提供支持？作為有責(zé)無權(quán)的PM，我的做法是以身作則，信任，借力。

在做QA時，期待有一個可以把控全局、哪里有問題哪里就有ta出現(xiàn)的產(chǎn)品。

雖然還有一些不足，我已在路上。

共勉，以上。

#說明：圖3-2，3-3源自網(wǎng)上，如有侵權(quán)，請私信。

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

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