同事推薦了我一篇文章 [[New Feature Validation Framework]]，平常對管理知識沒了解太多的我從裡面學到了些驗證分析的方法分享給大家。
通常我們討論一個工作事項要不要做時，大多是團隊有一個共同的價值觀，大家都覺得重要的事情就會排進來做。但是有些事情不是每個人看法都相同，此時團隊通常會用不同面向的討論方式來決策這件事情的優先程度。
而這篇文章裡面就提到了一些討論方法可以用來協助做這件事情的決策，他裡面提到了幾種方法，第一個是建構價值觀的方法，後面三個是不同角度的驗證方法：
- 精實價值樹 (Lean Value Tree)：先建立組織的目標與實際執行細節的連結
- Reverse Impact Map：新想法出現時，用來驗證是否符合組織目標
- 狩野模型 (Kano Model)：另一個維度的評估，推敲這個功能使用者的滿意程度
- 開發與延遲成本：用成本的角度評估新想法的優先程度與什麼時候該開始實作
精實價值樹 (Lean Value Tree, LVT) 是一種概念工具讓組織的價值觀、目標連結到實際手邊在做的工作事項，這個通常都是從宏觀角度往微觀角度的方向討論與決定。
LVT 從宏觀到微觀把價值觀分成四個顆粒細度，我自己也透過我們公司的狀況來做個練習。
![[perp-lvt.png]]
一個組織存在的目的，也就是為客戶或社會所創造的核心價值，也可以說是公司存在的意義。
比如說 Perpetual Protocol 存在的核心價值就是要作為一個永續經營的衍伸金融商品的積木，讓其他 DeFi 專案可以透過我們提供的積木組成更多樣化的金融衍生商品。
對於組織未來狀態的描述，可以說是希望組織未來可以成為什麼樣子。這邊不講要怎麼做到，只講未來要成為什麼樣子。
目標需要有明確且恰當的時間長度，通常是一年到三年，如果組織規模愈小，層級越少時間跨度就愈短，反之則愈長。而且同一個時間點，目標不應該太多，通常會是三個以內，最多不超過五個。因為這些戰略目標應該是要更聚焦一些。
另外每個目標應該都要有一到三個可以量化的數據指標，作為成功的衡量標準。
比如說 Perpetual Procotol 的目標應該有幾個：
- 市佔率第一的去中心化交易所
- 全去中心化 (Fully Decentralized)
- 全開放源碼 (Fully Open Source)
這些目標都應該要以達成組織願景為考量。
策略賭注是達成目標的途徑，針對每一個目標都要有數個嘗試完成該目標的方向，只是用不同的方向去達成。
比如說 Perpetual Protocol 基於完成「市佔率第一的去中心化交易所」的策略賭注可能是：
- Mobile friendly
- Integrate with popular protocol
- Reduce system risk
舉措是投資方向上面的具體行動跟措施，這些舉措應該都可以沿著策略賭注的方向，讓組織的狀態愈來愈靠近目標狀態。
比如說在 Perpetual Protocol 的舉措可能是：
- 開發 Mobile UI
- permissionless market
- integrate with uniswap v3
- 新版本改善系統風險
LVT 裡面提到各種顆粒細度的項目之間的關係可以用下面這張圖來看會比較清楚
![[lvt direction explain.png]]
有了 LVT 後對於組織的願景以及目標有了大方向，目前進行的工作也都可以找到是支持哪種改善方向與目標時，接下來就可以透過這邊捕捉到的價值觀來驗證一項工作事項的優先程度，如上述所說，有三個不同面向的驗證方式。
講 Reverse Impact Map 之前要了解 Impact Map，Impact Map 是一個四層的心智圖，用來敘述從目標 (goal) 到可交付內容 (deliverable) 之間的關係，跟 LVT 相比有些類似的地方，也有額外的維度來看影響層級：
- Goal 目標 (Why)
- 為什麼我們要這麼做？
- 最主要的目的是什麼？
- Actors 參與者 (Who)
- 誰可以產生或阻止我們想要的目標？
- 誰是產品的使用者？
- 誰會被這個目標影響？
- Impact 影響 (How)
- 參與者行為會如何改變？
- 參與者會怎麼樣改變行為來達成我們的目標？
- 參與者會怎麼樣阻止我們達成目標？
- Deliverables 可交付內容 (What)
- 做什麼事情可以達成以上的影響？
Impact Map 有很多介紹文章就不贅述。而 Reverse Impact Map 則是想要做一個功能 (Deliverable) 時，可以用以上這幾個面向來分析是否要實作。
再拿 Perpetual Protocol 為例，我們之前有討論是是否要實作針對我們系統的 SDK，透過反向的分析方式就會是這樣：
- Deliverable
- SDK
- Impact
- 內部專案可以花更少時間整合不同商業邏輯
- 外部專案可以更輕易的整合我們的系統
- Actor
- 組織內部的開發者
- 外部開發者
- Goal
- 往後可以有更快的開發速度
- 更多人使用我們的系統
這個時候我們已經有了前面產生的 LVT，可以看看這樣的目標是不是符合原本組織的目標，如果有，代表這個功能符合我們組織的價值觀，如果沒有，有可能是不符合組織的價值觀，或是可能只是之前沒有考慮或歸納到目標（或是方向），就可以進行更進一步的討論。
Kano 模型是狩野紀昭（Noriaki Kano）提出對於 雙因素理論 (Two-factor theory) 的延伸，只是原本用在反應工作的滿意程度改成用在產品滿意度。
雙因素理論是研究評估一個員工的工作是否滿意時，原本覺得滿意跟不滿意是同一條軸線，但後來發現「不滿意」的事情改善了之後並不會變成「滿意」，而是變成「沒有不滿意」，所以其實是兩條軸線：
- 不滿意 -> 沒有不滿意
- 沒有滿意 -> 滿意
前者稱為保健因素 (Hygiene factors)，只能保健，不能強身，這些因素有薪資、人際關係、公司政策等；後者稱為激勵因素 (Motivational Factors)，因素有工作帶來的成就感、對公司的認同感、工作本身的意義。
而 Kano Model 則是把原本用在員工對工作滿意程度的雙因素理論 (Two-factor theory)，變成了評估客戶對特定功能的滿意程度。
![[kano model.png]]
你要做的行動（比如說想實作的功能）對用戶的影響可能會是以下幾種。
沒有這個功能，使用者會不滿意，但是即使有了使用者也只是覺得這是應該的。比如說電影院如果有上一場客人留下來的垃圾，你就會很不滿，但是如果很整潔，你也只會覺得剛好。
如果沒有該功能，使用者就會不滿意，如果具備時滿意度就會隨之提升。通常一維需求也會稱為 Performance (性能或表現)。比如說像餐廳出菜的越快，效能越好通常使用者就越滿意，反之相反，通常都是比較線性的需求。
不具備該功能時，使用者不會太過不滿意，但是如果有該功能時，使用者的滿意度會大大的提升。舉例來說 Pixel 手機剛開始出來時令人驚豔的相機就是這樣的功能，平常大家對於拍照品質都感到滿足了，但是 Pixel 手機的相機功能遠遠超越其他手機時，所有顧客對他的滿意程度就會大幅提升。
但是當所有手機都可以做到這樣的功能時，魅力需求就會變成基本需求了。
有沒有該項功能都沒關係。比如說定博客來經常會有廣告推薦單，有沒有都沒差。
當在評估一群準備要進行的工作項目時，可以先將要做的功能先分類一下，看看他們是屬於哪類的功能。基本需求是最重要的，會導致使用者不滿意；一維需求需要保持在一定的水準。當前兩者都滿足時，就會需要一些魅力需求來做出市場區隔。
延遲成本 (Cost of delay) 是指「如果這件事情晚點再做，會損失多少資金？」，這可以用來判斷如果一個功能現在就要做，或是晚點才做。
延遲成本通常是決定優先順序的因素之一，但除此之外還需評估分析、設計、建構、測試一個功能所需要的成本，這個就是開發成本。
當了解延遲成本以及開發成本後，決定要開發什麼功能跟什麼時候要開發就有一個更清楚的脈絡來決定了。
比如說開發一個 mobile friendly 的網站，每個月帶來新增的使用者所佔的收入預估是每個月 100,000 美金，而分析、設計、建構、測試會需要花費四個人一個月的工作時數，若以一個工程師月薪 5000 美金估算約花費 20,000 美元，這樣就可以很清楚地得知這個功能會需要盡快開發，甚至投入兩個月都非常值得。
如果假設他可以帶來的收益是每個月 1,000 美金，這樣我們也可以知道他的優先程度排定時可以排較低的優先程度。
同時這樣的方法可以用來評估重構的必要程度。如果重構可以減低之後的開發成本可以大略估算時，這樣也可以評估一個重構的優先程度以及什麼時候該執行。
原本的文章介紹了我們一些工具跟方法，當想要實作一個新工作事項時我們有什麼工具跟方法可以來驗證這個新的工作事項。
Lean Value Tree 跟 Reverse Impact Map 可以用來確保一個工作事項有符合公司的大方向。Kano Model 可以用來評估一個工作事項對客戶來說代表的是怎樣的滿意程度，而開發成本則可以衡量什麼時候該開始開發這個功能，跟優先程度。
相信評估這些事項的方法不只這些，不過這些讓我對驗證新功能的方法有一些基礎的認識，或許隨著時間可以瞭解到更多不一樣的評估方法。
- [[New Feature Validation Framework]]
- [[DDD：Lean Value Tree（精益价值树） - ShouKai Blog]]
- [[服務設計模型：kano Model]]