本文是《解析精益产品开发》系列的第二篇。在第一章中，我们介绍了看板方法，它帮助组织不断改进，实现平滑连续的价值流。但是，
只有基于正确价值的流程才有意义，这是精益产品开发的前提。在本章中，我们将揭示产品开发中价值的本质，并在此基础上，
分享适合精益产品开发的价值定义和发现实践——影响图。
1.产品开发中价值的本质
传统的项目治理强调价值的预定义、分解和评估，并基于此规划项目。
那么你就可以通过按计划执行来实现价值。这个概念在生产或建筑等工程项目中是有效的，但在产品开发中存在问题。以瀑布模式的软件开发为例，在项目的前部，
通常可以按计划进行，但为了满足进度要求，风险往往会向后转移；项目后期，风险和不确定性逐渐显现，项目难度大、工期延误；更重要的是，
如果交付的产品不符合客户或市场的要求，完美地满足计划是没有价值的。为什么工程项目中有用的方法在用于产品开发时会出现问题？原因是产品开发和工程项目中价值的本质是根本不同的。
1 .1信息是产品开发的价值载体，与不确定性齐头并进。
项目的产出(如生产或建筑)是一种物理产品，
价值是由实物产品承载的；产品开发的输出是方案，价值由方案中的信息承载。类比制作食物和制作食谱，产品开发相当于制作食谱，工程项目相当于按照食谱制作食物。做两份同样的食物，得到两份价值。两次制作同一个食谱不会产生两个价值，因为不会产生新的信息，价值无法讨论。不确定性与信息及其承载的价值密不可分。贝尔实验的伟大科学家香农首先使用了比特。
测量信息，奠定信息论基础。根据信息论，信息量是对事件不确定性的度量，表示为信息=一位包含0和1。
不确定性有两种——，一个字节包含256(0-255)种不确定性，其信息内容为8bits——。确定事件的信息内容为0.——。产品开发不可能消除所有的不确定性，保留任何价值。正如治理之父彼得德鲁克在他的经典著作《治理的实践》中所说：在所有关于未来的概念中，
会失败的是“绝对不失败”的概念，如“有保证”和“零风险”。
每一个产品的开发都必须与过去不同，这意味着不确定性和风险，也给产品注入了信息，带来了潜在的价值。汤姆德马科在《与熊共舞》
这本书把风险和不确定性比作熊，成功的产品开发是与熊共舞的艺术。第一代iPhone采用了——多点触控的全新操作界面和——大猩猩玻璃的全新材质。
和新的商业模式——运营商(ATT；)深度绑定，这些尝试带来了技术、生产和商业上的不确定性，同时也让产品获得了独特的体验和特殊的价值。在科技领域，
在产品和市场瞬息万变的今天，挑战不确定性和风险成为企业传递价值、获取竞争优势的必由之路。
1 .2与业务目标相关的信息可以带来价值。
信息承载着产品开发的价值，但它只是潜在的价值。只有实现业务目标，信息才能成为真正的价值，组织只有在能够帮助实现业务目标的地方才应该承担不确定性。想象一下，
如果苹果在第一代iPhone中尝试4G(LTE)通信技术，会带来更大的不确定性。然而，即使它成功了，也不会带来价值，因为当时没有与之匹配的商业用途。
LTE网络，其实第一代iPhone甚至没有支持当时流行的3G通信技术。与业务目标无关的不确定性不会带来价值，
而且可能是有害的。Google Wave刚推出时，受到了谷歌和用户的高度期待，产品一炮而红。然而，一年后，它宣布将停止开发，因为它未能吸引足够的用户。波浪
几乎所有能加的功能都加了，但用户并不买账。相反，功能太多导致界面复杂，定位模糊，缺乏稳定性，让用户远离Wave。
产品开发的目的是实现业务目标，而不是完成功能。产品的功能应该集中在有限而明确的业务目标上，否则一方面会造成范围扩散。
造成项目实施和产品保护的困境；另一方面，它无法实现核心目标。波浪
太多功能的引入是以牺牲易用性和稳定性为代价的，但用户还是普遍抱怨它不能满足自己的应用需求，什么都能做，但作为一个协作工具，还是比不上Google Doc或者。
Zoho作为社交工具，比不上脸书或者谷歌Buzz，作为交流工具，比不上Gmail或者现有的IM工具。斯科特
Berkun已经成功领导了微软的几个重大项目，包括浏览器战争的赢家InternetExplorer 4.0，以及它的畅销书《项目治理之美》。
他分享了一个曾经使用过的需求治理实践——，它使用简单的机制来跟踪从目标到功能再到产品项的映射关系。在这种机制下，每个工作项必须对应一个功能，
每个函数必须对应一个目标，每个版本只关注有限数量的目标。根据这个
一次摸底，团队就能明确确定新的工作。
项能否进入项目范畴。这既有效抑制了范畴蔓延，又确保了核心目标的达成。1 .3 价值要在开发过程中连续发觉
产品开发是一个信息积存和知识创建的过程， 团队连续获取业务需求、 市场环境、 实现技术等方面的信息， 深化认知、 明确价值。 近年来，
业界在如何让这一过程更加有效方面的实践取得了很大进展。
1 .3.1 先期决策是传统项目治理的通用实践
传统项目治理强调预先计划和按计划执行。如图 ㈠所示， 团队拥有最丰富信息和知识的时刻是在项目的末期， 这也是最可能做出正确决策的时刻。然而与之对应的是，
绝大部分的决策在项目的早期做出， 如设定产品需求、 承诺项目计划和确定技术方案等。此时的决策只能依据有限的信息和知识做出，
却成为后期项目执行的基准。过早的决策成为后来的约束， 也降低了应对变化的灵活性。
图㈠ 先期决策
1.3.2 ―延迟决策‖比―先期决策‖更符合产品开发的本质
灵敏和精益开发倡导―延迟决策‖。如图㈡所示，在迭代模式下，随着产品开发的进展，市场和技术环境发生变化，客户需求逐步清楚，成员对业务和技术的把握越来越全面深入。对应的，项目的决策也是分步做出的，项目启动阶段团队做出一些初始的决策，
更多的决策则发生在后续迭代中， 此时团队拥有更多的信息和知识， 更可能作出正确的决策。
图㈡ 延迟决策
在《The Principles of Product Development Flow》 一书中， Donald. Reinertsen
说：“产品开发成功的关键是：总是能依据最新的信息作出经济上正确的决策， 当信息变化时， 决策也要相应变化。”这就是延迟决策的意义所在。至于延迟到什么时间，
Mary Poppendieck的建议是―最后责任时刻（The Last Responsible Moment） ‖， 此时再不做决策，
将失去重要的决策选项， 或系统将自动挑选缺省方案（如不采取动作， 或沿用既有方式等)， 这往往也不是最优的决策。Donald. Reinertsen
的建议更加实际：―进一步的等待不能提高预期的经济结果时， 就是应该做出决策的时刻了‖。采用谁的建议并不重要， 重要的是懂得延迟决策在经济上的意义，
和创造延迟决策的可能性。
1.3.3 ―延迟决策‖还不够， ―刻意发觉‖提高发觉过程的有效性
在图 ㈠和图 ㈡中， 信息积存和知识发觉的过程被表示为一条直的斜线， 这是一种简化表示。而在现实中， 这一过程是非线性的。如图 ㈢右边的线， 缺省情形下，
知识发觉更多集中于项目后期， 因为此时得到的反馈信息更加真实。我们称这种未经刻意计划的过程为―随意发觉（Accidental Discovery）
‖。随意发觉是相对无效的， 因为越是后期的信息和知识越难转化为真正价值， 毕竟在项目后期做出调整是很困难， 且成本庞大的。
图㈢ 刻意发觉
对应随意发觉，Dan North 提出了刻意发觉（Deliberate
Discovery）。他指出项目初期，团队缺乏业务领域、构建技术、遗留代码、工具等方面的知识，处于对项目最无知的状态。无知是产品开发的最大制约因素，这其中也包含对无知的无知，也就是不知道缺乏知识或不知道缺乏什么知识。有意思的是，对于无知的无知往往让团队更加乐观而非更加谨慎，所谓―无知者无畏‖。被动的、基于已有知识的延迟决策是不够的。团队应该在开发过程中通过有计划的活动，刻意地探索发觉，最快和最大化的发觉知识、排除无知，其中也包括排除对无知的无知，也就是尽快发觉我们还缺乏哪些方面的知识。这一过程被称为―刻意发觉‖，
它增加并提早了软件开发的知识创建。如图 ㈢所示， 相比随意发觉， 刻意发觉把发觉的过程拉向坐标的左上方，更早和更有效地发觉知识。
项目早期的快速原型、技术探索、最小产品发布等都属于刻意发觉的实践， 它们通过有目的探索活动，更早的积存知识，有力的支持了项目在执行、技术以及商务上的成功。
1.3.4 ―经证实的认知‖把―刻意发觉‖推向极致
―经证实的认知‖源自近年来兴起的―精益创业‖理念，它把―刻意发觉‖过程推到了极致。《精益创业》 一书的作者 Eric Ries
把创业定义为：―在极端不确定的情形下开发新产品和新服务‖，在移动互联的今天， 这越来越成为产品开发的常态，
不管是新创企业或是成熟企业的产品开发部门都是如此。Eric
认为学习是创业的重要部分，而最有效的学习必须是以从客户那里收集到的真实数据为基础的，并把这种学习称为―经证实的认知‖。―精益创业‖提倡先向市场推出极简的原型产品，
然后在不断地试验和学习中， 以最小的成本和有效的方式验证产品是否符合用户需求， 并灵活调整方向。
―经证实的认知‖的核心是开发（build）->测量（measure）->认知（learn） 的循环。如图
㈣，循环从概念开始，它往往是基于对市场、客户和技术的假设，我们并不完全确信它是可行的，能解决客户问题，并为市场所接受。在这一循环中，第一步是开发验证概念的最小产品；第二步：基于最小产品获取市场、用户的反馈和测量数据；第三步：用数据验证假设，深化认知和建立新的概念。再进入下一循环，不断构建、优化产品及对其的认知。
图㈣ 经证实的认知
―经证实的认知‖的执行过程是一个循环（图中的外圈），计划过程是另一循环（图中的内圈），它与执行的循环方向正好相反。也就是，第一步：确定要验证什么样的概念；第二步：规划需要获取什么数据来验证概念；第三步：决定通过构建什么最小产品来获得这些数据。这两个相反方向的循环共同构成了―体会证的认知‖的完整实践。
今天，云运算和产品服务化让产品发布模式发生了深刻变化，快速获取反馈和验证概念越来越方便，好的产品不会依靠于初始时一两个好创意。以用户为中心，快速有效地学习，不断调整和完善产品和服务成为产品开发的核心竞争力。―精益创业‖的理念和实践在产品开发中被广泛实践，大到微信、微博这样的平台，小到各类细分应用，甚至硬件产品，都会通过连续发布产品，
获取用户反馈，不断调整方向， 更好的解决用户核心问题， 优化产品功能。―体会证的认知‖为这一过程提供了理论依据和实践指导。
2\. 一个价值定义的实践方法——影响地图（Impact Mapping）
以上我们探讨了产品开发中的价值本质 1 ） 信息是产品开发的价值载体， 不确定性为产品开发注入信息， 带来潜在价值。2）
服务于商业目标的信息才能成为最终价值 3） 价值要在开发过程中连续发觉， 延迟决策、 刻意发觉和体会证的认知让这一过程变得更有效。―不确定性‖、
―服务于商业目标‖和―连续发觉‖是关于产品开发价值的三个关键词。对产品开发价值本质的认知是基础，
但只有把它们应用到实践中才有意义。下面将要介绍的―影响地图‖就是一个从产品开发本质出发的价值定义和价值发觉的实践。
2.1 影响地图解决的问题是什么？
产品开发的任务是通过交付功能（或服务）达成商业目标， 通常在组织中这意味着两个职能，一部分人关注业务——客户需求和产品目标；一部分人关注开发——用什么技术，
怎样实现。为此产品开发一直要面对两个挑战：
1 ） 业务职能和开发职能之间的懂得、 沟通和协作的隔阂
2） 产品功能和业务目标之间的不一致以及关联的模糊
图㈤ 影响地图要解决的问题
如图 ㈤所示， 影响地图要解决的正是上述两个挑战。
2.2 影响地图是什么？
影响地图是 Gojko Adzic 总结和提炼自己及他人的实践后提出的，旨在帮助组织更好地创建和沟通产品路线图和计划，确保功能交付和业务目标的一致，
并提高应对变化的灵活性。
2.2.1 影响地图可视化了从业务目标到产品功能的映射关系
产品是为人服务的， 必须通过影响人的行为才能实现目 标， 这也是―影响地图‖名称的由来。
为完成从目标到功能的映射， 影响地图要回答两个问题：
1 ） 对什么人产生什么样的影响可以帮助目标的实现
2） 提供什么样的产品功能（或服务）才能产生这样的影响
图 ㈥是一个影响地图的实例，它面向的业务目 标是―6 个月 内，不增加客服人数的前提下，支持两倍的用户数‖，以业务目标为核心，影响地图分为 4 个层次。
图㈥ 影响地图实例 1
第一层：目标（why） ， 也就是要实现的业务目标或要解决客户的核心问题是什么。目标应该具体、 清楚和可衡量。
第二层：角色（who） ， 也就是可以通过影响谁的行为来实现目标， 或排除实现目标的阻碍。角色通常包含 1 ）主要用户，如产品的直接使用者 ；2）
次要用户， 如安装和保护人员；3）产品关系人，也就是虽然不使用产品但会被产品影响或影响产品的人，如采购的决策者，竞争对手等。
第三层：影响（how） ，也就是怎样影响角色的行为， 来达成目标。这里既包含产生促进目标实现的正面行为， 也包含排除阻碍目标实现的负面行为。
第四层：功能（what），也就是要交付什么产品功能或服务产生期望的影响。它决定了产品的范畴。
2.2.2 影响地图显式化了从目标到功能映射背后的假设如图 ㈥， 上述的映射关系中， 事实上是基于两类假设的。
1 ） 功能假设：假设通过设想的功能能对角色产生期望的影响
2） 影响假设：假设对角色产生这样的影响会促进目标的实现
例如，我们假设：对常见的问题提供论坛链接，可以引导用户更多的上论坛。同时还假设：如果用户更多的上论坛就能减轻客服的工作负载，从而服务更多的用户。在功能交付之前，这些假设还只是待验证的概念。影响地图把这些假设显式化出来，帮助组织有意识地验证和修正这些概念，这与―精益创业‖的理念是一致的。让假设显式化是―影响地图‖的重要方面，Mary
Poppendieck 在―Impact Mapping‖一书的序中说：“影响地图是由连接原因（产品功能） 和结果（产品目标） 之间的假设构成的，
它帮助组织找到正确的问题， 而这比找到好的答案要重要的多”。
2.2.3 影响地图提供了一个共享、 动态和整体的图景
影响地图不应该专属于某个职能，也不应该是某一时刻的静态规划。开发过程中， 团队连续交付功能， 获得反馈及其它信息输入， 深化对产品的认知。随着认知的深化，
影响地图不断地被修正、 拓展。这一过程需要各个职能的共同参与， 影响地图是治理人员、 业务人员、 开发和测试人员共享的完整图景。对于业务人员，
他们不再是简单的把需求列表扔给开发团队， 并等着最后的结果。通过影响地图， 业务人员和开发人员一同完成从目标到产品功能的映射， 明确其中的假设，
并在迭代交付中验证这些假设， 当假设被证明或否定后， 应该对影响地图做出调整， 如连续加强或停止在某个方向上的投入， 或调整投入的方式。对于开发人员，
他们的目标不再限定于交付功能， 而是拓展至交付业务目标。开发者除了知道交付什么功能， 也了解为谁开发， 为什么要开发。这样就可以更加主动和创新地摸索，
有依据的做出决策和调整。
对于测试人员， 除了参与上面的规划和验证活动外， 测试的责任不再局限于检查产品是否符预定的功能，
而是验证产品是否产生了预期的影响。如果没有对用户产生期望的影响， 即便完美符合功能定义， 也不是高质量的产品。
2.3 一个影响地图案例
下面我们用一个案例来展现影响地图的使用。设想一个团队正在开发一个跨平台知识治理应
用， 它主要面向个人用户， 但也有人把它用到企业的知识治理中。该应用缺省模式下是免费
的， 对收费用户提供额外的功能和服务。
2.3.1 完成影响地图的初始版本
该产品团队在未来三个月 内有多个目标， 其中比较重要的是―增加付费用户的比例‖。我们就以这个目标为例来应用影响地图。
第一步：完成影响地图的第一层次——目 标。―增加付费用户的比例‖作为目 标还不够明确，经过论证调整为：―三个月 内付费用户比例从 1 %增加到 1.5%‖，
它更具体并且加上了明确的时间限制。但我们还是要问：―为什么要增加这 0.5 个百分点？‖， 发觉更深层的目标是增加收入， 而不是收费用户比例，
否则通过减少用户数量也可以实现比例增加。最后目标确定为：―三个月 内付费用户人数从 820 增加到 1 500 人以上‖， 它足够明确， 并且是可以度量的。
第二步， 第三步：完成影响地图中的第 2 和第 3 层次——角色和影响， 也就是考虑通过影响谁有助于这一目标的实现， 以及怎么影响。例如：影响已付费用户，
鼓励和促使他们积极的宣传所获得的便利， 可能会吸引更多的潜在付费用户；影响现有免费用户， 让他们意识到收费服务的价值，
也可能会争取到更多的收费用户；企业用户也是一个可挖掘的资源， 只不过团队对这方面的体会还非常有限， 不确信要从哪些方面着手。但这没有关系，
我们可以做出一些初始的假设， 并在后续过程中加以检验和完善。
第四步：完成影响地图的第 4 层次——功能， 也就是交付什么样的产品功能或服务来实现期望的影响。需要指出的是，
并不是所有的影响都要通过开发产品功能才能实现， 比如在这个例子中， 为了让企业用户更方便地支付，
最容易和最急迫的是为企业用户开具财务发票，它不涉及到任何开发工作。开始去做影响地图时， 往往会发觉这种情形所占比例比想象的高很多。这是好事，
毕竟我们要交付的是目标而不是功能。
图㈦ 影响地图实例 2
如图 ㈦， 经过上面四步， 我们完成了影响地图的初始版本。它由各职能共同完成， 或者由某个职能完成， 再由大家共同讨论、 精化，
团队会挑战影响地图中的元素和假设， 但不需要纠结于每一个细节， 它毕竟是基于对产品、 市场、 客户以及技术， 甚至是竞争对手的假设，不可能达成 1
00%的一致。影响地图让这些假设可视地出现出来， 团队将在开发和交付过程中不断验证这些假设， 并做出新的假设， 演化影响地图。
2.3.2 规划路线图和计划
一个产品可能会存在多个相关或细分的目标， 需要多个影响地图。即便如此， 还是应该尽可能限定同时进行的目标的数量， 在上一篇文章讨论看板时，
我们知道限制在制品数量是看板的最核心实践。而限制同时进行的目标的数量， 比限制同时开发的功能数量更重要和有效，它保证团队的工作最快地影响到业务，
得到真实反馈。―保持专心， 连续发布‖正在成为产品开发团队的追求， 或许 Facebook CEO 扎克伯格的办公桌面上的招贴―stay focused &
keepshipping ‖能给我们一些启示， 照片是扎克伯格在 Facebook 提交 IPO 申请当天上传至自己的 Facebook 页面的。
图 ㈧ 扎克伯格的办公桌面照片
有了一个或多个影响地图， 就可以开始制定产品路标和开发计划了。例如， 在图 ㈦中我们挑选了一些高优先级的功能（打钩的项） ， 作为接下来要完成和发布的内容，
期望通过它们最快地接近业务目标， 并验证重要假设， 扫除实现目标的不确定性。这是一个最简单的里程碑和发布规划，
当然我们也可以做更长远一些的规划。开始规划前我们第一要知道：
1 )） 我们的目标不是实现整张影响地图， 而是要根据地图找到实现业务目标的最短路径。
2） 通过影响角色才能实现目标， 所以第一考虑要交付哪些影响， 先在影响层面确定优先级，然后才是具体功能。以此为基础，
下面是一些可供参考的产品规划和优先级确定实践：
1 ） 先挑选容易实现却可以带来明显成效的功能
2） 挑选可以验证重要假设和不确定性的功能
3） 挑选能排除重大负面影响和阻碍因素的功能
4） 考虑先集中力对最重要的角色产生影响
5） 对于特别不确定的分支， 考虑先用最小的投入探索后， 再做进一步规划
6） 注视挑选的功能集，它们应该构成一个可发布，且能完成影响的最小产品
在实际应用过程中， 实践者们还需要去修订、 完善和发展自己的操作实践。
2.3.3 开发->测量->认知的循环
上例中， 我们从业务目标出发， 应用影响地图完成从业务目标到产品功能的动态映射， 为各个职能的沟通协作提供了统一的依据。我们还以此基础上，
规划产品的路线图和发布计划。这只是起点， 更重要的是在整个产品开发过程中， 不断检验影响地图中的概念和假设， 调整完善影响地图和基于它的发布路线图。
在产品开发和交付过程中， 我们会确认或否定影响地图中的假设， 决定加强或停止在某一分支上的投入；通过发布产品，
我们还可能取得不包含在影响地图中的意外的结果， 我们应该重视这些意外， 特别是意外的成功， 挖掘新的机会和概念；通过不断的反馈，
深化对产品及其周边因素的认知， 完善影响地图， 调整产品里程碑计划， 完善产品和服务，
动态地实现业务目标。这个过程实际上就是―精益创业‖中的开发->测量->认知的循环， 也是―精益创业‖最核心的部分。
Gojko Adzic 写了一本小书―Impact Mapping‖详细介绍了影响地图的概念和实践。Jojko
的上一本畅销书，《实例化需求》推动了―实例化需求‖在软件产品开发中的推广和普及，并因此获得 201 2 年的 Jolt
最佳图书大奖。对于―影响地图‖，Gojko期望它会根本改变组织构建产品和交付项目的方法。影响地图体现和涵盖了近年来产品开发领域多个重要趋势，包括面向目标的需求工程、迭代和连续交付、精益方法、精益创业、设计思维（Design
Thinking）
等。在实践中它简单有效， 是相对概念化的―精益创业‖和―设计思维‖的落地实践。
3\. 总结
提升有效交付价值的能力是精益产品开发的根本任务。―不确定性‖、
―服务于商业目标‖和―连续发觉‖是体现产品开发的价值本质的三个关键词。―影响地图‖很好地把握了这些本质， 它以商业目标为起点， 拥抱产品开发的不确定性，
结构化地出现假设和治理不确定性， 通过―开发->测量->认知‖循环连续发觉和构建产品的价值。在了解产品开发的价值本质及相关实践的基础上，
下一篇中我们将讨论面向价值的端到端的可视化， 我们还会讨论影响地图之外的其它实践， 并系统整合它们， 为更全面的解析精益产品开发奠定基础。
