（一）看板开发方法

看板（Kanban）开发方法是近年来最热门的敏捷和精益开发方法。越来越多的案例表明，它能够改善协作、优化管理，显著提高交付速度、质量和灵活性。看板开发方法的规则简单，但其有效实施依赖于对原理的理解、对原则的坚持和实践的应变。本文将整体介绍看板的原理、原则和基本实践。

1. 看板的原始含义

看板源自精益制造。尽管具体实践不同，看板开发方法和精益制造中的看板原理是一致的。从精益制造出发，可以帮助我们更好地理解看板的本质。

1.1 看板源自精益制造

精益制造是上世纪50年代起，从丰田公司实践中演化出来的，又被称为“丰田生产方式”。1990年麻省理工的James P. Womack等几位教授提炼总结了丰田的实践，出版《精益生产方式——改变世界的机器》一书，精益制造的概念开始为世人所认识和效仿，直至今日，它仍然是最先进的制造方式，是制造业共同追求的目标。

丰田生产方式之父，大野耐一说：“丰田生产方式的两大支柱是‘准时化’和‘自働化’，看板是运营这一系统的工具”。看板是丰田生产方式的核心工具（如图 ㈠）。

图 ㈠ 丰田屋——丰田生产方式

看板（Kanban）一词来自日文，本义是可视化卡片。如 图 ㈡，看板工具的实质是：后道工序在需要时，通过看板向前道工序发出信号——请给我需要数量的输入，前道工序只有得到看板后，才按需生产。看板信号由下游向上游传递，拉动上游的生产活动，使产品向下游流动。拉动的源头是最下游的客户价值，也就是客户订单或需求。

图 ㈡ 看板拉动制造过程

图 ㈢ 是一个典型的看板——装在塑料套里的一枚卡片，包含的信息是“什么地方，需要什么产品，多少数量

图 ㈢ 生产中的看板

1.2 基于看板的拉动系统实现准时化

准时化又叫即时生产（Just in time - JIT）是丰田生产方式的一个支柱。看板形成拉动系统，各环节根据看板信息，仅在在需要的时间，生产需要数量的必要产品。这将带来生产库存的降低，甚至实现生产过程零库存。库存又被称为“在制品（WIP ——work in progress）”，是已经开始但没有完成的工作，它们堆积在工序间或临时仓库中。库存降低带来的直接收益是：

1) 降低成本：库存减少增加了运营现金的使用率，同时降低管理和仓储开销。

2) 缩短交付周期：消除或缩短产品在工序间的库存等待时间，缩短了从开始制造到交付的周期时间。

3) 提高制造过程的灵活性：在低库存水平下，调整生产的计划更加容易。

降低库存更重要的作用是暴露制造系统中的问题。图 ㈣中的湖水岩石是一个经典隐喻，水位代表库存多少，岩石代表问题。水位高，岩石就会被隐藏。生产系统中库存多时，设备不良、停工等待、质量不佳、瓶颈过载等问题都会被掩盖。库存降低后，这些问题都会显现出来。没有了临时库存的缓冲，设备运转不良或停工等待立即会凸显出来；没有了库存等待时间，上一环节输出的质量问题也能即时得到反馈。这就是所谓“水落石出”，暴露问题是解决问题先决条件，不断暴露和解决问题，带来生产率、质量以及灵活性的提高。

图 ㈣ 湖水岩石效应

1.3 自働化

自働化是丰田生产方式的另一支柱，它的准确含义是自动停机（Auto-No-Mation），指出现问题时（如某个环节有次品），机器能够自动感知异常，并立刻停机或停下整个生产线。丰田认为，这相当于把人的智慧赋予了机器，称其为“人字旁的自动化”，所以用“働”而非 “动”字。图（三）比较了自动化与自働化在概念和实践上的不同。

图 ㈤ 自动化和自働化

自働化把质量内建于每一个制造环节，出现异常时，杜绝继续产出不合格产品，并且不把不合格产品输入到下一环节。这就是 “内建质量”（build quality in），而不是让质量依赖于最后的检测环节。

其次，自働化带来“停止并修正”（Stop and Fix）的文化，发生异常时，立刻停止生产，分析根本原因，并加以解决，防止问题的再次发生。“停止并修正”是持续改善的基础。

2. 精益产品开发的发展

以上我们简要介绍了精益制造（丰田生产方式）的框架和其中的看板实践，它既带来直接经济结果，又带来深层次的文化和思想变革。精益是制造业的革命，是既大规模生产之后的全新范式。精益思想的影响早已超越制造领域，精益服务、精益医疗，甚至精益行政都被广泛实践，产品开发也不例外。然而，开发和制造特点不同，决定无法照搬精益制造的实践。产品开发需要从自身特点出发，发展完备的实践体系。

精益产品开发概念出现于上世纪90年代，2000年后逐步成熟。这中间起到推动作用的代表人物有Mary Poppendieck，Don Reinertsen 和 David J. Anderson等。他们促进了精益思想和产品开发特征的结合。

Mary Poppendieck是精益软件开发的早期推动者，她的思想在敏捷软件开发社区被广泛引用，2003年到2010年，Mary和他的丈夫 Tom Poppendieck先后在三本书中总结了这些思想，并提出了操作建议。Don Reinertsen致力揭示产品开发流的本质，并提出相匹配的原则方法。在2010年出版的“The Principles of Product Development Flow”一书中，Don提炼了精益产品开发的175条原则，这可能是迄今为止对产品开发最本质和深入全面的阐述。但面对175条原则，从哪里开始是一个问题。

2006年在Don Reinertsen的启发和鼓励下，David J. Anderson 最早在软件开发中应用看板实践，其后不断完善，形成了看板开发方法，这是精益产品开发走向适用和普及的重要里程碑。看板的推广速度超过任何其它敏捷开发方法，Version one的调查报告显示看板是增长最快的敏捷实践，2011年使用了看板的敏捷团队占24%，2010年这个数据是18%。

2010年David在他的著作”kanban – Successful Evolutionary Change for Your Technology Business”一书中，详细介绍了看板的价值、原则和实践。书中总结了看板开发方法的五个核心实践，它们是：可视化工作流、过程规则显式化、限制在制品数量、度量和管理流动、以及协同改进。接下来，我们将以这五个实践为线索，介绍看板开发方法的概貌。

3. 看板的五个核心实践

3.1 核心实践1：可视化工作（价值）流

产品开发的加工对象——信息——是抽象和不可见的，这提高了价值流的管理难度。看板开发方法把可视化工作流作为基础实践，先让价值和价值流动具体可见，然后才是管理和优化。图 ㈥是看板开发方法中的一个典型可视化案例，被称为看板墙（Kanban wall）。

图 ㈥ 可视化工作流

图中的每个卡片代表一个价值项，如：功能需求、缺陷、技术概念验证等。它们所在的列，表示其所处的阶段。这些价值项，每经过一个阶段（图中的列）都会产生新信息，价值得以增加。例如，需求经过分析阶段，注入了新信息，价值更高。价值流是价值项从左至右的流动过程，是信息的产出过程，也是价值增加的过程。

价值流动可能会被阻碍。比如，编码因对第三方接口错误而无法进展；测试因没有设备而停滞。图中，红色卡片是对问题和阻碍因素的可视化。标识阻碍因素并推动其解决，促进价值流动。

最终限制系统端到端流量的是系统瓶颈处的流量，改善端到端的价值流，必须从解决瓶颈问题开始。发现看板墙上的瓶颈并不困难，找到最长的队列就可以了，这就和交通系统的瓶颈处，总是出现长长的等待车队是一个道理。上图中的队列出现在测试处，不难看出，测试是价值流动的瓶颈。

价值、价值流，以及问题和瓶颈的可视化，是改善价值的起始，也是其它看板实践的基础。

3.2 核心实践2：显式化流程规则

显式化流程规则，是指明确定义和沟通团队所遵循的流程规则。价值项的“流转规则”是看板开发方法中最典型流程规则，它定义了一个价值项从一个阶段进入下一阶段所必须达到的标准。图 ㈦中，给出了某团队其中一项流转规则的实例，定义了从分析阶段进入开发阶段所必须达到的条件。

“流转规则”的显式化，让质量内建于各个阶段——这与精益制造中内建质量的思想是一致的。除各个“流转规则”外，其它重要的流程规则也可以或者需要被显式化，如，团队的协作规则、优先级的定义规则等。

图 ㈦ 显程化流程规则

流程规则显式化更重要的意义在于，它是“持续改进”的出发点和结果的载体。没有显式化的规则作为依据，讨论改进就没有基础，而变得主观和随意。改进的结果通常也需要落实到显式的流程规则当中，让改进稳步进行，避免低效的反复。显式化规则不是为了限定团队的工作方式，而是为了帮助团队更好的改进。这就像，丰田的生产现场必须有明确操作规程，但如果这个操作过程长时间没有变化也同样是一个问题，因为，持续改进是精益思想的核心之一。

3.3 核心实践3：限制在制品数量

限制在制品数量是看板开发方法的核心机制。如 图 ㈧所示，列标题右面的数字标识了该阶段允许的在制品的最大数目（进行中和完成的价值项的和）。在制品数目小于这个数字时，才可以从前一阶段拉入新的工作。图中，分析阶段的在制品限制数目是3，而实际在制品数目是2，可以拉入新的工作。测试阶段的在制品数是3，达到了上限，就不允许拉入新工作。

图 ㈧ 限制在制品数目

限制在制品数量形成一个与精益制造类似的拉动机制。一个环节有空余的能力（在制品数目未达上限）时，从上游拉入新的工作，拉动的源头是最下游的交付或客户需求。与产品制造类似，通过拉动系统可以：

1) 加速价值流动：限制在制品数量，减少了价值项在阶段间的排队等待，缩短了价值从进入系统到交付的时间，加速了端到端的价值流动。

2) 暴露问题：限制在制品数量，让湖水岩石效应产生作用。它让过去被隐藏的问题，如团队协作不良、需求定义错误、开发环境低效、资源分配不均衡等得以显现。

许多号称使用“看板”的团队，并没有限制在制品数量，他们当然也不会得到上述收益。精益制造通过看板向上游传信号，拉动生产。而看板开发方法通过限制在制品数量形成拉动系统，缺乏这一核心机制就不成其为看板，对此，Corey Ladas 这样描述 “复印的美元不再具备货币的内涵，因此不再是钱；同样，缺少在制品数量限制的看板墙，也不能叫看板”。在制品数量的限制值及其演化，将在以后的文章中讨论。

3.4 核心实践4：度量和管理流动

快速、顺畅的价值流动是看板开发方法的目标。快速流动带来快速的价值产出和快速反馈，它对业务成功至关重要；顺畅流动，意味着稳定和可预测的价值交付能力，这与流动的绝对速度同等重要。

度量为改善价值流动提供方向参考，同时为改善的结果提供反馈。看板开发方法没有定义特定的度量方法，累积流量图是实际应用较为普遍的一种。图 ㈨是一个典型的累积流量图，左面的斜线是累积已经开始的价值项（如用户需求）数目，右面斜线是累积完成价值项的数目。两条斜线的垂直距离表示某个时刻已经开始但还没有完成的价值项数目，也就是在制品的总计数量。两条斜线的水平间距表示价值项从开始到完成的周期时间，也就是从概念到交付的响应时间，它是价值流动效率的一个重要衡量。斜线的斜率反应的是价值交付的速率，也就是每周可以交付的价值项数量。

图 ㈨ 流量累积图

累积流量是一个综合的价值流度量方法，可以通过它得到不同维度的信息。例如，我们设想限制在制品的数目，可以缩短周期时间、而对交付速率影响有限。但实际效果如何还要通过事实来检验，通过实验和度量，图中的数据基本验证了这一假设，让改进更有方向，结果更可衡量。同样的数据有不同的呈现方式，图 ㈩基于相同的数据，它突出了在制品数目和周期时间的变化趋势，以及两者的关系。从图中可以看出，周期时间的降低略滞后于在制品数量的降低，这符合精益理论，因为只有在积累的队列被处理完后，对交付周期的改进才能够显现出来。而图 11反应的是系统流量（每周交付价值的数量）的变化趋势，为改进提供了信心。

图 ㈩ 在制品数目和周期时间

图 11 周流量图

以上只是一个度量实例。度量不是目的，而是管理和优化价值流的手段。对于特定的组织，度量什么应该由目标和现状决定。

3.5 核心实践5：协同改进（Improve Collaboratively）

应用可视化、限制在制品数量、以及价值流度量，能够暴露产品开发中的问题和瓶颈。但发现问题还不够，重要的是如何去解决它们，对此看板开发方法给出了两个建议——团队协作和应用科学方法和模型。限制在制品数目本身就能够激发协作，例如在前面图 ㈧的看板墙，可能会出现以下的顺序场景

1) 测试遇到问题(如输入质量太差)而被阻塞 ，在制品数量达到上限

2) 因在制品数量达到上限，根据规则，测试不能从上游（实现）拉入更多的工作

3) 实现阶段已完成的工作无法进入下游测试环节，实现阶段的在制品数量很快也达到上限

4) 实现要想开始更多的工作，就必须关注下游的问题，并做出反应，如提高本环节的输出质量，或者是给予帮助

5) 实现和测试的协作使价值流动更加顺畅

图 12 协同改进

图 12是”kanban – Successful Evolutionary Change for Your Technology Business”一书的封面插图，它反映了发生在看板墙前面的协同改进。看板开发方法的基本假设是：产品开发的目标不是单个环节效率的最大化，而是端到端价值流的提升。看板通过拉动机制暴露了限制价值流动的瓶颈，并激发团队协作，改善价值流动。

解决瓶颈问题的方案可能在瓶颈处，如临时加班、分配更多资源、或相邻环节的支持等。但很多时候解决瓶颈问题的方案在别处，例如提高瓶颈之前环节的输出质量，调整职责分配，甚至是重新设计工作流。

对于偶然出现的问题，只需要临时性解决方案。如突发性高负荷，可以通过暂时的相互支持解决。而对于系统性问题，如持续的负荷不均衡，则需要长期的方案和更加系统和科学的模型指导，如系统思考、精益思想、排队理论等，这些模型本身不属于看板方法的一部分，但它们让长期的改进有章可循，以后的文章，我将中深入地探讨其中的一些模型。

4. 总结：看板是变革方法

David J. Anderson这样定义看板开发方法：

“看板定义了我增量、渐进地改变技术开发和组织运营的方法。它的核心机制是限制在制品数量的拉动系统，通过它暴露系统运作（或流程）的问题，并激发协作以改进系统。”

这当中的核心是，看板并不是一个开发框架或流程，而是引领变革的方法。每个组织有自己特点，所面对的市场，使用的技术不同，经历和所处的阶段不同，他们值得也应该拥有适合自身特点的方法流程。

看板的实施正是从组织流程现状出发，首先可视化实际工作流并显式化流程；在此基础上，限制在制品数量形成拉动系统以暴露系统问题和瓶颈，度量价值流动以发现改进机会；并通过团队的协作，不断改进和演化出合适的流程、方法，实现一个高效、顺畅的产品开发价值流。

适应组织的具体情况，和发现合适的变革路径，这两点是敏捷实施的最大困难，看板给出了被证明可行的方案。这可能是看板能够在国外社区迅速推广并成功运用的原因，而在国内，看板这方面的价值还远未被认识和发掘。这篇文章之后，我们还会从不同的方面，更加深入地介绍精益产品开发。它们是：

- 价值篇：解析产品开发中的价值和价值发现过程

- 价值流篇：解析产品开发中流动的本质，和价值流的管理

- 可视化篇：探讨面向价值和价值流的整体可视化方案

- 看板实施篇：通过案例介绍看板的实施步骤和实践细节

- 变革篇：从组织变革的视角讨论精益的实施、看板应用和持续改进

- ……

（二）产品开发中的价值

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

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

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