第2章 精益产品开发的核心原则（上）：聚焦价值流动效率

第1章分享了从传统开发方法到敏捷的嬗变。本章讨论精益产品开发——有了敏捷软件开发，为什么还需要精益？它可以解决什么问题？

聚焦用户价值端到端的流动

“更早地交付价值，更灵活地应对变化”，这是敏捷产品开发的业务目标，为此，我们从瀑布进化为迭代。然而，现实中仅仅实现阶段的迭代是不够的，我们真正需要的是端到端快速灵活地交付价值。这里的端到端是指从用户的问题到交付用户解决方案。

实现阶段的迭代是不够的

如图2-1所示，尽管在实现阶段进行了迭代开发（例如使用Scrum框架），实现了从需求分析到测试验收的迭代，但需求分析之前还有业务的规划和产品的定义，测试验收之后还有方案实施和验证。从更宏观的范畴看，产品从创意到交付的过程仍然是瀑布的，并没有完全解决瀑布开发模式带来的问题，比如业务反馈不够及时，响应不灵活等。业界把这样的开发模式称为Water-Scrum-Fall。

部分环节的迭代有它的价值，至少让我们在实现阶段能够及时发现技术及协作相关问题，并做出调整。但价值的交付还是很迟才能完成，而且业务闭环未能打通，得到的反馈也不够真实。可以这么说：“我们在昏暗的隧道中小步前行，只是让自己不要摔倒；但只有真实的业务交付和反馈，才是照亮前行的光。”

开发环节的实施，并不带来真正的价值交付和真实的反馈，也无法交付完整的客户价值。

我们的美好愿望是“更早地交付价值和得到反馈。”然而，残酷的现实却是“实现阶段的迭代并不带来真正的价值交付和真实的反馈。”

从聚焦资源效率到聚焦流动效率

如何真正实现端到端快速价值交付？精益产品开发给出的答案是：“从以资源效率为核心，转变为以流动效率为核心来组织产品交付过程。”资源效率指的是从组织内部的角度，审视各个独立环节的产出效率；而流动效率是指从用户的角度，审视用户价值顺畅流动的程度。聚焦流动效率，是精益产品开发在方法学层面的核心原则之一。

为了理解“流动效率”和“资源效率”的不同，让我们看一个具体实例，它摘自一本书，书名为This is Lean，描述了两位女士在面临同一个问题时的不同经历。

图2-2中这位女士叫Annie，她感觉胸部不适，怀疑长了肿块。于是她预约了社区医院的医生，图中描述了她的诊断过程。社区医生初诊后，告诉她需要去胸科医院检查；预约并等待后，Annie做了超声和影像检查；然后预约、等待外科医生的门诊，确定还需要进一步生理检验；再预约穿刺生理检查，等待结果；再次预约外科医生，最后得到诊断结果。从初次接触到确诊整个过程花了42天，其中真正接受检查的时间是两个小时，Annie大部分时间都处于焦急的等待之中。

再看第二位女士，Sarah也感觉胸部可能长了肿块，她选择了新出现的一站式胸科诊所，图2-3中所示的是她的诊断过程。到诊所后，护士安排做了初步检查，确认需要进一步诊断，立刻安排医生进行了超声和影像检查，确认肿块的存在，安排穿刺生理检查，结果出来后，医生给出了诊断意见。整个过程耗时2个小时，其中接受诊断的时间为80分钟。

如图2-4所示，护士、医生和检查设备是资源，负责注入价值；而病人是流动单元，接受价值。对应于产品开发，团队是资源，而用户的需求则是流动单元。

上面两个例子中，组织流程的出发点不同，一个聚焦内部的资源效率；一个聚焦用户价值的流动效率，其结果也截然不同。

如图2-5所示，在Annie的例子中，聚焦的是资源效率，试图最大化每个资源环节的利用率，如优化医生和设备的利用率。把镜头对准医生，他们始终忙碌，长长的病人队伍在身后等待。而把镜头对准流动单元——病人，则会发现他们走走停停，大部分时间处于等待状态。

如图2-6所示，在Sarah的例子中，聚焦的是流动效率，把加快病人诊断过程作为目标。镜头对准病人，会发现过程很少出现中断。即使排队，时间也很短。而把镜头对准资源——医生和设备，则会发现他们身后的队伍总是很短，甚至偶尔还有空闲。

比较Annie和Sarah的历程，“42天（1008小时）vs.2小时”，从时间的角度，病人体会到的是500倍的效率差异。图2-7综合比较了关注资源效率和关注流动效率带来的不同结果。除前面已经提到的目标和结果不同外，我们还看到，如果关注流动效率，就必须着眼用户价值而非孤立的资源，寻求整个系统而非局部的优化。

需要指出的是，资源效率和流动效率都重要。以快递业务为例，流动效率关系客户体验和服务承诺；资源效率关系运营成本。我会在第19章讨论资源效率和流动效率的关系，以及如何同步优化它们。本章关注的是，应该以哪个为核心来组织和优化用户价值交付过程，两者的区别是很明显的。

回到产品开发，尽管很多组织都宣称“以用户为中心，价值驱动”，但实践上却总是以资源效率为焦点，进行流程优化，结果往往事与愿违。资源效率的过度局部优化，增加了并行和排队，使用户需求走走停停，经常处于等待状态，在环节内和环节间形成队列，队列又带来额外的工作，如对其的管理、任务的切换及重启，额外知识的传递和再学习等，导致系统整体协调难度增加，让看上去很高的资源效率无法转化为真实的生产力，这是很多传统开发方式共同面对的困境。

从资源效率到流动效率

Don Reinertsen在其经典著作The Principles of Product Development Flow中指出：

在产品开发中，我们的问题几乎从来不是停滞的资源（工程师），而是停滞的产品需求（用户价值）。

问题是，几乎所有传统方法都把资源效率优化作为首要目标，这是有必然性的。

图2-8的故事中，一个醉汉在路灯下踉踉跄跄地寻找着什么，警察远远地看着他。半个小时过去了，警察终于忍不住走上前去说：“你在找什么？”“找我的钥匙。”醉汉回答。警察很快扫视了一下地面：“没有啊，是丢在这的吗？”“不是！”醉汉肯定地说。“那你在这干嘛呢？”警察不解地问。“因为只有这地方有光线，看得见啊！”醉汉反而有些不耐烦了。

对于产品开发组织，时时刻刻都能看到资源，承担改进的主体也是资源团队。那是路灯照亮的地方，自然成为焦点，却并不是真正的价值。为了回归用户价值，精益产品开发必须重新聚焦流动效率，它首先要分析和可视化用户价值端到端流动。让我们看一个具体的例子。

图2-9是某个30人左右团队的看板墙。看板墙以可视化方式呈现了用户需求从提出到交付的端到端过程，直观呈现了团队协作交付价值的步骤，交付过程中的问题、阻碍和瓶颈等。

这里有两个关键。其一，可视化的主体是用户价值的流动，也就是看板系统中流动的主体是用户需求而不是内部任务。其二，要反映端到端的价值流动，也就是从用户问题提出到交付用户解决方案的全过程，包括过程中的问题、阻碍和瓶颈。以可视化的价值流动为基础，团队才能聚焦用户价值，并改善价值的流动效率。关于这一案例的详细背景，请参见第7章。

上例中，团队使用的是“看板方法”，它包含5个核心实践，其中可视化价值流动是第一个也是最基础的实践。而其他4个实践也都与价值流动直接相关。如图2-10所示，它们分别是：显式化流程规则；控制在制品数量；管理价值流动；建立反馈，持续改进。看板方法是最有代表性的精益产品开发方法，这些实践的共同目标是提高用户价值的流动效率，从而顺畅、高质量地交付价值。我们将在第6章详细介绍看板方法实践体系。

协调多个团队才能提升流动效率

上面的实例是精益看板方法在小规模团队中的应用，它打通了组织的交付流程，是实施其他精益开发实践的基础。然而，相对复杂的产品，单个团队还是无法完成用户价值的交付。

图2-11是电信产品的实例，为了交付移动网络方案，通常需要数以千计的人员协作，包含若干个网元设备的联合开发。在解决方案层面，面对的是原始的用户需求；在下一层次，用户需求被分解成为各个网元的功能需求；而一个网元的开发可能就涉及好几百人，所以还需要分解到各个功能模块，成为模块任务。在如此复杂的产品中，单个团队的敏捷，并不能带来用户价值的更早交付和有效反馈的获取。

为此，有人认为敏捷只适合简单产品开发，如互联网应用。但互联网应用就一定简单吗？以外卖为例，图2-12是简化后的外卖服务链接图，它涉及地图、搜索、推荐系统、客服系统、团购系统、支付服务、用户系统、配送服务、商家管理系统、结算系统等，而这些服务和系统可能是不同团队开发和维护的。要及早交付价值和获取反馈，各个团队独立实施显然是不够的。

在复杂的产品和组织中，单个团队或服务的敏捷还无法交付完整的客户价值。

互联网向线下、纵深的发展已是大势所趋，服务的连结变得越来越复杂，经常需要多个团队有效协作才能更快交付用户价值。

在复杂的组织或产品中，产品是分层次的，相应的价值和价值的流动也是分层的，我们最终追求的是顶层用户价值的流动效率。图2-13是前面提及的电信设备，无线产品线的看板系统设计方案，与价值流动相匹配，看板系统也是分层的。

图2-13中，上方是解决方案层面的看板系统，主线是用户需求（绿色卡片）的流动，同时它也包含下一层次的价值项——网元层的功能需求（蓝色卡片），下层的功能需求隶属于上层的用户需求，底层的流动单元向上层价值对齐，实现用户价值的快速交付；图片下方是项目（网元）层的看板系统，每个网元都有自己的项目看板，其上的基本流动单元是功能需求，关注功能需求的流动效率，模块任务与功能需求关联，力求向功能需求对齐，快速完成功能需求。

这两个层次的看板系统，通过功能需求实现联动，让整个组织能够协调一致，快速交付用户的价值。我会在第18章中专门讨论这个案例，介绍分层看板设计背后的原则以及运作细节。

总结前面提到的两个看板系统案例，为了更顺畅、更早交付用户价值，首先要打通端到端——从用户问题到方案交付——的价值流；面对复杂的产品和组织时，还必须连接和融合各个团队或服务的工作，协调一致，实现最终用户价值的快速交付。我们可以将其总结为：“前后拉通，左右对齐”，而聚焦用户价值在整个组织端到端的流动效率是其中的关键。

小结

从“聚焦资源效率”转变为“聚焦流动效率”，是精益产品开发的核心原则之一，为了持续改善流动高效率，我们必须关注端到端价值流动过程，并做到“前后拉通，左右对齐”，在本书第II部分，我们将详细描述具体做法。

本章要点

• 仅仅实现过程的迭代，还不能完全满足更早交付价值和更灵活应对变化的需求。

• 从聚焦资源效率转变为聚焦流动效率，这是精益产品开发的核心原则之一。

• 产品开发中的主要问题不是停滞的资源，而是停滞的价值流动。可视化端到端的价值流动，有助于我们更好地关注和改进它。

• 复杂的产品中，单个团队的迭代是不够的，为了顺畅地交付价值，必须面向价值流动做到前后拉通、左右对齐。

常见问题

问题：我们准备应用规模化的敏捷实施方案，比如SAFe和LeSS等，还需要掌握精益的思想和实践吗？

回答：需要。当前的规模化敏捷实施方案都深受精益思想和精益实践的影响，以SAFe为例，它的全称是Scaled Agile Framework（规模化敏捷框架），由Dean Leffingwell等人提出，已经发展为4.0版本，最早版本的SAFe是在Scrum的基础上引入相关项目和产品组合的管控机制以及跨团队的计划、协调和跟踪实践；从2.0版本开始，SAFe开始更多应用精益思想和实践，强调流动，并把看板作为跨团队协调和价值流打通的工具，在团队层面仍然以Scrum作为基本工具；到了4.0版本，SAFe将看板方法引入团队级别。而SAFe原则，差不多也是精益原则的翻版。可以说，SAFe的演进过程也是其精益化的过程。

每个组织都有自己不同的上下文和既有的现状，不可能完全照搬所谓既定的框架。这就需要应用精益思想和实践，围绕用户价值加以适配和调整。否则不理解目标和原则，照样学样，往往是画虎不成反类犬。掌握和应用精益思想、原则和实践，才能演进出更适合组织上下文的框架，具体哪个规模化的框架反而不那么重要。

问题：精益是不是只适合比较大型的组织，小型组织应用敏捷方法就足够了？

回答：不是。首先，敏捷和精益本来就有许多共通之处。Scrum和XP方法的发明人都说自己深受精益思想的影响。而敏捷的实践，特别是需求和技术实践，让小批量的交付和流动成为可能，这是精益实践能够应用到软件开发领域的一个重要基础。另一方面，精益更强调以端到端的价值流动为基础的流动效率提升，对业务目标的改进更为直接，也为组织的敏捷和精益化变革提供了更平滑的路径。总体上讲，精益和敏捷的结合是相得益彰的。最后，以用户价值为中心来组织产品交付过程，对大型组织和小型组织都是非常必要的。