解析精益产品开发（二）—— 产品开发中的价值

本文是《解析精益产品开发》系列的第二篇。 第一篇中我们介绍了看板方法，看板方法帮助组织持续改进，实现顺畅和持续的价值流动。但是，只有基于正确价值的流动才有意义，这是精益产品开发的前提。在本篇中，我们将揭示产品开发中的价值本质，并以此为基础，分享一个适合精益产品开发的价值定义和发现实践——影响地图（Impact Mapping）。

1. 产品开发中价值的本质

传统项目管理强调预先定义、分解和估计价值，以此为基础计划项目，然后按计划执行就可以实现价值。这一理念应用在诸如生产或建筑之类的工程项目上是有效的，但应用在产品开发上时就有问题。以瀑布模式下的软件开发为例，在项目前段，通常能够按计划进行，但为了满足进度要求，往往会让风险后移；在项目后段，风险和不确定性逐渐显现，项目出现困难和延期；更有甚者，如果交付的产品不符合客户或市场的要求，再完美地符合计划也是没有价值的。为什么在工程项目中有用的方法用在产品开发中就会出现问题？其原因是产品开发和工程项目中价值的本质是根本不同的。

1.1 信息是产品开发的价值载体，它与不确定性如影随形

工程项目（如生产或建筑）的产出是物理产品，价值由物理产品承载；产品开发的产出是方案，价值由方案中的信息承载。以“制作食品”和“制作食谱”来类比，产品开发相当于制作食谱，工程项目则相当于按食谱制作食品。制作两份同样的食品，得到两份价值。而制作两遍同样的食谱，不会产生两份价值，因为它没有产出新的信息，价值也无从谈起。

不确定性与信息及其承载的价值如影随形。贝尔实验的伟大科学家香农（Shannon）最早用比特（bit）来度量信息，并奠定了信息理论的基石。按信息理论，信息的量是对事件不确定性的衡量，表达为information = 。一个bit包含了0和1两种不确定性—— ，而1个byte包含256（0-255）种不确定性，其信息量为8bits—— 。确定事件的信息量为0 —— 。产品开发不可能排除所有的不确定性还保留任何价值。正如管理学之父彼得•德鲁克在其经典著作《管理的实践》中所述：

在所有关于未来的概念中，一定会失败的就是那些“十拿九稳”、“零风险”等“绝对不会失败”的概念。

每一次产品开发都必须与过去有所不同，这意味着不确定性和风险，也为产品注入信息，带来潜在价值。Tom Demarco 在《与熊共舞》一书中把风险和不确定性比作熊，成功的产品开发是“与熊共舞”的艺术。第一代iPhone采用了全新操作界面——多点触控、全新材料——大猩猩玻璃材质，和全新商业模式——运营商（AT&T）深度绑定，这些尝试带来了技术、生产和商务上的不确定性， 同时也成就了产品与众不同的体验和非凡的价值。在技术、产品和市场快速变革的今天， 挑战不确定性和风险已经成为企业交付价值获得竞争优势的不二法门。

1.2 和商业目标相关的信息才能带来价值

信息承载产品开发的价值，但只是潜在价值。只有通过达成商业目标，信息才能成为真正的价值，组织也只应该在能帮助达成商业目标的地方承担不确定性。设想，苹果如果在第一代iPhone中尝试4G（LTE）通信技术，会带来更大的不确定性，然而即使成功了，也不能带来价值，因为当时还没有与之配套的商用LTE网络，事实上，第一代iPhone甚至没有支持当时已经流行的3G通信技术。

与商业目标无关的不确定性不带来价值，而且可能是有害的。Google Wave刚推出时被Google和用户寄予了厚望，产品红极一时，但一年后却因未能吸引到足够用户而宣布停止开发。Wave几乎加入了能够添加的所有功能，但用户并不买账，相反，过多的功能导致复杂的界面、模糊的定位和稳定性的缺乏，让用户远离Wave。

产品开发的目的是实现商业目标，而非完成功能。产品的功能应该围绕有限和明确的商业目标展开，否则一方面会引发范围蔓延，造成项目执行和产品维护的困局；另一方面却无法实现核心目标。Wave引入过多的功能而牺牲了易用性和稳定性，但用户还是普遍的抱怨，它不能满足自己的应用要求，它什么都能做，但作为协作工具它比不上Google Doc或Zoho，作为社交工具它比不上Facebook或Google Buzz，作为通信工具它比不上Gmail或已有的IM工具。

Scott Berkun曾经成功领导微软数个重大项目，包括奠定浏览器大战胜局的Internet Explorer 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增加到1500人以上”，它足够明确，并且是可以度量的。

第二步，第三步：完成影响地图中的第2和第3层次——角色和影响，也就是考虑通过影响谁有助于这一目标的实现，以及怎么影响。例如：影响已付费用户，鼓励和促使他们积极的宣传所获得的便利，可能会吸引更多的潜在付费用户；影响现有免费用户，让他们意识到收费服务的价值，也可能会争取到更多的收费用户；企业用户也是一个可挖掘的资源，只不过团队对这方面的经验还非常有限，不确信要从哪些方面着手。但这没有关系，我们可以做出一些初始的假设，并在后续过程中加以检验和完善。

第四步：完成影响地图的第4层次——功能，也就是交付什么样的产品功能或服务来实现期望的影响。需要指出的是，并不是所有的影响都要通过开发产品功能才能实现，比如在这个例子中，为了让企业用户更方便地支付，最容易和最急迫的是为企业用户开具财务发票，它不涉及到任何开发工作。开始去做影响地图时，往往会发现这种情况所占比例比想象的高很多。这是好事，毕竟我们要交付的是目标而不是功能。

图㈦ 影响地图实例2

如图 ㈦，经过上面四步，我们完成了影响地图的初始版本。它由各职能共同完成，或者由某个职能完成，再由大家共同讨论、精化，团队会挑战影响地图中的元素和假设，但不需要纠结于每一个细节，它毕竟是基于对产品、市场、客户以及技术，甚至是竞争对手的假设，不可能达成100%的一致。影响地图让这些假设可视地呈现出来，团队将在开发和交付过程中不断验证这些假设，并做出新的假设，演化影响地图。

2.3.2 规划路线图和计划

一个产品可能会存在多个相关或细分的目标，需要多个影响地图。即便如此，还是应该尽可能限定同时进行的目标的数量，在 上一篇文章讨论看板时，我们知道限制在制品数量是看板的最核心实践。而限制同时进行的目标的数量，比限制同时开发的功能数量更重要和有效，它保证团队的工作最快地影响到业务，得到真实反馈。“ 保持专注，持续发布”正在成为产品开发团队的追求，或许Facebook CEO 扎克伯格的办公桌面上的招贴“stay focused & keep shipping ”能给我们一些启示，照片是扎克伯格在Facebook 提交IPO申请当天上传至自己的Facebook页面的。

图 ㈧ 扎克伯格的办公桌面照片

有了一个或多个影响地图，就可以开始制定产品路标和开发计划了。例如，在图 ㈦中我们选择了一些高优先级的功能（打钩的项），作为接下来要完成和发布的内容，希望通过它们最快地接近业务目标，并验证重要假设，扫除实现目标的不确定性。这是一个最简单的里程碑和发布规划，当然我们也可以做更长远一些的规划。开始规划前我们首先要知道：

1) ）我们的目标不是实现整张影响地图，而是要根据地图找到实现业务目标的最短路径。

2）通过影响角色才能实现目标，所以首先考虑要交付哪些影响，先在影响层面确定优先级，然后才是具体功能。

以此为基础，下面是一些可供参考的产品规划和优先级确定实践：

1） 先选择容易实现却可以带来明显效果的功能

2） 选择可以验证重要假设和不确定性的功能

3） 选择能消除重大负面影响和阻碍因素的功能

4） 考虑先集中力对最重要的角色产生影响

5） 对于特别不确定的分支，考虑先用最小的投入探索后，再做进一步规划

6） 审视选择的功能集，它们应该构成一个可发布，且能完成影响的最小产品

在实际应用过程中，实践者们还需要去修订、完善和发展自己的操作实践。

2.3.3 开发->测量->认知的循环

上例中，我们从业务目标出发，应用影响地图完成从业务目标到产品功能的动态映射，为各个职能的沟通协作提供了统一的依据。我们还以此基础上，规划产品的路线图和发布计划。这只是起点，更重要的是在整个产品开发过程中，不断检验影响地图中的概念和假设，调整完善影响地图和基于它的发布路线图。

在产品开发和交付过程中，我们会确认或否定影响地图中的假设，决定加强或停止在某一分支上的投入；通过发布产品，我们还可能取得不包含在影响地图中的意外的结果，我们应该重视这些意外，特别是意外的成功，发掘新的机会和概念；通过不断的反馈，深化对产品及其周边因素的认知，完善影响地图，调整产品里程碑计划，完善产品和服务，动态地实现业务目标。这个过程实际上就是“精益创业”中的开发->测量->认知的循环，也是“精益创业”最核心的部分。

Gojko Adzic写了一本小书“Impact Mapping”详细介绍了影响地图的概念和实践。Jojko的上一本畅销书，《实例化需求》推动了“实例化需求”在软件产品开发中的推广和普及，并因此获得2012年的Jolt 最佳图书大奖。对于“影响地图”，Gojko希望它会根本改变组织构建产品和交付项目的方法。影响地图体现和涵盖了近年来产品开发领域多个重要趋势，包括面向目标的需求工程、迭代和持续交付、精益方法、精益创业、设计思维（Design Thinking）等。在实践中它简单有效，是相对概念化的“精益创业”和“设计思维”的落地实践。

3. 总结

提升有效交付价值的能力是精益产品开发的根本任务。 “不确定性”、“服务于商业目标”和“持续发现”是体现产品开发的价值本质的三个关键词。“影响地图”很好地把握了这些本质，它以商业目标为起点，拥抱产品开发的不确定性，结构化地呈现假设和管理不确定性，通过“开发->测量->认知”循环持续发现和构建产品的价值。

在了解产品开发的价值本质及相关实践的基础上，下一篇中我们将讨论面向价值的端到端的可视化，我们还会讨论影响地图之外的其它实践，并系统整合它们，为更全面的解析精益产品开发奠定基础。

来源：InfoQ中文站；作者： 何勉

本文链接《 解析精益产品开发（二）—— 产品开发中的价值》
官方微信：woshipm，干货天天推荐，欢迎订阅