如何衡量前端基建的效能價值？

關注「前端向後」微信公衆號，你將收穫一系列「用心原創」的高質量技術文章，主題包括但不限於前端、Node.js以及服務端技術

寫在前面
不一樣於商用產品，對內的工具/平臺大多沒有明確的直接業務價值，須要經過可量化的指標來衡量其效能價值，本文試圖創建一個可直接套用的數據指標框架，讓內部工具/平臺的價值也能看得見、說得清

一.分析生產活動的核心要素
從面向對象的角度來看，前端工程是對象和對象間的關係及交互行爲

（摘自面向對象視角下的前端工程體系）

其中，對象分爲主體對象與客體對象兩類：

對象，是對前端應用生產活動中各個實體的抽象，其中一些對象是主體（好比充當不一樣角色的人），另外一些是客體（好比工具、平臺等各類具體事物），對象之間經過一系列交互行爲來完成前端應用的開發和交付

即人與工具，是直接關係到生產力的核心要素：

工具越強大、越智能，人的操做效率越高、心智負擔越小

P.S.心智指的是人認識事物的方法和習慣，會影響用戶如何認知周遭世界以及如何採起行動，取決於對應角色的認知狀況、記憶、主動獲取教育與被動教育的渠道和方法、以及基於角色的競品使用習慣等，具體見工具類產品的體驗度量四象模型（1）

二.找出工具的關鍵目標
對工具而言，兼顧效率和體驗是不變的目標，但不一樣工具的側重點可能有所不一樣，例如：

• 不直面用戶的底層工具：如構建模塊、發佈模塊等，效率相對重要一些，體驗次之

• 用戶直接與之交互的上層工具：如調試器、發佈平臺等，更關注體驗，雖然效率也一樣重要

• 另外一方面，工具老是爲解決問題而生的，選用一個工具不外乎 4 種狀況：

• 無可替代：惟一可以解決目標問題的工具，沒得選，因此不論體驗、效率如何都不得不用

• 體驗最好：同類工具中使用體驗最好的一款，精準知足需求，效率上和其它工具沒有明顯差距

• 效率最高：同類工具中效率最高的一款，迅速解決問題，明顯比其它工具快不少

• 體驗還不錯，效率也過得去：同類工具中在體驗和效率上取得平衡的一款，沒有太明顯的缺點，勉強能解決問題，用起來也不很麻煩

• 除去沒得選的狀況，在效率沒有明顯差距時體驗更好的工具更受歡迎，效率能拉開明顯差距的工具若是沒有體驗硬傷必定會很受歡迎，這毫無疑問

• 然而，須要注意的是，若是體驗、效率方面的最優選項都有明顯的缺點，此時用戶更傾向於選擇一個不上不下的替代工具，而不是長期忍受其缺點：

啊。。是啊。。我不就是不想用 xxx 了

三.創建效能價值的度量模型
肯定了關鍵目標以後，接下來的問題是如何量化效率和體驗，使之可衡量

衡量效率
類比工做效率的計算公式：

工做效率 = 工做總量 / 工做時間
工具效率能夠定義爲：

工具效率 = 問題規模 / 操做時間
問題規模仍然不是一個可量化的東西，進一步具象爲時間成本：

工具效率 = （不用該工具解決所需的）時間成本 / （用該工具解決所需的）時間成本
那麼，有 3 種狀況：

• 比值等於 1：用不用工具都同樣，工具沒有帶來效率提高

• 比值小於 1：還不如不用，由於用工具花的時間反而更多了

• 比值大於 1：用工具效率更高，數值越大，工具帶來的效率提高越明顯

衡量體驗
體驗不像效率同樣可以經過統一的規則計算得出準確的數值，但也能夠創建度量模型：

體驗即產品與用戶心智的重合程度（上圖心智一行），工具的功能和性能越貼近用戶的心理預期，體驗評價越高，體如今：

• 易用程度：從用戶心智向產品功能作映射，極致的易用是符合直覺，上手即用

• 穩定程度：從用戶心智向產品性能作映射，極致的穩定是徹底信任，從不懷疑工具會出問題

即：

工具體驗 = 易用程度 * 穩定程度

也就是說，工具體驗是易用程度與穩定程度的乘積，只要稍有很差用或不穩定的缺點，體驗就會急劇降低

衡量效能價值
綜上所述，工具帶來的效能價值體如今 2 方面：

效能價值 = 效率價值 * 體驗因子

其中：

• 效率價值：下降用戶解決問題的時間成本，讓用戶更快速地解決問題

• 體驗因子：減小用戶的心智負擔，讓用戶更輕鬆愉悅地解決問題

兩者相輔相成，體驗升級可能會提升效率，效率提高一樣也可能帶動體驗

所以，在體驗有保障的前提下，能夠簡單地將效率做爲效能價值的衡量標準，用一個準確的比值便可量化效能價值

四.選擇合適的數據指標
有了度量模型後，接着將具體的數據指標框進來

時間成本
基於以上分析，（體驗有保障時）效率收益的直接體現是工具所能節省的時間成本，與用戶量、使用頻次、使用時長等密切相關：

• 用戶量：累計用戶數、日/周/月 UV、日新增用戶數、日/周/月活躍用戶數（期間操做過核心功能的用戶數）

• 使用頻次：日/周/月 PV、功能使用率、核心操做次數、日均使用次數

• 使用時長：核心操做時長

P.S.功能使用率 = 使用某項功能的用戶數 / 總用戶數，也能用來衡量不一樣功能對總體的貢獻

例如：

天天節省的時間成本 = 日用戶量 * 日功能使用率 * (不用該工具解決所需的時間 - 操做時間)
  = 100 * 35% * (1.5人日 - 0.8人日）
  = 24.5人日

此外，另外一些側面數據也能體現效能價值：

• 用戶分佈：目標用戶數、用戶***率、各屬性用戶佔比、各屬性用戶***率

• 產出結果分佈：數量、重要程度、平均時間、各屬性產出結果佔比

P.S.用戶***率可簡單理解爲用戶***率 = 現有用戶數 / 目標用戶數

例如：

覆蓋2/3的目標用戶，包括60%以上的一線開發人員、10%的測試人員
覆蓋8大產品線，半年支持40多個項目，包括效果極好的xx重點項目

易用程度
易用程度一樣也能經過一些數值來衡量：

• 用戶滿意度：用戶投訴與諮詢數/率、抽樣調查滿意度

• 操做難度：誤操做次數

• 心智負擔：幫助文檔字數、注意事項條數

此外，一種產品經理經常使用的需求採集方法是觀察真實用戶的實際操做，將用戶遇到的挫折記錄下來，過程當中不要打斷和急於提供幫助，每每可以精準地發現一些使用問題

穩定程度
穩定程度能夠從異常指標反映出來，例如：

• crash 率

• bug 數

• 操做失敗次數

其中，操做失敗是個模糊的定義，包括運行時錯誤、服務接口錯誤、搜索不到結果等等，穩定性問題極易破壞使用體驗，進而大幅拉低效能，好比工具總崩潰，幾乎無法用的話，效能價值就無從提及

五.有數據就用數聽說話
之因此要創建可量化的數據指標，是爲了用數聽說話，驗證此前的一些假設，爲工具的迭代、優化提供指導方向：

• 新功能是否獲得了用戶的支持？功能使用率如何？宣傳渠道有沒有效果？

• 用戶操做是否順暢，所花費的實際時間與預期是否存在較大差距？

• 產出結果如何，ROI 是否足夠高，有沒有必要繼續作下去？

用 PM 的成熟方法論作事