敏捷产品开发，一百个人有一百种理解，敏捷本来就是一个集合性的名词，讲到敏捷大家可能会联想到：scrum、xp、测试驱动开发、看板、持续集成、持续重构、技术卓越等等这些词，还会联想到与价值观相关的部分，比如说：应对变化、自组织、适应性等等。

这样讲没有问题，但这对我们理解敏捷真正的含义并没有太多的作用。有一位软件工程界的宗师级人物曾说过：“如果你过去问我支不支持敏捷，我可能说支持或不支持，并给个理由，现在只能说支持了，因为现在敏捷指的就是软件开发中一切好的方面，如果有什么不好的东西那就表示不够敏捷。”这样的说法对于敏捷的推广或许有好处，但对真正理解敏捷和实施敏捷而言却不然。

德鲁克说：任何组织的绩效都只在外部反应出来。外部就是给你带来价值的地方，也就是用户或者客户。敏捷作为一种管理的手段或方法，存在的目的是帮助组织取得成效。其责任是协调资源取得成效。不管是方法或技术都是为了成效服务的。

想要理解敏捷，必须回到业务目标，这是根本。敏捷的对立面经常是瀑布，上图左边就是一个瀑布模式，开发分成分阶段：需求-设计-开发-测试，每个阶段形成一个瀑布流，这种瀑布流的开发方式存在的问题是：价值交付只能是在最后。横坐标代表时间线，就是在全部做好之后一次性交付价值。

一次性交付价值存在的问题：根据摩尔定律，每18个月之后用同样的钱可以买到一倍的东西。反过来看， 18个月之后交付的话只能得到今天交付的一半的价值，越迟交付的是越少的价值，这是针对硬件产品来说的，对于软件产品和互联网时代做的产品而言影响更深，越迟交付的产品可能面世的机会都没有，获得超额利润的机会也没有。

面对在瀑布开发下延迟交付的情况，敏捷提出的解决方案很简单：迭代。每一个迭代交付一部分价值，这部分价值因为交付得早就意味着更多的价值。敏捷的业务目标：更快（早）地交付价值。这里的快不是绝对速度与流量的更大，而是指交付的时间更早。

再来看敏捷开发的第二个业务目标。图的左边也是坐标图，表示一个项目，横坐标是时间，从项目开始到结束；纵坐标是团队对这个项目或产品所拥有的知识和了解。 什么时候团队对于项目的知识和了解最丰富？显然是结束的时候。另外一个有意思的问题是 什么时候做出对项目最重要的决策呢？开始的时候。

也就是说我们往往在知识最匮乏、了解最不够的时候做出最重要的决策，并把这个决策当成事实来对待，后面发生的事情很难反映到项目中去，知识的累积也很难反映到项目中去。这是知识累积和决策时机之间的悖论。

敏捷应对这个悖论的方法是：决策是增量做出来的，每个迭代做出一部分决策，交付一部分产品，得到相应反馈，并根据反馈再做下一个迭代的决策，不断获取反馈应对变化，这个反馈可能是交付之后的，也可能是市场或竞争对手的变化带来的。

敏捷的第二个业务目标：更灵活的响应变化。也就是说通过增量出决策，不断交付获取反馈，积累更多知识，并应用这些知识做出更正确的决策，更灵活响应变化，这个变化包括主动的知识积累，也包括市场的变化、竞争对手的变化、团队对项目的了解。

综上所述，可以从业务角度对敏捷做一个解释：敏捷就是敏捷

对于产品开发而言，敏捷的目标是：创建一个组织更早地交付价值，更灵活的应对变化的能力。敏捷对于业务层面来说是一个目标，对于一个组织来说是一种能力，这种能力是必备的，帮助我们在今天的市场和业务环境下取得成功。

当我们清楚了敏捷是一种目标一种能力的时候，我们对敏捷的理解就能达成共识：我们需不需要这种能力？这是不是我们的目标？这对于我们取得竞争的胜利有没有必要？而在今天这个竞争的业态，敏捷是一种组织必须具备的基本能力。所以我们需要讨论的是如何具备这种能力，如何变得更敏捷。下面会讲一些方法和实践，都是为这个目标服务的。

为了实现敏捷的业务目标，我们需要迭代和持续交付。这为我们带来的新的挑战是过去传统的方法不适用了。随着更多问题的提出，也相应地产生了一系列方法和实践：

• 比如怎么管理迭代交付的过程呢？于是就有了scrum、FDD、测试驱动开发、XP（极限编程）的管理实践和框架来帮助我们管理迭代开发的过程，这些实践都是为目标服务的；

• 每个迭代交付什么，怎么规划？于是就有了产品代办列表、用户故事、故事地图等实践。

• 每个迭代都交付一些，那么测试工作量或回归工作量会不断递增，怎么应对不断增大的集成和回归测试工作？于是就有了测试驱动开发、自动化测试、TDD；

• 如何沟通需求，于是就有了行为驱动开发、实例化需求等方法；

• 如何保证代码的演进或演进式的迭代，于是就有了代码共有、简单设计、持续重构、领域驱动设计、演进式设计等方法。

业务目标是why，为什么要这么做。这些方法都是服务于业务目标，解决了how的问题。其实大部分时候这是必然的选择，必须实现这个目标，在这个前提下再来想怎么做。当然这并不容易，不是这些实践的简单累加就会敏捷了，还需要系统地形成方法。

最近两三年的时间，精益这个词变得非常热门，凡提敏捷处必有精益，好像不提精益感觉就不酷似的。我们先看精益产品开发是什么？

上图我们称之为waterfall，我们都知道waterfall不好，它不能应对变化、延迟了价值交付，那要怎么办？

现实的第一个挑战：开发环节的迭代并不带来真正的价值交付和真实反馈。

我们需要引入迭代开发，比如scrum、xp。图中的waterfall是从需求开始到测试结束，但是现实中可能不一定是，现实中在需求之前可能还有产品规划、产品定义，可能还有更早的一些探索，测试之后还有实施、验证、调整等，这时候我们发现在更大范围来讲其实还是一个waterfall，如上图所示，只不过在开发阶段实现了所谓的迭代，但并不能真正实现迭代的价值交付。

我们把这种模式称之为：water-scrum-fall，我们理想的目标是通过迭代更早地交付价值、更灵活的应对变化，但事实上仅仅是开发环节或者工程团队环节的迭代，并不能带来真正的价值交付，也不能得到真正真实的反馈，那么我们需要做得更多，需要更加端到端。

现实带来的第二个挑战：单个团队的实施也无法交付完整的用户价值。

在大的电信公司，比如华为，去做这个事情的时候会发现，为了交付一个价值需要多个团队，华为称为多个网元，不同的网络设备，每个设备都可能涉及到几百人上千人，这时每个设备下面可能会分成不同的功能团队、或者叫特性团队、模块团队。整个需求是分层的，在华为解决方案层面对应的需求是客户的原始需求；网元层面对应的是功能性需求；模块层面对应的是可分配需求，这时你会发现单个模块团队去敏捷不可能端到端，无法交付完整的价值，也无法得到反馈，所以我们为了更早地交付价值，其实就需要协调多个团队。

总结起来就看到了理想和现实的差距：理想是更快地交付价值，更灵活地应对变化；现实是：在开发阶段或者在团队实现阶段去做敏捷，或做单个团队的敏捷，往往不能带来价值的完整交付和灵活应对变化，这是很多团队面临的挑战。

精益是解决这一类问题的方法，精益作为一个思想比敏捷产品开发诞生得更早，遇到这样的问题可以诉诸于精益。那么精益是什么？维基百科上对精益的定义是：精益思想是关于有效组织人类活动的一个新的思维方法，目标是消除浪费，更多地交付对个人和社会有用的价值。概括为两个核心点：消除浪费、增加价值。

针对产品开发来说是顺畅、高质量地交付真正的价值。

怎么去实现呢？精益真正区别于其他的方法并不是它的目标更好，而是它有与这个目标相适应的一整套方法学和实践，接下来要说的是如何实现顺畅和高质量地交付价值。

上图是精益产品开发里一个比较核心的概念图，说的是我们对待效率的不同态度。很多改进一定程度上都是在提高效率。我们把效率分成流动效率和资源效率：

资源效率是资源的使用率和产出，比如工程师的产出、每个设备的产出，资源产出越高效率越高，这是资源效率；

流动效率是从用户的角度去看，一个用户的需求从提出到交付整个流动的速度，从提出到交付流动的时间，流动速度越快效率越高。

• 左下是一人干活十人围观，其资源效率和流动效率当然都是很低的；

• 右下是消防员，其实消防员的流动效率是很高的，一旦用户提出需求，他可以在第一时间响应，一点都没有等待，但他的资源效率很低，大部分时间都处于待命；

• 左上是炼钢炉，炼钢炉的情况是它一旦开启后面的东西必须配合排队，因为炼钢炉的耗费是很大的，必须保证他资源的利用率，而待加工的物料（用户价值）则在后面排队；

• 右上是快递公司，快递公司对资源效率的要求是很高的，因为关系到成本，对流动效率的要求同样也很高，因为这关系到对用户的服务。

对于产品开发来说，我们希望效率跟快递公司类似，也就是说资源产出要高，对用户的响应速度要快，用户的需求从进去到出来的时间要短，绝对速度要高。如何达到这一点是我们真正要关注的地方。

在传统的方法里，我们都会更注重资源效率，这是有原因的，我们改进的的时候会改进开发的效率、改进需求产出的效率、改进测试的效率，因为对于我们的管理方式来说，我们看到的就是一个个职能部门，而这种效率的改进到最后往往都是起不到效果的，因为简单的改进你都会做到，剩下的局部优化往往会影响到系统的性能，即整个的有效产出。这就会产生一个个的效率竖井，设计开发运维，一个个看上去效率都很高，但是事实上有效地价值流动却不能产生，系统并不是最优化的。

我们习惯聚焦于资源效率，宏观地来看在整个开发过程中开发和运维这两个大部门其实也是在关注各自的资源效率，然而很多时候这种效率的提升是没有用的，局部优化带来系统的劣化，这是一个非常普遍的情况，所以仅仅聚焦于资源效率产生的是效率竖井，精益产品开发对此提出来不同的看法。

如图所示，如果我们沿着资源效率的改进继续下去，会发现过度的局部优化损害的是整体的效率，并带来全局协调的困局。也就是说你看上去提高了资源效率，但最后它由于整体协调的困局，资源效率的改进也是无以为继的，这种情况特别普遍，对于很多一直在做效率改进的部门，如果一直沿着这条路走下去，各个部门单独改进，最后流程变得原来越来越复杂臃肿，整体效率很难提升。

我们热衷于改进资源效率，因为我们每天都能看到资源效率，而流动效率则不然，用户需求从进去到出去这个过程是看不见的，我们看到的是谁忙不忙，一天能产出多少代码，因此我们更倾向于去改进看得到的东西，这是很正常的。

上图中一个醉汉在路上寻摸了差不多半个小时，警察一直在旁边看着，实在看不下去了就问醉汉在干什么。醉汉说我在找我的钥匙。警察看了一下说这儿没有钥匙。然后又找了一会儿说：你钥匙是丢在这儿了吗？醉汉说：不是呀。警察又问那你为什么在这儿找呢？你知道醉汉怎么回答的吗？醉汉说：只有这儿有光啊。

资源效率是我们能看到的地方，却不是关键（Key）所在。我觉得这个隐喻很精确。

有一个精益产品的大师说：在产品开发中，我们的问题几乎从来不是停滞的资源（或不动的工程师），而是停滞的产品需求（用户价值）。但这个问题是很难看到的，那么我们在精益产品开发中怎么来处理这个问题，其实就有了答案，首先得看到需求流动的过程，看到了才能去改变。

第一步：理清价值流，约束在制品数，改善流动效率

精益产品开发的第一步是：提高流动效率。让用户的需求批量降低，并减少排队和拥堵，让它在整个研发过程中顺畅地流动起来，从进去到出来的过程时间尽量短，等待尽量少。

我们首先要做的事情是以用户价值为核心，打通整个组织的价值交付链条。就是要去分析这个价值流，然后识别和消除那些明显不合理的部分，让从用户的问题到解决方案的过程越短越好，这就是改进流动效率的第一步。

要做到可视化，要分析和可视化端到端的价值流动过程。质量管理之父戴明说过一句话：如果你不能以一个清晰的过程来展示你所从事的工作，你就不会真正地了解你在做什么。产品开发所从事的工作就是交付用户价值，从用户问题出发到交付解决方案。

我们做的就是要可视化端到端的价值流动过程。

看一个团队的看板，这是一个端到端的交付过程，蓝色的纸条从需求提出到设计到向开发团队澄清然后是就绪，就绪后我们称之为用户故事，这里的就绪是指对开发团队就绪了，开发知道验收标准了，相应的技术风险也分析了，之后一大段是实现中，这个实现中被划分成很多横向的条，这些条被称之为泳道，每个泳道里是一个需求（白色的纸条），后面的蓝色和黄色纸条是这个需求对应的任务，任务里分属不同的列和模块。

当所有的任务结束后，这个故事就可以拿到验证、待验证、待验收、已交付，流经整个过程。《精益产品开发原则、方法与实施》一书对此有详细的介绍。

从这幅图可以看到，这是一个端到端的交付过程，最前面一段是产品，最后一段去验收交付的也是产品，中间一段是研发的过程，这是一个2B的产品，无法让用户直接参与，所以产品代表用户去发布和接收需求，一定程度上是从用户开始到用户结束的一个端到端的价值流动过程，我们也看到研发即所谓的实现阶段，反映了团队的协作，不同的模块团队协作去交付这个故事，也看到了需求分解和合并，需求分解成任务，任务完成后再合并成需求去测试。

右边需求上贴着红色纸条是bug或问题，表现缺陷、问题和阻碍。

这个看板清晰地反映了三个方面：需求的交付过程、各个团队的协作怎么去交付一个需求、需求的分解和合并。

这里能看到需求的流动，比如泳道数是有限的，团队并行开发的需求数目是有限的，这个有限有一个好处：我们要尽快地完成那些已经开始的需求，如果泳道满了，你也不应该开始更多的需求。也就是尽快交付已经开始的价值。如果这个交付过程中间有问题，因为泳道数量有限，很快能看到拥堵，问题也会及时暴露出来，及时解决。所以更加注重需求的完成，而不是需求的开始，也就是说我们是以价值交付来驱动整个过程的。

除此之外，我们还应该看到它反映的流动过程，及其背后的规则，比如一个需求从一个阶段进入到另一个阶段需要满足怎样的规则。上图给出了两个规则示例，所有进入就绪的故事必须满足：

• 必须完成实例化需求活动，开发、测试和业务共同澄清需求，并定义明确交互过程和验收标准；

• 大需求已拆分为工作量在两周以内的故事；

• 已与业务关联方确认相关计划；

• 识别大的技术风险并定义应对方案；

• 涉及三个（含三个）开发人员以上的需求，执行好协调人，负责进度协调。

所有移交测试的需求需要满足：

• 并入正式的版本，并通过持续集成环境的检验

• 开发对照实例化过程中的验收标准进行了自测。

其实这些流动过程加上规则就构成了团队是如何操作这些需求的，也就是戴明所说的我们以一个清晰的过程来展示我们所从事的工作。

• 清晰全面地反映需求和需求交付的过程；

• 瓶颈和问题能在看板上得到即时体现；

• 团队可以根据看板信息协作和做决定。

但这只是一个基础，它分析了价值流，也可能会对价值流做适当的优化，但是我们还需要基于这个基础对价值流做一些管理，让其顺畅流动，这是下一步要解决的问题。

第二步：有效地提高资源效率

我们最终要实现的是资源效率和流动效率的同步提高。但我们必须从流动效率提高，才能保证全局的协调，就是整个价值交付链的协调，涉及到需求、开发、业务，测试，如果从流动效率开始的话就能保证他们的协调一致，然后再以此为基础进行资源效率的改进，这时候的改进才可以为继，否则如果从资源效率开始就会陷入协调的困局。所以效率改进的第二步是：在流动效率保证的基础上有效地提高资源效率。

看板记录了价值流，在此基础上我们要去管理价值流，比如一个需求怎么进入就绪，需求的分析过程这里不详细展开，通过实例化需求分析和澄清需求，或拆分需求，实例化需求是分解需求的很好的方式。

流动过程中看板反应了问题和瓶颈，怎么通过站会来促进价值流动？站会不是检查每天的工作的，而是促进价值流动的。标准的Scrum站会更多的是陈述每个人的工作，是以做什么优先，看板的站会是以价值流动优先的，关注流动，解决流动中的问题，所以一般效率会高很多。

前文讲的只是两个例子，怎么去管理价值的流动，主要是价值的输入，比如需求填充的过程、就绪队列的过程、价值流动过程的管理，还有输出，发布部署等，都是为了促进价值的顺畅流动。

现实是做了流动管理后，价值的流动过程还会有这样那样的问题，比如质量、进度、协调的问题，这时候怎么办？

为了分析和看到这些问题，就会引入精益的反馈和度量方法，在这里也不详细介绍。每个方法都会对应自己的度量，精益的度量有其独到之处：以价值流动为核心的，比如累积流图，是比较精确地再现了价值流动的过程、团队协作的过程，从而发现并衡量这些问题。

持续改进是精益产品开发的一个核心，也是精益思想的一个核心，通过持续改进来实现价值的顺畅流动，通过各种度量来反应问题，支持这种持续改进，所以精益在这方面是有其独到之处的。

在这里我们讲的是，通过反馈来收集定性和定量的反馈，并定期分析这些反馈，然后落实为具体的行动，比如流程操作，而这种操作会反应到看板和背后的规则上去，也有可能是其他方面，比如基础环境、代码设计、测试守护、人员能力，具体行动改进落实后再通过反馈看改进的效果，我称之为反馈、分析、改进的循环。有点类似于戴明的PDCA。

和PDCA相比少了一个计划的过程，在精益产品开发中是把持续改进内建到产品开发过程中，所以没有单独的计划过程，反馈、分析、改进是一个持续的内建的过程，内建到开发和交付的过程中，其结果是反而比较容易落实。

第三步是说效率是有边界的，不可能资源效率和流动效率同时达到100%，前面图片中消防员为了达到自己的流动效率，其实是牺牲了资源效率的，为了能及时响应火情，大部分时间是待命的，但产品开发希望两点都比较高，最好是能接近于理想值。所以怎么能突破这个平衡点是我们又一个要考虑的问题。《精益产品开发原则、方法与实施》一书对此有详细的介绍，时间关系就不多说了。 

精益产品开发的改进其实是从流动效率开始的，首先要可视化端到端的交付过程，然后管理好价值的流动，在管理好价值流动的情况下，再去发现这些问题，提高资源效率，我们希望保障全局的协调，这是以用户价值为核心的改进。怎么让它端到端的打通保证产品价值的交付，并做到真正交付有效的价值。这是精益思想的独到之处，

第二步也讲了，最终我们还是要改进产出效率，但是必须是基于可持续的改进，全局的改进，在全局协调、用户价值顺畅流动的基础上，再去改进和保证流动的速度更高。

我们看到精益看板方法的实践体系，正式在落实上面所说的思想和方法。

精益看板方法的五个实践：

第一：可视化价值流动，根据团队情况建模设计一个看板；

第二：显式化流程规则，有了一个看板流动过程，它的规则是什么，通过这个规则，团队怎么能够更好地组织和决策；

第三：控制在制品数量， 前两步实施好了这是一个很自然的结果；

第四：管理价值流动，包括输入输出和中间过程；

第五：建立反馈，持续改进。

这里是一个概貌，具体的内容就不详述了，有兴趣可以看书。

敏捷产品开始是为了更快的交付价值，更灵活的应对变化，而在现实中却会碰到这样那样的问题，精益产品开发是帮助我们变得更敏捷的一个方法。除此之外还有另一个重要的方面，怎么保证端到端地顺畅地交付高质量的价值，这是精益产品开发要解决的问题，这比敏捷“更灵活应对变化”要求更高一点，而且如果你的交付过程是顺畅的，你自然就应该是敏捷的，当然精益产品开发更重要的还是第二点：交付的价值是有用的，能保证业务的成功。

就是说如果你交付的价值是没用的，不能保证业务的成功，那这种交付是没有用的。敏捷开发对此的答案是我们要应对变化，如果市场变化了我们跟着变，但其实在今天看来这是有一些被动的。它做了一个假设，这个假设是：有人会告诉我该怎么变，但事实上不是，用户不会告诉你他需要什么，用户的选择太多了，他只会选择能够满足他的，甚至于能够引导他的，所以如何交付有用的价值，是接下来要讲的精益产品开发和精益创新要解决的问题。

这幅图是招商银行的案例，招商银行在顺畅、高质量交付价值方面是国内企业中做得很典范的，它的看板是一个真正的端到端反应价值交付和团队协作的看板。

我们要回答的问题是：除了顺畅、高质量地交付价值，还需要什么？

这个问题的答案很明确：顺畅交付是前提，但交付有用的价值才是根本。

那么，什么才是有用的价值？

我们面临的环境，引用一个最近很热门的词“乌卡时代”，就是说我们现在的时代是易变的、不确定的、复杂的、模糊的，产品开发生存的环境越来越困难，我们也不知道面对的需求是什么，客户告诉你的明天就可能会发生变化。

这个时代的另一个特征是：选择权已从生产者转移到消费者一侧，我们早已告别了稀缺时代，用户的选择太多了，我们称之为选择的暴力。选择权在用户手中，过去我们将我们的产品创新要能跟得上鼠标点击的速度，今天鼠标也不用点了，用户用手中的手机随时做出选择，而且更可能是无视。带来的直接变化是你做的东西用户不一定会用，用户不用就是浪费，精益就是要增加价值和消除浪费，但产品开发中，乃至整个创业和创新过程中最大的浪费是：交付用户不在乎的东西。

总之，乌卡时代变化太快，越来越难把握，选择权转移到用户手中，我们需要新的创新和产品开发模式，来做出一个用户在乎的会去用的东西。

这时就引入精益创业的概念。和传统的有规模的企业去讲精益创业可能会有一些敏感，要鼓励我们去创业吗？其实不是，精益创业概念的提出者定义了“创业”的意思：在高度不确定的情况下开创一个新的产品或服务。所以即使在传统的大规模企业中开创一个新的产品，如果它具有不确定性，需求不确定、用户不确定、问题不确定、方案不确定，那就需要精益创业的方法，来做出一个用户要的东西。

这是对精益创业的定义， 并不是说一定要是一个创业公司，而是在一个不确定的情况下做一个新东西。创业过程中最大的浪费是：构建没人在乎的东西。

精益创业的目标是做一个能卖出去的产品，而不是卖一个能做出来的东西。就是说因为选择权转移了，不是做一个东西就一定能卖出去的，所以做一个能卖出去的产品是精益创业的目标。

那么怎么做到这一点呢？在这幅图里我们看到，我们以为成功的过程是这样的一条直线，事实上成功是一个不断探索的过程，必须要承认这一点。

如果你制定一个计划去执行并希望它一定成功，泰森对此的评价是：每个人都有一套计划，直到一拳打在他的嘴上。所以今天创业者如果还抱着这样的思路，必然的结果就是这样的。你几乎找不到一个没有在过程中调整自己方向的成功的创业产品。

精益创业其实是一个科学的思维，上图是伟大的库克船长探索太平洋的过程。

精益创业的过程是从承认自己的无知开始，今天一个伟大的想法越来越不那么重要了，至少它不能保证成功。

上图展示的是两幅地图，左边是1459年欧洲人的世界地图，那时候的人相对现在来说是无知的，但是他们的地图反而更详细，世界所有的地方都根据他们想象的样子画出来，认为世界就是这样。而另一幅地图是1525年，哥伦布刚刚发现新大陆，这时候的地图出现大量留白，这就鼓励我们去探索。所以说承认自己无知，才能激发求知欲，去发现去探索。科学的革命本质上也是一场无知的革命，是从承认自己的无知开始的，之后才有了后面科学的发展。

跟承认自己的无知相对应的是先知的封印，这是一个宗教用语，先知知道一切。为什么我对这个词有特别深刻的印象呢？我和一些创业团队或者一些公司里的创业项目接触，发现最大的障碍是先知的封印，就是说我定义了这个方向，你们团队去执行就行了，这样的结果几乎都是失败的。真正的成功需要团队一起去探索去调整。所以要想成功，我们首先要承认自己的无知，以观察、实验、数据为基础，去调整建立新的能力，这是科学革命的态度，产品开发产品探索也需要科学的方法，这已经在科学界和工程界被一再证明了。

精益创业的核心：开发测量认知的循环和经实证的认知

精益创业的核心概念是：我们有一个概念，但它是被看做一个猜想或设想，根据这个设想开发一个产品，测量它，得到数据，通过数据建立认知，判断这个想法靠不靠谱、可不可行，接下来调整想法，如此往复，我们称之为开发测量和认知的循环，通过这个循环建立一个经实证的认知，经实证的认知是对应于初始的概念，初始的概念只是一个概念、假设，被验证了以后才能成为认知。

这个循环包含了一个顺时针的验证的环和一个逆时针的计划的环，逆时针的环是有了一个想法，我们对它的态度是：首先要想拿到什么样数据来证明这个想法是可行的，而为了拿到这个数据，我们需要做一个什么样的产品。然后再进入执行的循环。

这幅图更形象地说明了从一个想法开始，经过开发、测量、认知循环，然后分析数据，如此往复，建立起一个可靠的商业模式。

如何实施精益创业和创新的实践，问题是从哪里开始？

关于从哪里开始，我们首先要知道的是：我们的创业团队或者创新团队的目标是什么。这个目标不是这儿有一堆需求我们要把它做完，这不叫创新。我们的目标是探索出一个可重复和可规模化的商业模式，我们交付的不仅仅是产品，而是一个商业模式。

完整的商业模式才能保障能卖出去，可规模化，而仅仅是能做出来。

商业模式是关于一个组织如何创造、交付和获取价值的完整故事。其中两个最重要的方面：产品和市场。产品包括：定位是什么，解决什么问题，用什么方案，需要什么样的成本、结构；市场包括：渠道、定价方式、运营等。

所以要做一个创新的过程，要知道初始的商业模式是什么样的，这个商业模式不一定合理，但是我们要把它刻画出来、描述出来，要从这个初始的商业模式开始探索最后交付一个可行的商业模式，包括产品和市场。

这个实践叫精益画布，就是用一页纸刻画你的商业模式，它有很多相互关联的模块构成，比如说客户定位、客户问题、解决方案、渠道、成本等。画布左边的模块是和产品相关的，右边的与市场相关。产品带来成本，市场带来收入，我们怎么保证成本和收入达到平衡。除了精益画布以外，还有很多其他的方法来刻画商业模式，比如价值定位地图、商业画布等。

刻画商业模式之后还要识别各种风险，市场风险、产品风险、客户风险等。所有的风险或者假设都必须被验证和解决了，这个商业模式才能成立，这个过程就是证明商业模式的可行，当然也包括商业模式的调整。

我们首先得有plan A,有了 plan A以后，识别它的风险，然后有计划地去验证这些风险，最后形成可行的商业模式，如图横向的是一个个的方案，有些方案在初始的阶段就会被否定掉，有些是因为识别到的风险而被否定，最终要交付的是一个可行的商业模式。

但是，产品创新的过程不可能是看着商业模式来做的，有时候精益画布被过度神话了。产品创新和开发过程需要进入更细的粒度。我们产品创新的过程，必须要去衡量创新和交付的进度是什么样的，这是精益创业一个很重要的话题。

我们必须要有数据才能衡量进展，比如概念，每个人都觉得自己的概念好，那我们怎么衡量这个概念是好的还是坏的；测量，测量什么？怎么测量？认知，要建立认知，没有数据就没有认知。

我们的问题是要去定量衡量创新的过程，而过去常用的方法并不可行。比如基于功能交付的进度无法衡量创新的进展；比如我们用过去运营的指标——用户数、收入来衡量产品的创新过程也是不适用的，因为整个创新过程中对用户数可能只需要一个很低的数值，一小部分人被真正满足了就可以，如果一味地追求用户数和收入，往往会带到一些虚荣的指标当中去，我们需要一个不一样的指标来衡量创新的进展。称之为：创新会计，或创新核算。

比如著名的海盗模型。它是关于业务指标的，但对于指导创新仍然不够用。

在这幅图中我们需要看到商业模式是怎样运行的：用户是怎么进去的，进去后怎么激活的，激活后怎么留住的，留住后怎么产生销售的，一个老用户怎么给我们带来新用户的…我们需要去核算整个过程。我们看到了这整个过程，但问题是从哪里开始？

我们可以把一个产品的运营比作一个工厂，这个工厂运营的其实就是用户，怎么吸引用户、满足用户、留住用户、产生收入，我们要核算的是整个这个过程。

如果我们能找到这些指标，我们该先关注什么哪一个？Eric Ries说：一个新产品增长有三个引擎：粘性引擎；病毒引擎；付费引擎。

把这三个引擎放到工厂模式里，就会发现我们应该先关注的是怎么黏住用户。这部分涉及到的内容很多，由于时间的关系不展开讲。

总结：整个创新过程需要一个可交付的商业模式，然后要能刻画这些商业模式，找到一个可行的商业模式，在真正指导我们具体执行的过程中，我们需要有数据，围绕这些数据一定要理解产品的运营方式，怎么去吸引用户激活用户留住用户产生收入，以及产生口碑效应等，不同的产品需要不同的方法，并建立不同的数据指标，要知道什么时候去关注什么指标，由这些指标出发真正设计你的产品。当然对于不同的具体产品，你还需要做的更细，上图就是电商产品的例子，就不展开了。

关键：要看到全貌的同时，聚焦当前时刻最关键指标。全貌是整个产品是怎么运营的，聚焦是在什么时间应该聚焦到什么指标上。这幅图里把产品的打造分成不同的阶段，并称之为关隘模型，也就是说你得一关关的过，每个阶段关注与之对应的目标，具体到创新核算，就是专注于相关的指标，在不同的阶段应该聚焦不同的关键指标。

我们找到了不同阶段应该关注的不同指标，接下来要解决的问题是如何从目标出发设计产品？

引入一个新的方法——影响地图。影响地图解决的问题是从目标出发怎么设计一个产品的功能。之所以叫影响地图，是假设我们通过产品功能来影响用户的行为，最终实现产品的目标。

影响地图是一个非常有效的、支持精益创业的需求挖掘和需求规划的方法，在互联网行业被普遍采用，上图给了一个影响地图的概貌和一些例子，影响地图是由四个级别构成：why目标是什么；who谁能帮助我们实现这个目标，用户或与用户相关的人；how他通过什么行为帮助我们实现这个目标；最后what为了产生这个行为我们产品需要做什么功能。

影响地图有一个核心点：影像地图里的需求只能看成假设，我们假设做了这些需求就能对用户的行为产生影响，假设产生了这样的影响就能实现我们的目标，真正做的时候影响地图把这个假设呈现出来不断印证，这个假设印证的过程其实最后就是体现精益创业的过程，基于概念开发产品，通过测量得到数据最后验证这个概念。

所以影响地图综合了精益创业的实践和精益需求的方法。

如图，举一个影响地图的例子，既是需求挖掘、需求设计的方法，也是需求规划和迭代规划的方法。

产品的设计永远不是一个简单的事情，并不是说告诉你一个框架一个小的方法就能实现的，用好影响地图背后的产品设计假设，通过改变或影响用户的行为来实现业务和产品的目标。如何改变和影响用户的行为其实需要对人性的把握和商业逻辑的理解，以及一些产品设计的真正的技巧，比如如何提高用户转化的LIFT设计模型（在培训中会讲到），提高用户粘性的模型。产品设计本身就是一门学问，通过精益产品设计方法把相关的精益产品设计理念整合起来。

产品创新的挑战：在耗尽资金和时间前实现产品和市场的匹配。任何一个创业都是有时间和资金的约束的，不管内部还是外部。要在耗尽这些时间和资金之前交付一个可行的商业模式，至少证明值得继续投资。

创新管理的核心：延长创新跑道的长度。

之所以用一个飞机的跑道来举例，是想说明在跑道的尽头飞机必须能够起飞，跑道有多长很重要，这个长度由什么决定呢？大家很自然会想跑道的长度是还有多少时间多少钱。比如给了我两年，肯定比给我一年更容易成功，比如给了我一千万肯定比给我500万更容易成功。但事实上跑道长度不取决于时间和金钱，它们只是约束条件。

那么，跑道的长度由什么决定呢？

创新是一个探索的过程，取决于探索的效率。跑道的长度取决于：在给定的时间和金钱的条件下组织能做出有效转型的次数。每次转型都是一次探索，并不是每次转型都是大的方向的转型，比如是用户定位的转型、问题的转型、解决方案的转型等的改变，但必须是有效地改变。注意这里很重的一点是“有效的”转型。

也就是说我们必须从先知的封印（有一个想法，你们去做吧，肯定行）转变成科学的探索方法（能指引我们有效探索和转型）。

科学的探索方法有三个最重要的点：速度、专注、有效学习。三者缺一不可。

• 速度容易理解，缺少速度会耗尽资源；

• 缺少专注会导致过早优化，没有在正确的时间做正确的事情；

• 缺少有效学习会导致瞎忙。看上去在探索，在转型，但是总是没向正确的方向去。

如何做到这三点呢？这是精益创业实践和精益创新管理需要关注的东西。

• 速度：快速迭代、减小实验批量快速试错、顺畅流动（从一个想法到验证要更快）；

• 专注：要看到整体、目标驱动、专注单一指标、目标清晰的MVP；

• 有效学习：承认无知、精益设计、明确假设带着目的验证假设、数据/结果分析、直面结果并行动，勇于转型。

回到敏捷宣言（如上图）。这是2001年提出的，其实它的全称是敏捷软件开发，当是大家还是聚焦于软件开发过程的问题，今天面临的问题是如何更顺畅地端到端地交付有用的产品，所以敏捷宣言也需要作一个扩展。精益和敏捷宣言：（如下图）

作为一个完整的体系，需要先有精益产品设计，在此基础上有相应的精益或敏捷的需求和管理方法：比如实例化需求、用户故事地图等，再是产品开发的输入，在输入的基础上需要有看板这样的方法，然后到产品交付，这时候要跟产品运营打通，得到反馈支持产品探索和创新实践，精益数据的分析方法、构建和优化、验证的方法，再回过头来支持精益产品设计，形成循环，这是我们完整的精益产品开发体系。

Q：@SparkYu@何红旗：敏捷、精益有什么区别？

A：先说一个事实：敏捷早期受到了精益思想的一些影响，比如Scrum和XP的发明人都声称收到精益思想的启发，但这些影响不是根本性的。早年提敏捷时，较少说到精益。不过最近3，5年情况变了，好像只说敏捷，不带上精益就一点也不酷。

easily）。具体到产品开发就是：“更早的交付价值，更灵活的应对变化”，这是一个目标，也是一个能力要求。至于各种实践，其实都是为这一目标服务的。比如Scrum是管理迭代交付过程的一个框架，有人可能说不是，说Scrum还是一个持续改进的框架，但持续改进不也是为了价值交付吗？TDD，持续集成等实践都是服务于这个目标。

精益的目标也不复杂，消除价值交付过程中的浪费，交付更多有用的价值。它最核心的就是两个字“价值”，体现到产品开发中就是要“顺畅，高质量地交付有用的价值”，就目标本身而言，如果顺畅，你自然就是敏捷的，精益是涵盖了敏捷的，但不能因此就说精益更牛，毕竟说大目标谁不会啊。精益的核心还是为了实现这一目标背后的方法学支持。方法学我没办法展开来讲，好在，我有一篇完整的文章说了，也做过一次线上分享。大家可以参考。在我的公号（LeanAction）中回复“精益思想”可以找到这篇文章。

那为什么精益这两年提得特别多呢，我看到三个原因。

第一： 产品交付的要求越来越高了。如果只是开发阶段的迭代根本不能做到交付真正的价值。这时原先适应小团队和交付阶段的Scrum，XP方法搞不定了。

我们需要打通组织的整个价值链，做到所谓前后的真正拉通，规模和关联复杂时还要融合左右，目标只有一个——快速的交付价值或验证设想。今天几乎所有的大规模敏捷框架（比如SAFe，LeSS）都会把精益思想和实践作为基础，背后就是这个道理。顺便说一句，我个人是不支持任何大规模敏捷框架的。

第二：创新的要求越来越高了。敏捷宣言里说，我们要响应变化。Scrum和XP的实践也是这么做了。但今天互联网时代，要求变得更高了。响应变化这个词其实显得有点被动，它暗含了一个假设，就是有人会告诉你改变了，该怎么变。然而，今天这不是事实了。团队需要刻意的有计划的去探索、去寻求变化，甚至试错这个词都不能表达背后的意义，应该是目标驱动地、系统和高效试错。唯有这样才能交付出有用的东西。在这一背景先产生了精益创业的方法，精益创业事实上是精益思想，在产品创新（而不仅仅是创业）过程的应用。这个和精益思想有什么联系我就不展开了，Eric Ries在《精益创业》中有很好的阐述。

第三：敏捷的落地和变革非常困难。定义一个理想的模式是容易的，了解现状要难一些，但也还好。最困难的是，如何从现状到达理想的目标。精益方法为此提供了方法学和实践的支持。我在书的第19章，就专门阐述了这一点。我讲了怎么化解资源效率和流动效率的悖论，并以流动效率为核心来组织团队的改进过程。这背后其实就是精益的改进思路和实践。

第一：敏捷作为一个目标，就是更早交付和灵活的响应变化。它特别重要，但不代表产品交付的全部。

第二：精益强调是顺畅和高质量的交付，以及交付的是真正的价值。

第三：精益作为一个工具，应该主导精益和敏捷的实施。毕竟创新和价值交付是产品开发组织存在的理由。我们应该回到这个根本上来。

不过，很多时候精益和敏捷一般是混着用的，这没关系。重要的是，你应该合理应用敏捷的实践，并掌握精益这个强大的工具，实现真正的精益和敏捷的目标——顺畅（包含灵活）和高质量的交付真正的价值，有力支持业务的成功。

Q：@Charles 敏捷和持续交付的关系

A：敏捷是一个目标，也是一个能力要求，而持续交付是这个能力的最核心部分，是集成和标志，具备持续交付能力，其它能力估计问题也不大。

Jez Humble 给持续交付的定义是：以可持续的方式将各类变更（包括新功能、缺陷修复、配置变化、实验等）安全、快速地落实到生产环境或用户手中的能力。

按这个定义，持续交付不就是敏捷响应的能力吗？不过，持续交付从字面意义上，偏向工程实践，特别是软件构建和部署的Pipeline，但它也应该包含组织和管理实践。

其实今天，敏捷、持续交付、DevOps、精益（产品开发）是近义词，每个社区也都在努力扩展自己的外延，都在拉近自己和业务以及创新的关系，最后也就殊途同归了。

另外，持续交付这个词，我蛮喜欢的，它指向明确，又有撬动作用。DevOps就不那么明确。但模糊性反而DevOps有更大的想象空间，搞得朋友多多的，谁都为它站台，特别是云计算厂商，都号称自己是DevOps 的enabler。这样也不错，众人拾柴火焰高嘛。

Q：@飞翔的心: 进行scrum开发，如果提升团队的需求拆解能力？

@梅：产品大特性如果需要跨sprint时，是否需要拆分成小故事？如何评估和衡量？

A：大特性的分解是必要的，因为这样才能：

1）更早和更灵活地交付；2）更早的发现风险；3）方便计划安排

拆分有三个基本要求，1）要足够小，从迭代的角度，至少要能很容易的放入一个迭代，理想情况下一个迭代要能做多个需求；2）拆完的要端到端（有价值，能测试，能交付）；3）拆完后还要能看到整体。

为了拆而拆而拆，把拆分当成单独的工作是常见的误区。拆分应该是需求组织、分析和澄清的副产品，而不是单独的任务。

具体到实践，故事地图和实例化需求这两个实践很有用。其中故事地图是为了按业务场景来组织和规划需求。实例化需求的目的是有效地分析和澄清需求，过去OOA(面向对象分析)所解决的问题，实例化需求当中也会体现，只不过更适合迭代或持续的交付。实例化需求，我实施的时候觉得是个比较容易的实践，也能解决上面的问题。但是现实中做好的团队的确不多，等我有时间应该好好总结一下才对。

Q：@小鱼：如何让非IT人员理解敏捷，然后可以一起参与推动敏捷的实施和改善？

A：敏捷作为一个目标（快速、灵活的交付）本来就是业务的目标，而IT人员要做的是建立起实现这一目标的能力，我们称之为IT的敏捷交付能力。

这是前提，那怎么让非IT的人员理解敏捷呢。那就是要回到业务本身，谈灵活交付，谈端到端的价值交付，谈交付真实的价值。这些背后往往包含精益的思想，这部分解释了为什么最近两年，突然谈敏捷时，必有精益。

Q:@天外来客：WIP经验值与案例

A：我在书中用了三个章节和大量的案例谈WIP这件事，也给出了相应的经验和方法。

对这个问题，我在实施中很少会纠结。而那些纠结WIP应该是几的团队，往往还有更基础的问题需要解决。那就是要围绕价值组织团队的协作和交付，打通和可视化端到端的价值交付流程。有了这个基础，你会发现WIP的设置和贯彻难度会极大的降低。专注于已经开始的价值，快速完成它们，难道不是很自然的事吗？

如果团队看到的只是任务，这时要求设置WIP限制，就会很不容易接受，达到的实际业务效果也不直接，推广起来当然难。

Q:@追梦：我想了解的是：敏捷开发流程的前提是团队都需要具备敏捷思维，那么如何带动团队快速敏捷起来呢？

A：什么是敏捷思维？凭什么你的思维是敏捷的，而我的不是呢？这是我们应该思考的。

我不认为敏捷思维的说法是错的，但现实中鼓吹敏捷思维，效果的确不好。这你也看到了。作为个人应该有敏捷思维（不管这种思维是尊重人也好，适应性或成长思维也罢），但回到执行层面却不能要求别人有自己所谓的“敏捷思维”，更不能以此占据道德高点。

我们需要的价值思维和目标思维，而把敏捷看成实现目标的方法。所以，第一步应该达成共识的是，我们作为一个组织应该如何交付价值，我们对外的目标是什么，需要什么样的能力。而后才是需要是是什么样的敏捷方法，来帮助我们建设这一能力，和实现目标。

组织存在一定是对外交付价值，灵活的交付价值，这一点是没有异议的。从这个基础出发，我们就有机会构建好基本的共识和选择正确的方法。这也是为什么我在书中，强调最多的两个字是“价值”，而后再强调“价值的流动”。我强调的还不够的是“有用的价值”，这是我后面要做的。

Q:@小楼听雨：我想问一下，PMP项目管理和敏捷管理有啥区别？敏捷方法迭代速度快，在有限的时间和资源下，如何快速实现功能开发交付？用PMP方法管理团队和利用敏捷管理项目团队，各有啥优缺点？

A：我个人做项目经理很多年，PMP有它的价值，从PMP知识体系中我获益不少。但PMP的知识体系是不敏捷的，即使今天有ACP也改变不了这个事实。因为 “项目”这两个字就决定了它的属性，项目创造了批量、创造的节点。批量本身就和敏捷交付是背道而驰的。敏捷交付需要更多的是产品思维，实现产品的持续交付、持续反馈、持续运营和持续调整。

在敏捷交付中，我们需要弱化项目思维，而增加产品和价值思维。弱化批量化的阶段实践，而建设持续交付和反馈的能力。

另外，在需要大量同步、协调和决策评审的实施类项目中，PMP知识体系及实践框架会继续存在且发挥作用。。

Q:@大宇：敏捷开始的结束时间是固定的、而开发对象可以允许变更和追加的、如何在遵守时间的前提下对待式样变更。有没有什么实践经验上的注意点可以分享。

A：固定时间盒不是敏捷的必然实践，它只是Scrum的实践，在Scrum框架中有它的道理。要注意的点是:

• 拆分需求，但不要为了拆分而拆分，比如通过实例化需求把需求拆分成端到端的小需求。这样才有安排和变更的灵活性。

• 不要把Sprint做成小瀑布了，一旦做成小瀑布，所有的需求同时开始了，变更起来就不太可能了。而且最后往往会守不住时间，或因为时间而牺牲质量。

Q：精益对时间盒子的要求，是不是没有scrum那么硬性？

A：是的，scrum对时间盒的要求非常严格，时间盒是scrum里最核心的概念之一，scrum认为时间盒就是其心跳，所有的计划和跟踪模式都是基于时间盒，对于同一个团队其时间盒的要求是相等的，这是由其框架模式决定的。

在看板方法里对时间盒是没有要求的，scrum是面向迭代的，看板是面向流动的，它更关注持续流动，在看板里也建议有相应节奏，但是需求填充和交付的节奏不一定是一样的，比如可以一个星期填充一个需求，而交付可以是两个星期或一个月一次。之所以建议有节奏，是可以给大家对一件事情有一个预期，但不是必须的。

Q:@ 陈娇智：项目进度推进一拖再拖，每个阶段都有无数不同问题，如果确保项目质量和进度并存问题？

A：关于质量：以需求为粒度控制质量，实现单个需求的持续流动，而不是以迭代或项目为粒度控制时间点。我在第21章有详细的讨论。进度问题其实也是相关的，实现需求的持续流动，而弱化项目的阶段，在需求上内建质量，就不存在每个阶段无数问题这一说了。这一点招商银行的项目管理是典范，做得非常好。

Q:@琪琪：大项目做敏捷、持续集成，过程中专项或集成的工作并行太多，导致团队同时在运转的事项比较多，状态切换或专项转换混轮，怎么处理解决这种状态的混乱，或者怎么提高大项目管理中多项事情并行的效率？

A：操作上两个方面。第一：合理规划，理清输入。这是源头。第二：在第一点的基础上，限制在制品。

可能还有两个更基础的问题：第一：组织结构的合理性，是否与交付的需要适配；第二：技术实践的到位程度，比如有很多手工集成的工作，可能意味着需要划分的合理性，或持续集成实践的到位程度。

Q:@满江红: 梳理用户故事地图，如果即想按角色分类，又想按迭代划分，如何呈现到地图上，有没有好的实例？

答：看来你已经实践的比较深入了。这两个本来就有一些冲突。我个人的观点，按角色分是为了挖掘和过滤需求，到规划的时候，就不要强求按角色来规划迭代了。规划的时候应该按业务目标（优先）和场景来规划，如果正好能匹配角色，那是件好事，匹配不上不要强求。