編輯導(dǎo)語：B端產(chǎn)品通常需要支撐功能和產(chǎn)品功能來共同實現(xiàn)一個業(yè)務(wù)需求，那么這兩種功能在設(shè)計實踐中，存在什么特點呢？我們在日常實踐中，又該如何權(quán)衡產(chǎn)品功能和支撐功能的設(shè)計呢？關(guān)于這兩個問題，本文作者結(jié)合自己的工作經(jīng)驗，為我們談了談他的一些看法。

近幾年，構(gòu)建最小可行化方案（MVP）快速試錯，找尋市場切合點的敏捷開發(fā)的方法論受到各個互聯(lián)網(wǎng)公司的追捧。

但面向B端的產(chǎn)品天然具有著開發(fā)周期長，功能定制化的特點，為了用戶需求可以快速響應(yīng)的同時，實現(xiàn)功能的復(fù)用，往往在一個功能的早期不會設(shè)計和開發(fā)的盡善盡美，故會存在一個運維或者運營人員高強度支撐產(chǎn)品的階段。

有時候運維或者運營人員甚至會介入正常的業(yè)務(wù)流程中，充當“人肉補丁”，以保證在特殊情況下的業(yè)務(wù)可以正常進行。這些情況都是產(chǎn)品初期是正常操作，不可避免的。

所以我們通常需要支撐功能和產(chǎn)品功能共同實現(xiàn)一個業(yè)務(wù)需求，所謂支撐功能與產(chǎn)品功能，我們內(nèi)部定義為：

• 支撐功能：為了支持業(yè)務(wù)正常進行提供給運營人員使用的功能；
• 產(chǎn)品功能：提供給客戶側(cè)人員使用實現(xiàn)業(yè)務(wù)場景的功能。

支撐功能和產(chǎn)品功能在設(shè)計實踐中，存在以下特點：

1. 支撐功能與產(chǎn)品功能不存在明顯的業(yè)務(wù)范圍界限

如關(guān)閉訂單接單前部分退貨的功能，可以由門店在界面上單獨配置，也可以由運營人員在項目級別關(guān)閉，實現(xiàn)的業(yè)務(wù)場景基本一致，故不存在明顯的業(yè)務(wù)范圍界限。

2. 支撐功能與業(yè)務(wù)功能在一個業(yè)務(wù)流程期間可能交叉出現(xiàn)

如一個商家入住過程，可能存在商家入駐申請，運營配置租戶，商家完善信息等階段。

3.?支撐功能由于面向內(nèi)部專業(yè)人員，大部分時候不需要交互良好的流程和界面，故開發(fā)周期更短

如配置每5分鐘拉取一次或每天7帶點定時數(shù)據(jù)拉取的功能，就可以通過corn表達式的方式來控制，而不用提供繁多的控件。

由此可見，支撐功能和產(chǎn)品功能在如何更有效率的滿足業(yè)務(wù)場景方面存在重疊，在業(yè)務(wù)流程中交叉出現(xiàn)；而支撐功能開發(fā)周期較短，有利于快速響應(yīng)用戶需求，節(jié)省資源，為日后的產(chǎn)品優(yōu)化提供空間。

所以我們在日常實踐中，我們該如何權(quán)衡產(chǎn)品功能和支撐功能的設(shè)計呢：

一、用戶關(guān)注側(cè)重點的和運營關(guān)注側(cè)重點的權(quán)衡

B端產(chǎn)品的產(chǎn)品價值在于解決問題，提高客戶工作效率。故對于產(chǎn)品用戶來說，他們并不關(guān)心一個功能是怎么實現(xiàn)的，他們只關(guān)心在什么場景下用什么方式實現(xiàn)什么目標，故需要權(quán)衡用戶關(guān)注側(cè)重點的和運營關(guān)注側(cè)的重點。

以數(shù)據(jù)聚合功能為例，為了將各個前臺系統(tǒng)數(shù)據(jù)進行聚合，需要進行以下流程：接口授權(quán)→數(shù)據(jù)拉取機制設(shè)置→數(shù)據(jù)展示

接口授權(quán)：即獲取數(shù)據(jù)源的接口授權(quán)，此操作由于涉及到接口賬號及密鑰的配置，屬于接口層面的對接操作，用戶由于缺少對系統(tǒng)底層實現(xiàn)邏輯的認知和關(guān)注；此時交由用戶自行配置，用戶的學(xué)習成本較高，故應(yīng)由運營人員進行操作，很明顯應(yīng)設(shè)計成支撐功能。

數(shù)據(jù)拉取機制設(shè)置：產(chǎn)品支持設(shè)置時間間隔或固定時間點去拉取數(shù)據(jù)進行加工并郵件分發(fā)給預(yù)設(shè)用戶的郵箱，由于產(chǎn)品資源有限，同時對所有租戶在同一時間節(jié)點進行數(shù)據(jù)拉取與加工，對服務(wù)器性能有一定影響。

同時產(chǎn)品經(jīng)理在調(diào)研后得知：

1. 系統(tǒng)自動分批加工功能本期暫未無法上線，需要運營人員手動設(shè)置數(shù)據(jù)加工時間；
2. 用戶對于數(shù)據(jù)的發(fā)送沒有很強的時間點要求，一般工作日中午之前獲取到數(shù)據(jù)報表即可。

經(jīng)過調(diào)研，我們得知：用戶不關(guān)注數(shù)據(jù)拉取的機制設(shè)置；運營人員對于數(shù)據(jù)拉取機制較為關(guān)注。數(shù)據(jù)展示：應(yīng)展示哪些數(shù)據(jù)字段，這是用戶根據(jù)實際業(yè)務(wù)情況進行決定的，故應(yīng)該做成產(chǎn)品功能。

二、 功能使用頻率和開發(fā)資源的權(quán)衡

當功能的使用頻率較低，但占用開發(fā)資源較多時，可以考慮使用支撐功能來實現(xiàn)。

以各個外賣平臺都有的商品信息變動日志為例，此功能滿足了用戶在商品信息錯誤時，通過日志找到錯誤發(fā)生的時間及操作人，進而確認錯誤原因。經(jīng)過調(diào)研，我們得到兩個反饋：

1. 各項目分別發(fā)生商品信息錯誤需要排查日志確定問題原因的概率較低，但是目前存量客戶整體出現(xiàn)這種業(yè)務(wù)訴求的次數(shù)較多；
2. 開發(fā)對日志功能方案進行了評估，指出如果做成產(chǎn)品功能，則對數(shù)據(jù)加工時效性有較高的要求，實現(xiàn)難度較大，需要提高數(shù)據(jù)庫資源。

在這種情況下，耗費了大量的資源，實現(xiàn)了一個單個項目使用頻率并不高的功能，在項目初期，投資回報率明顯是低的了，故最終采用設(shè)計支撐功能的方式來滿足此業(yè)務(wù)場景。

實現(xiàn)的方式為：使用mongoDB數(shù)據(jù)庫記錄日志，當用戶期望排查日志確定商品信息異常變動問題原因時，向產(chǎn)品運營申請，產(chǎn)品運營在后臺中定位日志并提供給用戶；

三、 風險控制的權(quán)衡

在項目初期，權(quán)限控制，操作引導(dǎo)功能尚不完善，此時，如果識別到將功能交付給客戶使用后風險較大，應(yīng)采用支撐功能的方式來實現(xiàn)。

以異常數(shù)據(jù)修正功能為例：在日常工作之中，我們發(fā)現(xiàn)，由于系統(tǒng)計算邏輯未考慮全面，導(dǎo)致訂單數(shù)據(jù)出現(xiàn)異常，通常表現(xiàn)在訂單中相關(guān)金額計算異常，作為問題解決機制的一環(huán)，需要增加異常數(shù)據(jù)手工修正功能。

此功能設(shè)計時，由于對哪些訂單的數(shù)據(jù)可以進行修正無法識別，故所有訂單數(shù)據(jù)都允許進行修正。

但調(diào)研得知，目前權(quán)限控制系統(tǒng)較為粗糙，無法將此功能指定給組織中特定的用戶，此時如果將該功能直接交付給所有客戶，則會存在正常訂單也被修改的風險。

權(quán)衡之后，采取了使用支撐功能的方案解決；

四、操作效率的權(quán)衡

在產(chǎn)品初期新上線了一個少部分項目不適用的一個新功能，故需要將功能設(shè)計成開關(guān)選項控制開啟。但用戶側(cè)運營人員操作效率較低，可能在數(shù)天內(nèi)都不進行選項的打開操作，進而造成功能無法大面積推廣。

出于操作效率的權(quán)衡，我們設(shè)計了一個支撐功能，以實現(xiàn)在后臺開啟對應(yīng)的業(yè)務(wù)功能。從這個例子可以看出，一各業(yè)務(wù)場景可能完全可以由用戶自行操作。

但是因為各個用戶的內(nèi)部管理水平水平不一，為了功能的正常上線與推廣，也是需要設(shè)計支撐功能的；

結(jié)語：

需要注意的一點是，當運營人員可以通過支撐功能替代部分產(chǎn)品功能支撐業(yè)務(wù)場景時，會發(fā)現(xiàn)支撐功能具有影響范圍大，用戶感知弱的特點，需要注意：

1. 操作結(jié)果同步：運營人員在后臺使用支撐功能的結(jié)果應(yīng)讓用戶可以感知到；
2. 操作日志記錄：運營人員在后臺使用支撐功能時，應(yīng)記錄操作日志，以在出現(xiàn)問題時，方便確定影響范圍，進行回滾；
3. 與產(chǎn)品功能不沖突，控制優(yōu)先級問題：當產(chǎn)品功能和支撐功能可以對同一個業(yè)務(wù)場景進行控制時，應(yīng)考慮兩者控制優(yōu)先級問題，防止功能沖突；
4. 支撐功能的退出機制：支撐功能應(yīng)在產(chǎn)品功能逐漸成熟后退出正常的業(yè)務(wù)流程，但需要考慮如何從支撐功能切換為產(chǎn)品功能，以對現(xiàn)有系統(tǒng)影響最小。

最后的最后，大部分支撐功能在產(chǎn)品逐漸成熟后，應(yīng)減少對產(chǎn)品功能的直接干預(yù)。

大部分業(yè)務(wù)支撐功能，都能在完善用戶權(quán)限體系，完善異常處理機制，完善系統(tǒng)自動化處理邏輯后，支撐功能作為資源不充足，功能不完善的情況下支撐系統(tǒng)的千斤頂，應(yīng)逐漸轉(zhuǎn)化為產(chǎn)品功能。

我們還需要了解到，產(chǎn)品經(jīng)理大部分的工作都是在用戶需求—開發(fā)資源中取得一個平衡點，動用無窮無盡的資源將產(chǎn)品功能在產(chǎn)品初期做到盡善盡美既不明智也不可能，支撐功能不是妥協(xié)，它是產(chǎn)品臨時的但正式的功能，我們應(yīng)該正視它。

筆者畢業(yè)兩年，B端產(chǎn)品萌新一枚。期望可以將自己工作中的經(jīng)驗分享給大家，第一次發(fā)文，請大家多多指教。

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

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