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

編輯導讀：B端產(chǎn)品設計千頭萬緒，一個小功能往往業(yè)需要進行很復雜的思考，本文作者從B端零售業(yè)中訂單軌跡這一小功能的設計出發(fā)，來分享一下自己對B端產(chǎn)品功能設計的思考，希望對你有幫助。

筆者目前在負責一個O2O訂單中臺產(chǎn)品，產(chǎn)品的主要功能為：聚合分發(fā)訂單以實現(xiàn)訂單的履約，所謂聚合，是獲取了美團外賣，餓百，有贊等公域和私域的O2O訂單，進行了訂單數(shù)據(jù)的一致化標準化。所謂分發(fā)，是將數(shù)據(jù)一致化后的訂單分發(fā)至門店作業(yè)系統(tǒng)，聚合物流系統(tǒng)，ERP系統(tǒng)，統(tǒng)一進行標準化揀貨作業(yè)，標準化配送，標準化記賬與庫存管理。

接下來我們了解一下訂單軌跡日志是什么：

對于B端產(chǎn)品來說，可用性是產(chǎn)品的基礎，可用性一般指兩個方面：

1. 解決方案能夠解決企業(yè)問題；
2. 系統(tǒng)可持續(xù)穩(wěn)定的運行；在產(chǎn)品運營過程中，客戶反饋產(chǎn)品不可用，可能并不是業(yè)務解決方案有問題。

而監(jiān)控是降低運維成本，保證系統(tǒng)穩(wěn)定運行的有效手段，在B端產(chǎn)品中，監(jiān)控一般分為兩個方面:

1. 業(yè)務監(jiān)控：如訂單軌跡日志，憑證生成監(jiān)控等，這些功能本質(zhì)是對服務層的關(guān)鍵節(jié)點的轉(zhuǎn)義描述-問題定義與預警
2. 系統(tǒng)監(jiān)控：如數(shù)據(jù)庫資源監(jiān)控，redis監(jiān)控等，這些功能本質(zhì)是對存儲層的運行情況的描述與預警；

那么我們可以看出，訂單日志軌跡是B端產(chǎn)品中的一個業(yè)務監(jiān)控功能。那么訂單軌跡日志作為一個監(jiān)控功能是怎么幫助我們降低運維成本，保證系統(tǒng)穩(wěn)定運行的呢，就像我們剛剛在業(yè)務監(jiān)控功能本質(zhì)上描述的一樣，主要體現(xiàn)在兩個方面：

1. 關(guān)鍵節(jié)點的轉(zhuǎn)義描述：以發(fā)生時間正序可視化展示訂單狀態(tài)的變更，節(jié)省運維過程中查詢數(shù)據(jù)庫的時間，降低理解數(shù)據(jù)庫中編碼的含義的難度。同時在運維過程中可以清晰的判斷訂單的業(yè)務進行是否正常；
2. 問題定義與預警：如訂單未正常同步狀態(tài)，或者退單長時間沒有被審核，可能會造成財務憑證的生成的延遲，造成對賬與扣減庫存等一系列問題。故需要定義出什么情況下需要識別為問題，并自動進行提醒相關(guān)人員，減少運維過程中面對大量訂單無法進行便捷的識別問題的現(xiàn)象。

總結(jié)以下，訂單軌跡日志就是以發(fā)生時間正序展示訂單狀態(tài)變更及其變更原因，并提供異常預警的功能。該功能的業(yè)務背景和解決方案是清晰的，在中臺系統(tǒng)中，相較于其他功能，訂單軌跡日志是一個很小的功能，但是小功能在設計過程中，也經(jīng)歷了很復雜的思考。

原因在于：

1、B端零售業(yè)訂單中臺系統(tǒng)的復雜性；

2、B端系統(tǒng)功能設計過程中的資源有限性；

接下來，我從這兩個方面給大家介紹，這兩個屬性帶來的一些我們不得不去進行思考的點；

一、系統(tǒng)的復雜性

1.1? 復雜系統(tǒng)中，目標用戶的定義

該需求的來源方是組內(nèi)的系統(tǒng)支持工程師，那目標用戶就是他嗎？通過用戶訪談并查閱了工單系統(tǒng)中類似問題的反映數(shù)量及在各個項目的分布，我們發(fā)現(xiàn)，對于用戶側(cè)的運營人員，訂單軌跡日志功能也是他們普遍的訴求。由此可見，需求的來源方可能并不是唯一的目標用戶。這就要求我們在B端設計過程中，對現(xiàn)實世界進行抽象。

用戶一般具有過多與當前業(yè)務無關(guān)的屬性，如認知水平，個人喜好（B端產(chǎn)品主要依靠優(yōu)化業(yè)務流程的各個節(jié)點來最終實現(xiàn)提高效率的訴求，實際操作系統(tǒng)的用戶作為系統(tǒng)的一個節(jié)點，往往由于產(chǎn)品策略選擇，必須被要求具備相適應的認知水平和操作方式等，如財務系統(tǒng)操作人員必須具備基礎的財務知識，故在抽象B端產(chǎn)品的目標用戶時，一般不對具體對象認知水平，個人操作喜好等做重點的考量），需要進行剝離，抽象出普遍的用戶畫像，我們稱之為角色。抽離出角色后，我們接下來就可以很方便的針對運維支持的角色進行設計。

1.2? 復雜系統(tǒng)中，關(guān)鍵節(jié)點如何轉(zhuǎn)義描述

在訂單中臺系統(tǒng)中，由于涉及到很多系統(tǒng)的數(shù)據(jù)，實際我們在做關(guān)鍵節(jié)點的轉(zhuǎn)義描述過程，就是對數(shù)據(jù)進行一致化標準化的過程，一般可以按照以下思路進行：

數(shù)據(jù)收集→數(shù)據(jù)整理→數(shù)據(jù)展示

1.2.1 數(shù)據(jù)的收集

我們可以從具體業(yè)務場景和抽象的系統(tǒng)設計兩個層面進行了分析：

從業(yè)務場景分析：訂單軌跡日志作為業(yè)務監(jiān)控的一項功能，在實際使用場景中，需要提供兩個方面的信息：

1. 訂單的狀態(tài)變更：運維支持人員可以通過訂單狀態(tài)的描述，判斷業(yè)務流轉(zhuǎn)是否正常，狀態(tài)是 對某一對象一個時間段內(nèi)業(yè)務進展的概括性描述；
2. 造成訂單狀態(tài)變更的動作：當運維支持人員發(fā)現(xiàn)訂單狀態(tài)變更異常時，可以通過判斷造成訂單狀態(tài)變更的動作來判斷問題原因；

從系統(tǒng)設計層面分析：面向?qū)ο蠓椒▽r間看錯一個個相互獨立的個體，相互之間沒有因果關(guān)系，他們之間平時保持獨立，在某個外力的驅(qū)動下，對象之間才會依據(jù)某種規(guī)律相互傳遞信息，這些交互構(gòu)成一個業(yè)務場景。在訂單這個業(yè)務場景中，我們可以將外賣平臺，訂單中臺，ERP系統(tǒng)都視為一個對象。此時，當我們針對外賣平臺這個對象設計功能時，我們需要考慮以下三個方面：

1. 對象描述：描述對象本身的屬性
2. 輸入信息：其他對象傳遞給訂單中臺的信息，即造成訂單中臺本身屬性發(fā)生變化的外力
3. 輸出信息：訂單中臺傳遞給其他對象的信息，即造成其他對象屬性發(fā)生變化的外力

得到以下初步的結(jié)果：

在B端行業(yè)，現(xiàn)有業(yè)務的技術(shù)實現(xiàn)方式會深刻影響到功能的設計，故通常在功能設計階段就需要和開發(fā)進行充分的互動，以確認我們單純從業(yè)務場景和系統(tǒng)設計兩個層面梳理的展示數(shù)據(jù)是否正確能夠描述訂單的軌跡，一方面是資源有限，要充分理解現(xiàn)有功能實現(xiàn)邏輯，避免對系統(tǒng)改造較大的設計，以控制開發(fā)成本；另一個方面，訂單軌跡日志功能作為業(yè)務監(jiān)控的一環(huán)，本身就是對服務層關(guān)鍵節(jié)點的描述，服務層的邏輯當然是開發(fā)同學更為熟悉。

通過和開發(fā)確認，我們發(fā)現(xiàn)了需要增刪的地方：

1. 門店前臺系統(tǒng)中的數(shù)據(jù)是其自行調(diào)用訂單中臺接口進行的查詢，且不對訂單狀態(tài)造成影響，不應展示；
2. ERP系統(tǒng)不會給訂單中臺系統(tǒng)主動推送數(shù)據(jù)，需要訂單中臺系統(tǒng)主動查詢，且不對訂單狀態(tài)造成影響，不應展示；
3. 訂單系統(tǒng)會根據(jù)配置，自動實現(xiàn)狀態(tài)的變更，需要進行展示；

經(jīng)過整理細化，展示的數(shù)據(jù)為（數(shù)據(jù)已脫敏）：

1.2.2 數(shù)據(jù)整理

當我們確認好要展示的數(shù)據(jù)后，我們需要按照一定的規(guī)則對數(shù)據(jù)進行整理，形成一致的標準化的文案，方便用戶閱讀。我們一般將【時間+描述+操作人】定義為一個元件，元件按照發(fā)生時間正序排列，形成完整的訂單軌跡日志，如：

2020-11-11 13:46 推送【新訂單】消息至訂單中臺? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?美團外賣

2020-11-11 13:47 自動同步訂單到 訂單中臺? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?訂單中臺

2020-11-11 13:47 訂單總狀態(tài)變?yōu)椤鹃T店作業(yè)中】? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 訂單中臺

2020-11-11 13:46 門店操作【揀貨完成】? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 門店前臺作業(yè)系統(tǒng)

2020-11-11 13:47 呼叫【美團配送】成功，運單號：100111? ? ? ? ? ? ? ? ? 訂單中臺系統(tǒng)

2020-11-11 13:48 推送【騎手取貨】消息至鼎力云系統(tǒng),騎手姓名：張? ? ?聚合物流系統(tǒng)

數(shù)據(jù)整理的原則是：

• 顆粒度適中：通過合并同類動作，去除重復動作，使得訂單軌跡日志不至于過于啰嗦，如同步訂單狀態(tài)時，訂單中臺既會接收外賣平臺的消息推送，也會在接收到消息推送后主動調(diào)用外賣平臺接口查詢訂單狀態(tài)確認狀態(tài)是否為最新狀態(tài)，以保證在訂單狀態(tài)高頻變動的階段獲取正確的數(shù)據(jù)，這時就不需要展示如此的詳細，既展示消息推送，也展示拉取的動作，只展示消息推送的數(shù)據(jù)即可。
• 明確視角：應明確說明信息的發(fā)送者，接收者或者狀態(tài)變更的操作人是誰，以明確視角，不至于混亂
• 統(tǒng)一規(guī)則：同一類操作的文案需要保持一致，如【時間+推送【XXX】消息至訂單中臺+操作人】描述其他系統(tǒng)向訂單中臺推送的數(shù)據(jù)
• 通俗易懂：不要使用技術(shù)語言，如回調(diào)，JOB等，而是使用通俗易懂的語言進行描述；

1.2.3 數(shù)據(jù)展示

• 確定信息優(yōu)先級：從數(shù)據(jù)整理的結(jié)果來看，一筆訂單的訂單軌跡日志數(shù)據(jù)過多，需要判斷信息的優(yōu)先級，優(yōu)先展示重要的信息。從使用場景來看，正常情況下只需要關(guān)注訂單狀態(tài)，異常的情況下才需要查看造成訂單狀態(tài)變更的原因。故優(yōu)先展示狀態(tài)信息；
• 區(qū)分視角，貼切場景：由于存在訂單中臺接收的數(shù)據(jù)和推送給其他系統(tǒng)的數(shù)據(jù),故決定采用將輸入和輸出的數(shù)據(jù)分開展示；

最終經(jīng)過方案細化，展示效果示意圖如下：

1.3 復雜系統(tǒng)中，如何進行問題的定義與預警功能的設計

如圖所示，訂單的創(chuàng)建是一個異步的動作，會出現(xiàn)接收到新訂單消息，鼎力云中卻沒有創(chuàng)建訂單的問題，同樣的，也會出現(xiàn)狀態(tài)不同步的問題，針對此類情況，就必須先將問題定義出來，然后設置預警功能，從而保證業(yè)務的正常進行。此塊內(nèi)容較多，下篇文章再詳細介紹。

二、資源的有限性

產(chǎn)品功能隨著邊界的蔓延，邊際收益也在遞減，所以產(chǎn)品的功能是有邊界的。在【中臺產(chǎn)品經(jīng)理寶典】一書中，作者提出：ROI(投資回報率)是衡量B端產(chǎn)品功能的標桿，產(chǎn)品經(jīng)理必須考考慮一個功能的投入和收益

由上圖可知，為提高ROI，則必須在產(chǎn)品設計時減少投入，因為對于B端來說，收益不是特別好量化，那么可行的方向就是：重點降低功能推廣成本，后期運維成本的同時壓縮開發(fā)成本，這就要求我們在產(chǎn)品設計時必須做以下工作：

確認哪些功能特性必須滿足，必須做的功能特性中，哪些優(yōu)先做，以壓縮開發(fā)成本。

我們可以使用簡化版的KANO模型來進行分析：

• 可用性的功能特性必須實現(xiàn)，且優(yōu)先實現(xiàn)，放在一期版本。如：展示基本的狀態(tài)和輸入輸出數(shù)據(jù)，以及預警功能；
• 易用性的功能特性必須實現(xiàn)，但優(yōu)先度不高，放在二期版本。如：使用時間軸的方式進行數(shù)據(jù)的展示
• 超預期的功能特性選擇實現(xiàn)，優(yōu)先度最低，放在需求池中。

訂單軌跡日志功能借助尼爾森可用性原則優(yōu)化交互體驗，以減少后期的運維成本和功能推廣使用的成本：

• 一致性和標準化：即在數(shù)據(jù)整理階段進行的展示形式的標準化和一致化，為用戶提供一致性的閱讀體驗，減少認知成本；
• 人性化幫助原則：在界面上提供了功能的使用說明；

充分理解現(xiàn)有功能實現(xiàn)邏輯，少做對系統(tǒng)改造較大的設計，以控制開發(fā)成本。

舉個例子，在整理門店前臺作業(yè)系統(tǒng)時，我們希望記錄某一個操作具體是門店的哪個人做的。但是由于之前的接口中并為定義具體的操作人字段，門店前臺作業(yè)系統(tǒng)自然也無法將此值同步至訂單中臺系統(tǒng)。那么我們就將這個功能特性先放棄了，計劃在后期針對這個場景做專門的需求，以防止需求的蔓延。

三、總結(jié)

在B端產(chǎn)品設計過程中，由于B端產(chǎn)品本身的復雜性和資源有限性，導致我們在設計即使是一個小功能時，也必須進入深度的思考以回答做什么以及怎么做的問題，在這個過程中，還要兼顧業(yè)務，技術(shù)和商務，我們常常戲稱自己是在王八殼里蓋立交橋，但是這也是B端產(chǎn)品設計的魅力吧。

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

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