本文作者對一個B端項(xiàng)目進(jìn)行了復(fù)盤，著重從流程角度對項(xiàng)目進(jìn)行拆解，闡述其中需要注意的地方。

入行以來，側(cè)重點(diǎn)都是偏向前端即所謂的C端，較少觸及后臺項(xiàng)目，細(xì)細(xì)數(shù)來不過三四個而已。最近再次從0到1完成了一個后臺項(xiàng)目，感觸頗多。

借總結(jié)復(fù)盤之機(jī)，分享一些自己的體會。不管是流于表面也好，或是對你幫助自然更佳，一同共勉前行。

目錄：

1. 項(xiàng)目背景
2. 項(xiàng)目生命周期
3. 階段拆解分述
4. 總結(jié)分析

一、項(xiàng)目背景

產(chǎn)品定位：滿足內(nèi)部孵化項(xiàng)目后臺管理、統(tǒng)計分析需求，代號為PGD后臺管理系統(tǒng)。

目標(biāo)用戶：母公司的品質(zhì)合作商、已經(jīng)合作的渠道商、孵化項(xiàng)目的運(yùn)營人員。

痛點(diǎn)：重要的用戶數(shù)據(jù)、交易數(shù)據(jù)、商品數(shù)據(jù)部署在第三方平臺，且分布分散，無法形成有效的管理和統(tǒng)計分析。

產(chǎn)品目標(biāo)：通過線上、可視化平臺進(jìn)而降低操作門檻、合作限制，減少核心資源的投入和依賴，從而有效提升平臺的渠道商入駐率和商品的質(zhì)量。最終，形成平臺性的影響力和品牌效應(yīng)。

二、項(xiàng)目生命周期

（可點(diǎn)擊放大）

如上圖所示，后臺項(xiàng)目產(chǎn)品的流程與前端項(xiàng)目相比而言，有些節(jié)點(diǎn)還是存在差異的。

一般而言，可以分為六個階段：

1. 啟動：產(chǎn)品需求挖掘；
2. 啟動：功能需求挖掘；
3. 執(zhí)行：規(guī)劃、立項(xiàng)、評審；
4. 執(zhí)行：需求、設(shè)計、評審、測試；
5. 執(zhí)行：開發(fā)、測試、驗(yàn)收；
6. 收尾：發(fā)布、數(shù)據(jù)監(jiān)控；
7. 收尾：復(fù)盤總結(jié)、迭代需求。

（可點(diǎn)擊放大）

三、階段拆解分述

3.1 啟動：產(chǎn)品需求挖掘

（可點(diǎn)擊放大）

產(chǎn)品需求挖掘，如果從崗位劃分來說是產(chǎn)品經(jīng)理的職責(zé)范疇。可是作為體驗(yàn)設(shè)計師，你如果不參與這個過程，在某種程度上，后續(xù)在理解業(yè)務(wù)深度上是有可能存在偏差的。

所以，建議相關(guān)用戶體驗(yàn)設(shè)計師在產(chǎn)品需求初立，即加入討論。當(dāng)然，這個恐怕需要結(jié)合不同公司，不同合作團(tuán)隊(duì)來看哈，有些產(chǎn)品不一定樂意體驗(yàn)設(shè)計師提前介入。

3.1.1 目標(biāo)用戶分析

不管是B端產(chǎn)品，還是C端產(chǎn)品，都離不開客群用戶。

KCL項(xiàng)目的用戶群體，其實(shí)有些不同。如上圖所示，分為三大群體：所在內(nèi)部孵化平臺運(yùn)營人員、入駐渠道商及渠道商下屬的門店相關(guān)人員。不同群體又涉及不同的利益相關(guān)者，這就需要在進(jìn)行目標(biāo)用戶分析的時候，注意不同用戶需求問題的收集，并設(shè)置不同的登記編號。

3.1.2 用戶目標(biāo)分析

改版或者舊版架構(gòu)關(guān)系如上圖所示，平臺對于服務(wù)商下屬的門店沒有影響和控制力，門店出現(xiàn)服務(wù)差評或者用戶投訴的時候，只可以通過門店的上層服務(wù)商進(jìn)行處理，這種情況極大的影響了平臺品牌傳播。

因而，項(xiàng)目平臺希望新版后臺項(xiàng)目可以加強(qiáng)對于商品、門店、商戶的影響和控制力，避免因?yàn)槿腭v商戶或門店的服務(wù)，影響到平臺自身的品牌建設(shè)。

改版用戶目標(biāo)

3.2 啟動：功能需求挖掘

功能需求挖掘的核心，在于需求的管理和排序管理。

當(dāng)然，對于明確目標(biāo)用戶同樣重要。目標(biāo)用戶客群，是篩選需求層級的標(biāo)準(zhǔn)因素之一。

因?yàn)榕cC端不同，B端的決策者、購買者、使用者通常不會是同一波人，并且價值優(yōu)先級為決策層>管理層>執(zhí)行層。故在權(quán)衡決策產(chǎn)品時，不僅需要從多層級來進(jìn)行綜合平衡，需要更加關(guān)注對決策層和管理層的價值。決策層，可能是業(yè)務(wù)方的boss們，也可能是上級主管層。

而我們獲取需求的方式，一般主要分為業(yè)務(wù)需求、技術(shù)需求和功能迭代優(yōu)化需求。業(yè)務(wù)需求又分為內(nèi)部需求和外部需求。例如所在KCL項(xiàng)目來說，我們除內(nèi)部KCL業(yè)務(wù)場景的需求，還有母公司分配過來的需求。

技術(shù)需求的基數(shù)一般比較小，這種需求主要存在于外部需求情況下會產(chǎn)生技術(shù)類需求，一般都是由業(yè)務(wù)需求產(chǎn)生技術(shù)類需求。各種需求匯集成需求池，對于需求的優(yōu)先級排序就顯得極為重要。

3.3 執(zhí)行：規(guī)劃、立項(xiàng)、評審

其實(shí)這個階段，我暫時未參與。上圖中關(guān)于立項(xiàng)的細(xì)節(jié)，主要是通過一高級產(chǎn)品朋友獲知。

關(guān)于規(guī)劃立項(xiàng)這個，據(jù)說一些大廠有的是由產(chǎn)品來推動，有的是由高級體驗(yàn)來推動立項(xiàng)。立項(xiàng)通過后，需要負(fù)責(zé)人協(xié)調(diào)各個部門資源去推動立項(xiàng)的細(xì)節(jié)，上線之后的指標(biāo)會直接影響最終的考核。

話題跑遠(yuǎn)了，關(guān)于立項(xiàng)這個環(huán)節(jié)，依不同公司和項(xiàng)目團(tuán)隊(duì)自定，非必要環(huán)節(jié)。但每次發(fā)起需求時，也需要明確產(chǎn)品的價值，如何去衡量收益，是否與項(xiàng)目、公司目標(biāo)有關(guān)聯(lián)，是否一致。

這個對于接下來的需求排序和交互方案設(shè)計，有著重要的參考依據(jù)價值。

3.3 執(zhí)行：需求、設(shè)計、評審、測試

3.3.1 需求評審

由上一個階段篩選初步需求優(yōu)先級之后，需要進(jìn)行需求評審。

需求評審的參與方，一般包含業(yè)務(wù)方、產(chǎn)品經(jīng)理、用戶體驗(yàn)設(shè)計師、視覺設(shè)計師（非必須）、研發(fā)（此階段可不參加）。之后，依據(jù)確立當(dāng)前版本的迭代規(guī)劃，開始交互方案設(shè)計。

至于界面設(shè)計，需要看后臺項(xiàng)目的實(shí)際情況，KCL項(xiàng)目來說，因?yàn)椴⑽床捎帽容^知名的設(shè)計語言框架。所以，需界面設(shè)計師介入。如果采用了例如antdesign設(shè)計組件的時候，界面設(shè)計師一般不需要介入的。

B端產(chǎn)品更多是通過技術(shù)實(shí)現(xiàn)互聯(lián)網(wǎng)信息化管理，對企業(yè)流程進(jìn)行優(yōu)化升級，從而達(dá)到降本增效的目的。而C端比較追求極致的簡單好用，在整個產(chǎn)品設(shè)計上比較側(cè)重用戶的感受，偏向精心打磨頁面與交互，盡量少讓用戶做選擇，以保持產(chǎn)品的易用性與流暢性。

3.3.2 設(shè)計

在考慮交互方案設(shè)計的時候，需要格外注意產(chǎn)品的信息架構(gòu)設(shè)計。這其中菜單結(jié)構(gòu)設(shè)計、菜單功能父子級梳理，內(nèi)容信息布局——上下結(jié)構(gòu)、左右結(jié)構(gòu)、上下（左右）結(jié)構(gòu)又是重中之重。所有這些，必須都是基于業(yè)務(wù)流程來考慮。

如上圖（平臺管理員權(quán)限圖），在不同級別功能權(quán)限設(shè)置上，需要考慮的是符合用戶的操作預(yù)期和平臺本身的運(yùn)營成本。

例如KCL項(xiàng)目，商品的控制，最初是考慮商戶同樣具有操作權(quán)限的，但是在后續(xù)與業(yè)務(wù)方溝通之后，發(fā)現(xiàn)就其本質(zhì)來說，平臺上售賣的商品資產(chǎn)狀態(tài)已經(jīng)歸屬于平臺。之所以會需要商戶入駐，主要是為了解決C端用戶購買之后，去線下核銷的時候，確認(rèn)資產(chǎn)合法性的。

在交互設(shè)計或者界面設(shè)計過程中，還有一點(diǎn)比較重要的就是組件化。組件化搭建設(shè)計界面對于設(shè)計后期維護(hù)，對于減輕研發(fā)的成本都是有非常大幫助的。

要搭建組件化項(xiàng)目，需要考慮兩種情況：一是從0到1的時候，這個時候一開始就確認(rèn)搭建組件化設(shè)計和研發(fā)是最為理想化的；二是從1到N的過程中，這個時候，要么一點(diǎn)一點(diǎn)修改前端顯示和模塊化功能，要么就是集中另外一組人力且有一個牛逼架構(gòu)師，快速搭建新的平臺，后續(xù)轉(zhuǎn)移數(shù)據(jù)。

設(shè)計過程中，最好需要考慮CRUD原則（crud是指在做計算處理時的增加(Create)、讀取查詢(Read)、更新(Update)和刪除(Delete)幾個單詞的首字母簡寫）和RBAC模型（RBAC，基于角色的權(quán)限控制，模型的核心是在用戶和權(quán)限之間引入了角色的概念，取消了用戶和權(quán)限的直接關(guān)聯(lián)，改為通過用戶關(guān)聯(lián)角色、角色關(guān)聯(lián)權(quán)限的方法來間接地賦予用戶權(quán)限），特別是對于后臺項(xiàng)目的設(shè)計體驗(yàn)有很大幫助。

3.3.3 交互評審

關(guān)于交互評審，此處不同團(tuán)隊(duì)又有不同情況。

UED團(tuán)隊(duì)比較小的，一般都是產(chǎn)品兼職交互方案設(shè)計。此時，方案需要在產(chǎn)品部分內(nèi)部進(jìn)行內(nèi)審，這個內(nèi)審，一般超過兩次為佳。不管是內(nèi)審還是外審，都最好自己設(shè)計一個自我審查表，走查一遍，以避免不要的低級錯誤出現(xiàn)。

對于中大型UED團(tuán)隊(duì)，交互方案一般都是用戶體驗(yàn)設(shè)計師來主導(dǎo)，也是由體驗(yàn)設(shè)計師主講。

3.3.4 測試

這里的測試，與后續(xù)技術(shù)測試無任何相關(guān)性。此處的測試是以交互方案或者界面方案為基礎(chǔ)，設(shè)置跳轉(zhuǎn)動效邏輯之后，行程與正式功能相差無異的操作體驗(yàn)測試。其目的在于，及時發(fā)現(xiàn)方案中不合理或者存在的問題。

3.4 執(zhí)行：開發(fā)、測試、驗(yàn)收

開發(fā)技術(shù)評審，建議是盡量可以參加的就參加。這也是在KCL項(xiàng)目中，感受頗深的一個體會。

雖然說研發(fā)內(nèi)部評審的時候，更多是討論技術(shù)可行性，以及工時預(yù)估等。但是，如果可以及時并根據(jù)每個人分到的模塊，可以有效控制deadline的風(fēng)險，以及上線排期和排隊(duì)審批流程。

特別是產(chǎn)品或交互方案設(shè)計的關(guān)鍵流程，要熟知是哪位研發(fā)負(fù)責(zé)。后續(xù)溝通中，如果出現(xiàn)問題，也可以及時協(xié)調(diào)資源進(jìn)行補(bǔ)救。

技術(shù)測試的時候，作為體驗(yàn)設(shè)計師或者PM，最好與測試同學(xué)就各種細(xì)節(jié)，和衡量指標(biāo)進(jìn)行有效的溝通。不然，彼此之間可能會出現(xiàn)一些小誤會。存在依賴關(guān)系的API是否已經(jīng)開放完畢，非關(guān)鍵流程的數(shù)據(jù)指標(biāo)沒有及時產(chǎn)出，是否轉(zhuǎn)移下一期……問題無法一一言明。

還有一點(diǎn)，需要注意的是技術(shù)側(cè)，注重的是功能的可用以及局部和異常處理，對于項(xiàng)目的整體和體驗(yàn)并不會關(guān)注。所以，對于交互體驗(yàn)，還是需要體驗(yàn)或PM親自驗(yàn)收的。

對于產(chǎn)品驗(yàn)收和體驗(yàn)設(shè)計驗(yàn)收，正如上文所說，與技術(shù)側(cè)關(guān)注點(diǎn)不同。重點(diǎn)在于界面視覺元素的布局是否符合用戶預(yù)期和使用習(xí)慣，功能操作是否符合用戶的認(rèn)知，信息獲取是否增加了學(xué)習(xí)成本等。

驗(yàn)收結(jié)束，一定要輸出一份驗(yàn)收記錄。記錄當(dāng)前遺留問題和已完成功能，主要是為后續(xù)迭代規(guī)劃或者移交工作留存記錄。

3.5 收尾：發(fā)布、數(shù)據(jù)監(jiān)控

當(dāng)各項(xiàng)驗(yàn)收基本無問題（主流程走通=上線標(biāo)準(zhǔn)），App端經(jīng)常會用到白名單、灰度、A/B test等方法進(jìn)行小范圍試驗(yàn)，然后開始逐步放量，用大量的數(shù)據(jù)來驗(yàn)證效果。

例如：今日頭條非常喜歡搞A/B test，然后通過兩個方案的數(shù)據(jù)對比來決定最終哪種方案。對于Web端的產(chǎn)品，因?yàn)闆]有版本這一層限制與隔離保護(hù)，當(dāng)服務(wù)上線時，更需要產(chǎn)品經(jīng)理做好信息公告、用戶反饋的收集工作，在服務(wù)遷移時更是如此，才能做好平臺與數(shù)據(jù)的平穩(wěn)過渡、快速應(yīng)對。

在KCL項(xiàng)目中，主要是數(shù)據(jù)遷移和上線放量內(nèi)測階段出現(xiàn)問題較多。B端項(xiàng)目和C端項(xiàng)目測試有個很大差異——B端用戶，使用你的系統(tǒng)或項(xiàng)目都是循序漸進(jìn)的，甚至試用半年以上都有。當(dāng)然，如果品牌背書過硬，這個時間線就會比較短。

數(shù)據(jù)監(jiān)測的軟件非常多，可以根據(jù)團(tuán)隊(duì)選取適合的。因?yàn)槟腹静少徳?，后臺數(shù)據(jù)監(jiān)測經(jīng)歷過易觀、數(shù)倉、還有集團(tuán)內(nèi)部的自研系統(tǒng)。

總體來說，個人覺得易觀還好，其他的學(xué)習(xí)和掌控數(shù)據(jù)指標(biāo)方面需要增加一些學(xué)習(xí)成本。

3.6 收尾：復(fù)盤總結(jié)、迭代需求

對于復(fù)盤總結(jié)來說，如果團(tuán)隊(duì)工作情況允許的情況下，是非常有必要的。雖然作為B端產(chǎn)品來說，好用、易用不是首要衡量標(biāo)準(zhǔn)，但是如果可以體驗(yàn)更好，對于后續(xù)市場的占領(lǐng)也是一個優(yōu)勢。

與C端產(chǎn)品比較大差異的是，對于用戶的感受，B端產(chǎn)品最好是可以與用戶訪談交流的。因?yàn)槭欠裼行嵘似淦髽I(yè)內(nèi)部的管理效率，實(shí)際的調(diào)研比單純的詩句更具有說服力（C端產(chǎn)品另說）。

這個階段，復(fù)盤總結(jié)和規(guī)劃迭代的需求是相輔相成的。

迭代需求的規(guī)劃，其實(shí)就是一個新的項(xiàng)目流程的開始。這點(diǎn)對于不同團(tuán)隊(duì)有不同的后續(xù)，有的做完從0到1之后，是規(guī)劃下一版本（小版本兩周一迭代，大版本一個月一迭代，遵循MVP）；有的團(tuán)隊(duì)，卻是需要移交后續(xù)團(tuán)隊(duì)去運(yùn)營，接下來是新的項(xiàng)目的從0到1流程。

四、總結(jié)分析

這六個過程，從思維層來說，僅僅是自己從實(shí)際項(xiàng)目中考慮總結(jié)的一點(diǎn)個人看法。

對于PM或者體驗(yàn)設(shè)計來說，重點(diǎn)在于啟動和收尾，把控好這兩個階段，對于項(xiàng)目來說起碼成功三分之一了，中間主要看的是團(tuán)隊(duì)資源和實(shí)力。

從界面層來說，還有一個非常重要的點(diǎn)，就是組件化的規(guī)范。掌握好組件的利用，對構(gòu)建交互方案、與開發(fā)對接和溝通會有想不到的收獲。

作者：PGDWORKS；公眾號：PGDWORKS

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

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