本文要点：

用通俗易懂的语言来陈述产品猜想（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

创作场景

数据驱动型决策如何支持软件交付（一）：用假设进行产品管理