編輯導語：B端產品通常需要支撐功能和產品功能來共同實現一個業務需求，那麼這兩種功能在設計實踐中，存在什麼特點呢？我們在日常實踐中，又該如何權衡產品功能和支撐功能的設計呢？關於這兩個問題，本文作者結合自己的工作經驗，為我們談了談他的一些看法。
近幾年，構建最小可行化方案（MVP）快速試錯，找尋市場切合點的敏捷開發的方法論受到各個互聯網公司的追捧。
但面向B端的產品天然具有着開發週期長，功能定製化的特點，為了用户需求可以快速響應的同時，實現功能的複用，往往在一個功能的早期不會設計和開發的盡善盡美，故會存在一個運維或者運營人員高強度支撐產品的階段。
有時候運維或者運營人員甚至會介入正常的業務流程中，充當“人肉補丁”，以保證在特殊情況下的業務可以正常進行。這些情況都是產品初期是正常操作，不可避免的。
所以我們通常需要支撐功能和產品功能共同實現一個業務需求，所謂支撐功能與產品功能，我們內部定義為：
- 支撐功能：為了支持業務正常進行提供給運營人員使用的功能；
- 產品功能：提供給客户側人員使用實現業務場景的功能。
支撐功能和產品功能在設計實踐中，存在以下特點：
1. 支撐功能與產品功能不存在明顯的業務範圍界限
如關閉訂單接單前部分退貨的功能，可以由門店在界面上單獨配置，也可以由運營人員在項目級別關閉，實現的業務場景基本一致，故不存在明顯的業務範圍界限。
2. 支撐功能與業務功能在一個業務流程期間可能交叉出現
如一個商家入住過程，可能存在商家入駐申請，運營配置租户，商家完善信息等階段。
3. 支撐功能由於面向內部專業人員，大部分時候不需要交互良好的流程和界面，故開發週期更短
如配置每5分鐘拉取一次或每天7帶點定時數據拉取的功能，就可以通過corn表達式的方式來控制，而不用提供繁多的控件。
由此可見，支撐功能和產品功能在如何更有效率的滿足業務場景方面存在重疊，在業務流程中交叉出現；而支撐功能開發週期較短，有利於快速響應用户需求，節省資源，為日後的產品優化提供空間。
所以我們在日常實踐中，我們該如何權衡產品功能和支撐功能的設計呢：
一、用户關注側重點的和運營關注側重點的權衡B端產品的產品價值在於解決問題，提高客户工作效率。故對於產品用户來説，他們並不關心一個功能是怎麼實現的，他們只關心在什麼場景下用什麼方式實現什麼目標，故需要權衡用户關注側重點的和運營關注側的重點。
以數據聚合功能為例，為了將各個前台系統數據進行聚合，需要進行以下流程：接口授權→數據拉取機制設置→數據展示
接口授權：即獲取數據源的接口授權，此操作由於涉及到接口賬號及密鑰的配置，屬於接口層面的對接操作，用户由於缺少對系統底層實現邏輯的認知和關注；此時交由用户自行配置，用户的學習成本較高，故應由運營人員進行操作，很明顯應設計成支撐功能。
數據拉取機制設置：產品支持設置時間間隔或固定時間點去拉取數據進行加工並郵件分發給預設用户的郵箱，由於產品資源有限，同時對所有租户在同一時間節點進行數據拉取與加工，對服務器性能有一定影響。
同時產品經理在調研後得知：
- 系統自動分批加工功能本期暫未無法上線，需要運營人員手動設置數據加工時間；
- 用户對於數據的發送沒有很強的時間點要求，一般工作日中午之前獲取到數據報表即可。
經過調研，我們得知：用户不關注數據拉取的機制設置；運營人員對於數據拉取機制較為關注。數據展示：應展示哪些數據字段，這是用户根據實際業務情況進行決定的，故應該做成產品功能。
二、 功能使用頻率和開發資源的權衡當功能的使用頻率較低，但佔用開發資源較多時，可以考慮使用支撐功能來實現。
以各個外賣平台都有的商品信息變動日誌為例，此功能滿足了用户在商品信息錯誤時，通過日誌找到錯誤發生的時間及操作人，進而確認錯誤原因。經過調研，我們得到兩個反饋：
- 各項目分別發生商品信息錯誤需要排查日誌確定問題原因的概率較低，但是目前存量客户整體出現這種業務訴求的次數較多；
- 開發對日誌功能方案進行了評估，指出如果做成產品功能，則對數據加工時效性有較高的要求，實現難度較大，需要提高數據庫資源。
在這種情況下，耗費了大量的資源，實現了一個單個項目使用頻率並不高的功能，在項目初期，投資回報率明顯是低的了，故最終採用設計支撐功能的方式來滿足此業務場景。
實現的方式為：使用mongoDB數據庫記錄日誌，當用户期望排查日誌確定商品信息異常變動問題原因時，向產品運營申請，產品運營在後台中定位日誌並提供給用户；
三、 風險控制的權衡在項目初期，權限控制，操作引導功能尚不完善，此時，如果識別到將功能交付給客户使用後風險較大，應採用支撐功能的方式來實現。
以異常數據修正功能為例：在日常工作之中，我們發現，由於系統計算邏輯未考慮全面，導致訂單數據出現異常，通常表現在訂單中相關金額計算異常，作為問題解決機制的一環，需要增加異常數據手工修正功能。
此功能設計時，由於對哪些訂單的數據可以進行修正無法識別，故所有訂單數據都允許進行修正。
但調研得知，目前權限控制系統較為粗糙，無法將此功能指定給組織中特定的用户，此時如果將該功能直接交付給所有客户，則會存在正常訂單也被修改的風險。
權衡之後，採取了使用支撐功能的方案解決；
四、操作效率的權衡在產品初期新上線了一個少部分項目不適用的一個新功能，故需要將功能設計成開關選項控制開啓。但用户側運營人員操作效率較低，可能在數天內都不進行選項的打開操作，進而造成功能無法大面積推廣。
出於操作效率的權衡，我們設計了一個支撐功能，以實現在後台開啓對應的業務功能。從這個例子可以看出，一各業務場景可能完全可以由用户自行操作。
但是因為各個用户的內部管理水平水平不一，為了功能的正常上線與推廣，也是需要設計支撐功能的；
結語：
需要注意的一點是，當運營人員可以通過支撐功能替代部分產品功能支撐業務場景時，會發現支撐功能具有影響範圍大，用户感知弱的特點，需要注意：
- 操作結果同步：運營人員在後台使用支撐功能的結果應讓用户可以感知到；
- 操作日誌記錄：運營人員在後台使用支撐功能時，應記錄操作日誌，以在出現問題時，方便確定影響範圍，進行回滾；
- 與產品功能不衝突，控制優先級問題：當產品功能和支撐功能可以對同一個業務場景進行控制時，應考慮兩者控制優先級問題，防止功能衝突；
- 支撐功能的退出機制：支撐功能應在產品功能逐漸成熟後退出正常的業務流程，但需要考慮如何從支撐功能切換為產品功能，以對現有系統影響最小。
最後的最後，大部分支撐功能在產品逐漸成熟後，應減少對產品功能的直接干預。
大部分業務支撐功能，都能在完善用户權限體系，完善異常處理機制，完善系統自動化處理邏輯後，支撐功能作為資源不充足，功能不完善的情況下支撐系統的千斤頂，應逐漸轉化為產品功能。
我們還需要了解到，產品經理大部分的工作都是在用户需求—開發資源中取得一個平衡點，動用無窮無盡的資源將產品功能在產品初期做到盡善盡美既不明智也不可能，支撐功能不是妥協，它是產品臨時的但正式的功能，我們應該正視它。
筆者畢業兩年，B端產品萌新一枚。期望可以將自己工作中的經驗分享給大家，第一次發文，請大家多多指教。
本文由 @kathic 原創發佈於人人都是產品經理，未經許可，禁止轉載
題圖來自 Pexels，基於 CC0 協議