本文要點：
- 用通俗易懂的語言來陳述產品猜想（Product Conjectures）或假設（Hypotheses）是產品管理中的常見做法。爲了使用假設進行數據驅動型決策，它們需要表述爲適合自動化評估的格式。
- 假設可以使用功能（Capability）/ 結果（Outcome）/ 可測量信號（Measurable Signal）三元組半正式地表示，這樣可以把定性和定量的規範很好地結合起來 。
- 假設的自動評估要求將軟件開發人員的開發能力作爲功能實現的一部分進行規劃 。
- 假設的自動評估還需要軟件開發人員擁有運維技能，並把它們應用於功能實現的過程中。
- 假設的文檔需要在確定用戶故事的工具中直接完成。
數據驅動型決策系列文章
數據驅動型決策系列文章對數據驅動型決策如何支持軟件交付中的三個主要活動做了概述，這三個主要活動是：產品管理、開發和運維。
本系列由幾篇文章組成，每一篇都重點介紹了一個可以應用數據驅動型決策的領域：
- 在產品管理領域，假設可以用於確保產品決策的有效性。
- 在開發領域，持續交付指標（Continuous Delivery Indicators）可以用於確保開發過程的效率。
- 在運維領域，SRE的SLI和SLO可以確保指導生產中服務的可靠性。
在本系列文章中，我們還將展示如何同時應用假設、持續交付指標以及SRE的SLI/SLO，從而使軟件交付組織能夠同時爲有效性、效率和服務可靠性進行優化。
在Vladyslav Ukis的InfoQ個人資料中列出了該系列的所有文章。
簡介
軟件產品交付組織越來越頻繁地交付複雜的軟件系統。軟件交付涉及的主要活動是產品管理、開發和運維（這裏的確指的是活動，而不是各自獨立的部門，我們不推薦後面這種說法）。在每項活動中，必須快速做出很多決策以推進交付。在產品管理中，決策是關於功能優先級的。在開發中，它涉及的是開發過程的效率。在運維中，它關聯的是可靠性。
可以根據團隊成員的經驗做出決策。此外可以根據數據做出決策。這會帶來更客觀和透明的決策過程。尤其是隨着交付速度的提高及交付團隊數量的增加，組織變得透明的能力是讓所有人一直都保持一致，而不需要浪費時間的同步會議的重要手段。
我們在本文中探討了來自假設的數據如何支持產品管理活動，以及如何將數據用於快速的數據驅動型決策。反過來，這將導致產品交付組織透明度的提高和政治化程度的下降，最終支持更好的業務結果，例如提高用戶對軟件的使用率，或者提升累積收入水平。
我們報告了西門子醫療（Siemens Healthineers）在產品管理中應用假設的情況，西門子醫療是一個由位於不同國家的16個軟件交付團隊構成的大型分佈式軟件交付組織。
過程指標（Process Indicator），而非人員KPI
爲了以數據驅動的方式指導產品管理，我們需要一種方法來用數據表達產品管理中的主要活動。需要把這些數據視爲正在進行的工作的過程指標，而不是用於人員評估的關鍵績效指標（KPI）。這一點很重要，因爲如果這些數據被用於人員評估，那麼人們可能會傾向於以有利自己的方式來調整它們。
把數據作爲過程指標來處理很重要，不要用產品交付組織領導設立的人員評估KPI來處理，這麼做通常是爲了實現無偏差的數據質量和數據評估。
假設
在產品管理中，核心問題之一是“要構建什麼？”。軟件功能構建完成卻不使用的話就完全是浪費，因此這一點很重要。
爲了解決“要構建什麼”這個問題，產品交付團隊會做一些小實驗以探索客戶的需求，在生產中進行實驗是最理想的。每個實驗都需要相關的測量數據，用於證實或推翻最初的假設。這個過程是假設驅動開發（Hypothesis Driven Development，簡稱HDD）的主題。《如何實現假設驅動的開發》這篇文章對這個問題進行了很好的闡述。本質上，在HDD中，一個實驗被稱爲假設，並用功能/ 結果/ 可測量信號來描述：
假設：
我們認爲這個<功能>；
會導致這個客戶<結果>；
在生產中，看到這樣的<可測量信號>時，就可以知道我們成功了。
在功能實施開始之前，功能的假設定義就已經完成了。產品交付團隊聲明他們希望把哪個<功能>放入產品以實現特定的客戶<結果>。 定義的<可測量信號>在生產中變得可見時，就能知道這個客戶<結果>已經實現了。
這樣，產品交付團隊預先定義了他們如何預見客戶在生產中使用的功能。在功能開發過程中，該團隊還實現了<可測量信號>，以創建必要的工具來查看在生產中如何使用該功能。最終，一旦將這些功能部署到生產中，團隊將評估實際的<可測量信號>，以瞭解假設是否正確（構建→測量→學習）。
之後重複該過程；基於第一個假設的結果，制定第二個假設，然後實施並測量，以此類推。
以我們的經驗來看，整個過程也讓產品交付團隊從“只是一個功能工廠”轉變爲負責交付那些客戶在生產中實際使用的軟件。
也就是說，產品交付團隊把重點放在其提供給客戶的價值上，而不是僅僅計算交付給生產的功能有多少。
一直用假設工作的團隊根據來自生產的數據（自動的反饋循環；每次發佈都是一次科學實驗），通過優化客戶的軟件使用體驗，有效地解決客戶的問題領域。而在工作中不用假設的團隊只生產功能，而不測量用戶生產中的功能使用率。
從項目到產品
如今，很多組織在從項目過渡到產品。引入假設可以支持這種轉變。因爲在項目中，需求工程的範圍只限於開發工作，項目往往到這裏就結束了，所以沒有包括髮布和運維方面的工作。
用<可測量信號>作爲需求工程過程的一部分來設定假設，必然會包括髮布和運維過程（可以這麼說，Dev + Ops = DevOps）。這樣，需求工程就包括了用戶行爲的證據，這是從項目邁向產品的一步。
其他與假設相關，有助於從項目過渡到產品的內容有：
- 由於假設覆蓋了要實現的業務成功標準，開發團隊會愈加傾向業務驅動，而不需要什麼項目了。
- 在使用<可測量信號>測量的<結果>的指導下，開發團隊運作時需要的管理參與也會更少。開發團隊可以自行發佈很多版本，而這以前需要分成許多獨立的項目。
- 有了<可測量信號>的數值，團隊當前的狀態就是透明的， <可測量信號>還能指導團隊在通往<結果>的道路上的決策過程。
啓動
確定了指標框架（Indicators Framework）後，我們很清楚，只有給團隊提供足夠的支持，把它引入擁有16支開發團隊的組織纔會產生效果。
爲了定義假設，我們擴展了業務功能（Business Feature）模板，以包括<功能>、<結果>和<可測量信號>字段。
我們和這些團隊舉辦了30至60分鐘長的小型工作研討會，在會上我們選擇一個團隊準備實現的需求，並把它轉換成假設。之後，當我們把該需求部署到生產中後，我們就與該團隊會面並評估<可測量信號>。
採用
我們把建議的指標框架引入一個組織，該組織擁有16支開發團隊，這些團隊在來自醫療領域的一項全球數字化服務“teamplay”上一起工作（更多關於“teamplay”的信息請參考西門子醫療的Adopting Continuous Delivery at teamplay）。這些團隊一開始就對假設非常感興趣。
對於這些團隊來說，掌握假設定義過程很容易。事實證明，功能假設定義期間的討論對進一步的需求工程（使用BDD）很有價值。很早就敲定功能的範圍是可行的。此時的假設定義創建了一個定義良好的邊界，稍後可以在其中創建詳細的用戶故事。
下圖是來自一個teamplay用戶管理（User Administration）的假設定義示例：
| 功能 | 結果 | 可測量信號 |
|---|---|---|
| 通過醫院管理部門啓用用戶邀請 | 管理員：能夠給上線的非管理員用戶適當的用戶權限 非管理員：能夠跳過註冊流程，並且只通過接受來自醫院管理部門的邀請就可以訪問應用程序 | 1.2020年每家醫院的平均用戶數量比2019年的增加30% 2.在2019年12月31日前註冊的醫院中，至少有10%在2020年至少使用一次用戶邀請功能 3.在2020年1月1日以後註冊的醫院中，至少有50%在2020年至少使用一次用戶邀請功能 4.醫院管理部門發出邀請到用戶接受邀請的時間間隔小於1周。 |
實施後，第一個可測量信號的值表明，功能的使用率增加到假設中指定的那個點需要一些時間。但是，來自銷售的定性反饋表明，使用用戶邀請獲得客戶註冊變得非常容易（意外的定性可測量信號）。根據這些反饋團隊可以看到，隨着時間的流逝，假設是否應該更改定義以反映由客戶所報告的功能可用性水平。
下圖是另一個來自teamplay數據訪問管理（Data Access Management）的假設示例：
| 功能 | 結果 | 可測量信號 |
|---|---|---|
| 按醫院位置和部門訪問數據 | 管理員：能夠讓用戶看到與其工作範圍相應的數據 非管理員：默認關注來自自己醫院部門的數據以簡化自己的工作 C級用戶：比較不同醫院部門之間的KPI | 1.至少有一半的醫院網絡啓用了數據訪問管理 2.在醫院網絡中，可以訪問所有數據的非管理員用戶的數量>0 |
可測量信號的實施因團隊而異。一些團隊在生產環境中實現了可測量信號。隨着團隊發佈頻率有計劃的增加，我們認爲，團隊將增加對可測量信號實施的採用。
關於假設，其中一支團隊有個有趣的經歷。在對一個功能進行假設定義後，該團隊開始實施。在實施過程中，他們嚴重受限於所用的外部框架。這些限制非常嚴重，以至於功能顯然無法按預期實施，因此，結果就無法實現。該團隊已經開始尋找另一個外部框架。
我們將很快引入“teamplay 服務標準”，這是一個簡短的列表，裏面有對我們很重要的服務主題。這裏有兩個主題與假設有關：“爲服務建立數據驅動的優先級”和“爲成功下定義，並朝着這個目標迭代”。這樣一來，我們將在組織內部進一步推進假設。
優先級
我們的團隊需要更多跟假設有關的經驗，以便始終如一地把手頭的數據作爲優先級的輸入。這些數據有不同的形式：
- 積極/消極測試的假設
- 來自可測量信號的意外見解
現在已經有了數據，需要開發團隊尤其是產品所有者考慮這些數據以做出關於最佳優先級的決策。優先級權衡如下：
- 對功能進行投資以提高產品效率和/或
- 對開發效率進行投資和/或
- 對服務可靠性進行投資
總結
綜上所述，如果團隊使用假設優化其產品管理過程，那麼，該團隊能夠通過數據驅動方式逐漸地優化其工作方式，因此隨着時間的流逝，團隊可以達到這麼一種狀態：他們構建的功能明顯在被用戶使用。
假設有助於去政治化，並使軟件交付組織的決策過程變得透明。最終，它支持組織驅動更好的業務結果，如提升用戶對軟件的使用率並獲得更高的收益。
本文是軟件產品交付組織數據驅動型決策系列文章的一部分。本系列文章對數據驅動型決策如何支持軟件交付中三個主要活動進行了概述，這三個主要活動是：產品管理、開發和運維。未來的文章將介紹開發、運維中的數據驅動型決策，以及產品管理、開發和運維中數據驅動型決策的組合。
致謝
感謝“teamplay”整個團隊導入並採用本文介紹的方法。
作者簡介：
Vladyslav Ukis先後畢業於德國Erlangen-Nuremberg大學以及英國曼徹斯特大學的計算機科學專業。他一畢業就加入西門子醫療，並一直致力於軟件架構、企業架構、創新管理、私有和公共雲計算、團隊管理和工程管理。最近幾年，他一直在西門子醫療數字生態系統平臺和應用（Siemens Healthineers Digital Ecosystem Platform and Applications）“teamplay”上推動持續交付和DevOps轉型。
原文鏈接：
Data-Driven Decision Making – Product Management with Hypotheses