入行以來陷谱，側(cè)重點都是偏向前端即所謂的C端，較少觸及后臺項目瑟蜈，細(xì)細(xì)數(shù)來不過三四個而已烟逊。最近再次從0到1完成了一個后臺項目，感觸頗多铺根。借總結(jié)復(fù)盤之機(jī)宪躯，分享一些自己的體會。不管是流于表面也好位迂，或是對你幫助自然更佳访雪，一同共勉前行。

目錄：

一掂林、項目背景

二臣缀、項目生命周期

三王滤、階段拆解分述

四偷霉、總結(jié)分析

一因惭、項目背景

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

目標(biāo)用戶：母公司的品質(zhì)合作商未玻、已經(jīng)合作的渠道商厂汗、孵化項目的運營人員

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

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

二稼虎、項目生命周期

如上圖所示，后臺項目產(chǎn)品的流程與前端項目相比而言招刨，有些節(jié)點還是存在差異的霎俩。一般而言，可以分為：啟動-產(chǎn)品需求挖掘? →? 啟動-功能需求挖掘 →? 執(zhí)行-規(guī)劃、立項打却、評審? →? 執(zhí)行-需求杉适、設(shè)計、評審柳击、測試?? →? 執(zhí)行-開發(fā)猿推、測試、驗收? →? 收尾-發(fā)布捌肴、數(shù)據(jù)監(jiān)控 → 收尾-復(fù)盤總結(jié)蹬叭、迭代需求，六個階段状知。

三秽五、階段拆解分述

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

產(chǎn)品需求挖掘饥悴，如果從崗位劃分來說是產(chǎn)品經(jīng)理的職責(zé)范疇坦喘，可是作為體驗設(shè)計師，你如果不參與這個過程西设，在某種程度上瓣铣，后續(xù)在理解業(yè)務(wù)深度上是有可能存在偏差的。所以贷揽，建議相關(guān)用戶體驗設(shè)計師在產(chǎn)品需求初立坯沪，即加入討論。當(dāng)然這個恐怕需要結(jié)合不同公司擒滑，不同合作團(tuán)隊來看哈腐晾，有些產(chǎn)品不一定樂意體驗設(shè)計師提前介入。

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

不管是B端產(chǎn)品藻糖，還是C端產(chǎn)品，搜離不開客群用戶库车。KCL項目的用戶群體巨柒，其實有些不同。如上圖所示柠衍，分為三大群體：所在內(nèi)部孵化平臺運營人員洋满、入駐渠道商及渠道商下屬的門店相關(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)行處理裆泳，這種情況極大的影響了平臺品牌傳播。

因而柠硕，項目平臺希望新版后臺項目可以加強(qiáng)對于商品工禾、門店、商戶的影響和控制力蝗柔。避免因為入駐商戶或門店的服務(wù)影響到平臺自身的品牌建設(shè)帜篇。

改版用戶目標(biāo)

3.2、啟動-功能需求挖掘

功能需求挖掘的核心在于需求的管理和排序管理诫咱。當(dāng)然笙隙，對于明確目標(biāo)用戶同樣重要。目標(biāo)用戶客群是篩選需求層級的標(biāo)準(zhǔn)因素之一坎缭。因為與C端不同竟痰，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項目來說饮焦，我們除內(nèi)部KCL業(yè)務(wù)場景的需求，還有母公司分配過來的需求窍侧。技術(shù)需求的基數(shù)一般比較小县踢，這種需求主要存在于外部需求情況下會產(chǎn)生技術(shù)類需求，一般都是由業(yè)務(wù)需求產(chǎn)生技術(shù)類需求伟件。各種需求匯集成需求池硼啤，對于需求的優(yōu)先級排序就顯得極為重要。

3.3锋爪、執(zhí)行-規(guī)劃丙曙、立項、評審

嗯…其骄，其實這個階段亏镰，我暫時未參與。上圖中關(guān)于立項的細(xì)節(jié)拯爽，主要是通過一高級產(chǎn)品朋友獲知索抓。關(guān)于規(guī)劃立項這個，據(jù)說一些大廠有的是由產(chǎn)品來推動毯炮，有的是由高級體驗來推動立項逼肯，立項通過后，需要負(fù)責(zé)人協(xié)調(diào)各個部門資源去推動你立項的細(xì)節(jié)桃煎，上線之后的指標(biāo)會直接影響你最終的考核篮幢。話題跑遠(yuǎn)了，關(guān)于立項這個環(huán)節(jié)为迈，依不同公司和項目團(tuán)隊自定三椿，非必要環(huán)節(jié)。

但每次發(fā)起需求時葫辐，也需要明確產(chǎn)品的價值搜锰，如何去衡量收益，是否與項目耿战、公司目標(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)理玻褪、用戶體驗設(shè)計師、視覺設(shè)計師（非必須）公荧、研發(fā)（此階段可不參加）带射。之后依據(jù)確立當(dāng)前版本的迭代規(guī)劃，開始交互方案設(shè)計循狰。至于界面設(shè)計窟社，需要看后臺項目的實際情況券勺，KCL項目來說，因為并未采用比較知名的設(shè)計語言框架灿里，所以关炼，需界面設(shè)計師介入。一般如果采用了例如antdesign設(shè)計組件的時候匣吊，一般不需要界面設(shè)計師介入的儒拂。

B端產(chǎn)品更多是通過技術(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ù)期和平臺本身的運營成本岳链。例如KCL項目來說，商品的控制劲件，最初是考慮商戶同樣具有操作權(quán)限的掸哑，但是在后續(xù)與業(yè)務(wù)方溝通之后，發(fā)現(xiàn)其本質(zhì)來說零远，平臺上售賣的商品資產(chǎn)狀態(tài)已經(jīng)歸屬于平臺苗分。之所以，會需要商戶入駐牵辣，主要是為了解決C端用戶購買之后摔癣，去線下核銷的時候，確認(rèn)資產(chǎn)合法性的。

在交互設(shè)計或者界面設(shè)計過程中择浊，還有一點比較重要的就是組件化戴卜。組件化搭建設(shè)計界面對于設(shè)計后期維護(hù)，對于減輕研發(fā)的成本都是有非常大幫助的琢岩。但是要搭建組件化項目投剥，這需要考慮兩種情況，一是從0到1的時候粘捎，這個時候一開始就確認(rèn)搭建組件化設(shè)計和研發(fā)是最為理想化的薇缅；二是從1到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)限）壳鹤，特別是對于后臺項目的設(shè)計體驗有很大幫助盛龄。

3.3.3、交互評審

關(guān)于交互評審芳誓，此處不同團(tuán)隊又有不同情況余舶，UED團(tuán)隊比較小的，一般都是產(chǎn)品兼職交互方案設(shè)計锹淌，此時匿值，方案需要在產(chǎn)品部分內(nèi)部進(jìn)行內(nèi)審，這個內(nèi)審赂摆，一般超過兩次為佳挟憔，不然……哼哼，能力不佳的影響會不由的在別人印象里滋生烟号。不管是內(nèi)審還是外審曲楚，都最好自己設(shè)計一個自我審查表，走查一遍褥符，以避免不要的低級錯誤出現(xiàn)龙誊。對于中大型UED團(tuán)隊，交互方案一般都是用戶體驗設(shè)計師來主導(dǎo)喷楣。同時也是由體驗設(shè)計師主講趟大。

3.3.4鹤树、測試

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

3.4岛蚤、執(zhí)行-開發(fā)邑狸、測試、驗收

開發(fā)技術(shù)評審涤妒，建議是盡量可以參加的就參加单雾。這也是在KCL項目中，感受頗深的一個體會她紫。雖然說研發(fā)內(nèi)部評審的時候硅堆，更多的是討論技術(shù)可行性，以及工時預(yù)估等贿讹。但是如果可以及時并根據(jù)每個人分到的模塊渐逃，可以有效的控制deadline的風(fēng)險，以及上線排期和排隊審批流程民褂。特別是產(chǎn)品或交互方案設(shè)計的關(guān)鍵流程茄菊，要熟知是哪位研發(fā)負(fù)責(zé)，后續(xù)溝通中助赞，如果出現(xiàn)問題买羞，也可以及時協(xié)調(diào)資源進(jìn)行補(bǔ)救。

技術(shù)測試的時候雹食，作為體驗設(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)移下一期。問題無法一一言明赎离。還有一點逛犹，需要注意的是技術(shù)測，注重的是功能的可用以及局部和異常處理。對于項目的整體和體驗并不會關(guān)注虽画。所以舞蔽，對于交互體驗，還是需要體驗或PM親自驗收的码撰。

對于產(chǎn)品驗收和體驗設(shè)計驗收渗柿，正如上文所說，與技術(shù)側(cè)關(guān)注點不同脖岛。重點在于界面視覺元素的布局是否符合用戶預(yù)期和使用習(xí)慣朵栖，功能操作是否符合用戶的認(rèn)知，信息獲取是否增加了學(xué)習(xí)成本等柴梆。驗收結(jié)束陨溅，一定要輸出一份驗收記錄。記錄當(dāng)前遺留問題和已完成功能轩性，主要是為后續(xù)迭代規(guī)劃或者移交工作留存記錄声登。

3.5狠鸳、收尾-發(fā)布揣苏、數(shù)據(jù)監(jiān)控?

當(dāng)各項驗收基本無問題（主流程走通=上線標(biāo)準(zhǔn)），App端經(jīng)常會用到白名單件舵、灰度卸察、A/B test等方法進(jìn)行小范圍試驗，然后開始逐步放量铅祸，用大量的數(shù)據(jù)來驗證效果坑质，例如：今日頭條非常喜歡搞A/B test，然后通過兩個方案的數(shù)據(jù)對比來決定最終哪種方案临梗。

對于Web端的產(chǎn)品涡扼，因為沒有版本這一層限制與隔離保護(hù)，當(dāng)服務(wù)上線時盟庞，更需要產(chǎn)品經(jīng)理做好信息公告吃沪，用戶反饋的收集工作，特別是在服務(wù)遷移時更是如此什猖，才能做好平臺與數(shù)據(jù)的平穩(wěn)過渡票彪、快速應(yīng)對。在KCL項目中不狮，主要遇到了數(shù)據(jù)遷移和上線放量內(nèi)測階段出現(xiàn)問題較多降铸。B端項目，和C端項目測試有個很大差異——B端用戶摇零，使用你的系統(tǒng)或項目都是循序漸進(jìn)的推掸，甚至試用半年以上都有。當(dāng)然，如果品牌背書過硬谅畅，這個時間線就會比較短俊嗽。

數(shù)據(jù)監(jiān)測的軟件非常多，可以根據(jù)團(tuá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)隊工作情況允許的情況下揽惹，是非常有必要的被饿。雖然作為B端產(chǎn)品來說，好用搪搏、易用不是首要衡量標(biāo)準(zhǔn)狭握，但是如果可以做的體驗更好，對于后續(xù)市場的占領(lǐng)也是一個優(yōu)勢疯溺。與C端產(chǎn)品比較大差異的是论颅，對于用戶的感受，B端產(chǎn)品最好是可以與用戶訪談交流的囱嫩。因為是否有效的提升了其企業(yè)內(nèi)部的管理效率恃疯，實際的調(diào)研比單純的詩句更具有說服力（C端產(chǎn)品另說）。

這個階段墨闲，復(fù)盤總結(jié)和規(guī)劃迭代的需求是相輔相成的今妄。迭代需求的規(guī)劃，其實就是一個新的項目流程的開始损俭。這點對于不同團(tuán)隊有不同的后續(xù)蛙奖，有的做完從0到1之后，是規(guī)劃下一版本（小版本兩周一迭代杆兵，大版本一個月一迭代雁仲，遵循MVP）；有的團(tuán)隊琐脏，卻是需要移交后續(xù)團(tuán)隊去運營攒砖，接下來是新的項目的從0到1流程缸兔。

四、總結(jié)分析

這六個過程吹艇，從思維層來說：僅僅是自己從實際項目中考慮總結(jié)的一點個人看法惰蜜。其中對于PM或者體驗設(shè)計來說，重點在于啟動和收尾受神，把控好這兩個階段抛猖，對于項目來說起碼成功三分之一了。中間主要看的是團(tuán)隊資源和實力鼻听。從界面層來說财著，還有一個非常重要的點，就是組件化的規(guī)范撑碴。掌握好組件的利用撑教，對于構(gòu)建交互方案、對于與開發(fā)對接和溝通會讓你有想不到的愜意醉拓。關(guān)于組件化的思路伟姐，可以看看另外一篇文章。