中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

本文作者對一個B端項目進行了復盤，著重從流程角度對項目進行拆解，闡述其中需要注意的地方。

入行以來，側重點都是偏向前端即所謂的C端，較少觸及后臺項目，細細數來不過三四個而已。最近再次從0到1完成了一個后臺項目，感觸頗多。

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

目錄：

1. 項目背景
2. 項目生命周期
3. 階段拆解分述
4. 總結分析

一、項目背景

產品定位：滿足內部孵化項目后臺管理、統計分析需求，代號為PGD后臺管理系統。

目標用戶：母公司的品質合作商、已經合作的渠道商、孵化項目的運營人員。

痛點：重要的用戶數據、交易數據、商品數據部署在第三方平臺，且分布分散，無法形成有效的管理和統計分析。

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

二、項目生命周期

（可點擊放大）

如上圖所示，后臺項目產品的流程與前端項目相比而言，有些節點還是存在差異的。

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

1. 啟動：產品需求挖掘；
2. 啟動：功能需求挖掘；
3. 執行：規劃、立項、評審；
4. 執行：需求、設計、評審、測試；
5. 執行：開發、測試、驗收；
6. 收尾：發布、數據監控；
7. 收尾：復盤總結、迭代需求。

（可點擊放大）

三、階段拆解分述

3.1 啟動：產品需求挖掘

（可點擊放大）

產品需求挖掘，如果從崗位劃分來說是產品經理的職責范疇?？墒亲鳛轶w驗設計師，你如果不參與這個過程，在某種程度上，后續在理解業務深度上是有可能存在偏差的。

所以，建議相關用戶體驗設計師在產品需求初立，即加入討論。當然，這個恐怕需要結合不同公司，不同合作團隊來看哈，有些產品不一定樂意體驗設計師提前介入。

3.1.1 目標用戶分析

不管是B端產品，還是C端產品，都離不開客群用戶。

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

3.1.2 用戶目標分析

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

因而，項目平臺希望新版后臺項目可以加強對于商品、門店、商戶的影響和控制力，避免因為入駐商戶或門店的服務，影響到平臺自身的品牌建設。

改版用戶目標

3.2 啟動：功能需求挖掘

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

當然，對于明確目標用戶同樣重要。目標用戶客群，是篩選需求層級的標準因素之一。

因為與C端不同，B端的決策者、購買者、使用者通常不會是同一波人，并且價值優先級為決策層>管理層>執行層。故在權衡決策產品時，不僅需要從多層級來進行綜合平衡，需要更加關注對決策層和管理層的價值。決策層，可能是業務方的boss們，也可能是上級主管層。

而我們獲取需求的方式，一般主要分為業務需求、技術需求和功能迭代優化需求。業務需求又分為內部需求和外部需求。例如所在KCL項目來說，我們除內部KCL業務場景的需求，還有母公司分配過來的需求。

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

3.3 執行：規劃、立項、評審

其實這個階段，我暫時未參與。上圖中關于立項的細節，主要是通過一高級產品朋友獲知。

關于規劃立項這個，據說一些大廠有的是由產品來推動，有的是由高級體驗來推動立項。立項通過后，需要負責人協調各個部門資源去推動立項的細節，上線之后的指標會直接影響最終的考核。

話題跑遠了，關于立項這個環節，依不同公司和項目團隊自定，非必要環節。但每次發起需求時，也需要明確產品的價值，如何去衡量收益，是否與項目、公司目標有關聯，是否一致。

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

3.3 執行：需求、設計、評審、測試

3.3.1 需求評審

由上一個階段篩選初步需求優先級之后，需要進行需求評審。

需求評審的參與方，一般包含業務方、產品經理、用戶體驗設計師、視覺設計師（非必須）、研發（此階段可不參加）。之后，依據確立當前版本的迭代規劃，開始交互方案設計。

至于界面設計，需要看后臺項目的實際情況，KCL項目來說，因為并未采用比較知名的設計語言框架。所以，需界面設計師介入。如果采用了例如antdesign設計組件的時候，界面設計師一般不需要介入的。

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

3.3.2 設計

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

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

例如KCL項目，商品的控制，最初是考慮商戶同樣具有操作權限的，但是在后續與業務方溝通之后，發現就其本質來說，平臺上售賣的商品資產狀態已經歸屬于平臺。之所以會需要商戶入駐，主要是為了解決C端用戶購買之后，去線下核銷的時候，確認資產合法性的。

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

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

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

3.3.3 交互評審

關于交互評審，此處不同團隊又有不同情況。

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

對于中大型UED團隊，交互方案一般都是用戶體驗設計師來主導，也是由體驗設計師主講。

3.3.4 測試

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

3.4 執行：開發、測試、驗收

開發技術評審，建議是盡量可以參加的就參加。這也是在KCL項目中，感受頗深的一個體會。

雖然說研發內部評審的時候，更多是討論技術可行性，以及工時預估等。但是，如果可以及時并根據每個人分到的模塊，可以有效控制deadline的風險，以及上線排期和排隊審批流程。

特別是產品或交互方案設計的關鍵流程，要熟知是哪位研發負責。后續溝通中，如果出現問題，也可以及時協調資源進行補救。

技術測試的時候，作為體驗設計師或者PM，最好與測試同學就各種細節，和衡量指標進行有效的溝通。不然，彼此之間可能會出現一些小誤會。存在依賴關系的API是否已經開放完畢，非關鍵流程的數據指標沒有及時產出，是否轉移下一期……問題無法一一言明。

還有一點，需要注意的是技術側，注重的是功能的可用以及局部和異常處理，對于項目的整體和體驗并不會關注。所以，對于交互體驗，還是需要體驗或PM親自驗收的。

對于產品驗收和體驗設計驗收，正如上文所說，與技術側關注點不同。重點在于界面視覺元素的布局是否符合用戶預期和使用習慣，功能操作是否符合用戶的認知，信息獲取是否增加了學習成本等。

驗收結束，一定要輸出一份驗收記錄。記錄當前遺留問題和已完成功能，主要是為后續迭代規劃或者移交工作留存記錄。

3.5 收尾：發布、數據監控

當各項驗收基本無問題（主流程走通=上線標準），App端經常會用到白名單、灰度、A/B test等方法進行小范圍試驗，然后開始逐步放量，用大量的數據來驗證效果。

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

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

數據監測的軟件非常多，可以根據團隊選取適合的。因為母公司采購原因，后臺數據監測經歷過易觀、數倉、還有集團內部的自研系統。

總體來說，個人覺得易觀還好，其他的學習和掌控數據指標方面需要增加一些學習成本。

3.6 收尾：復盤總結、迭代需求

對于復盤總結來說，如果團隊工作情況允許的情況下，是非常有必要的。雖然作為B端產品來說，好用、易用不是首要衡量標準，但是如果可以體驗更好，對于后續市場的占領也是一個優勢。

與C端產品比較大差異的是，對于用戶的感受，B端產品最好是可以與用戶訪談交流的。因為是否有效提升了其企業內部的管理效率，實際的調研比單純的詩句更具有說服力（C端產品另說）。

這個階段，復盤總結和規劃迭代的需求是相輔相成的。

迭代需求的規劃，其實就是一個新的項目流程的開始。這點對于不同團隊有不同的后續，有的做完從0到1之后，是規劃下一版本（小版本兩周一迭代，大版本一個月一迭代，遵循MVP）；有的團隊，卻是需要移交后續團隊去運營，接下來是新的項目的從0到1流程。

四、總結分析

這六個過程，從思維層來說，僅僅是自己從實際項目中考慮總結的一點個人看法。

對于PM或者體驗設計來說，重點在于啟動和收尾，把控好這兩個階段，對于項目來說起碼成功三分之一了，中間主要看的是團隊資源和實力。

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

作者：PGDWORKS；公眾號：PGDWORKS

本文由 @PGDWORKS 原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議