第一性原理和精益敏捷的规模化实施

毕宏飞

作者简介

何勉

前言

今天的分享的题目是第一性原理和精益敏捷的规模化实施。我编写的《精益产品开发（原则、方法与实施）》最近也在发售了，我个人觉得这本书是国内第一本系统讲精益和敏捷系统开发实施的书，里面有大量的案例是来自华为和招行的，也有来自平安的，更多的是来自几家创业公司的案例，因此也算是对国内精益敏捷实施案例比较全面的总结。它的名字定义为原则、方法与实施，也表达我希望从三个层面阐释精益和敏捷的实施。

讲第一性原理之前讲一个反面的东西叫做“货物崇拜”，有人听说过这个词吗？货物崇拜这个事情发生在二战时期西南太平洋的小岛上，二战时期美军在这里驻军，等他们撤走以后发生一个很奇怪的现象，这个小岛上兴起一个宗教，人们开始拜飞机，把飞机作为图腾崇拜。他们每年定期会在自己的身体上写USA三个大字母立队行军，拿着木头枪拜飞机，手里拿树叶翻来翻去，大家猜猜他们在干什么？

他们觉得美军在那个地方不需要打猎，不需要捕鱼却有充分的物资，这些物资都是岛民没有见过的。他们认为美军是一个普普通通的人，美军的种种行为是在召唤神灵，神灵是飞机，他们称之为铁鸟。而他们只需要做这些动作这些铁鸟就会带来无穷无尽的物资，他们还认为这些物资原本就是他们的祖先给予他们的，这些铁鸟神灵是他们的祖先派来给他们送货的，结果美军劫持了他们。因此他们觉得自己只要模仿美军的动作，比如这个木枪，比如翻树叶，其实翻树叶是美军的作战文件。他们在模仿这些行为，而这些行为一直坚持到今天，从来没有改变过，以至于已经成为一个宗教了，这就叫货物崇拜，也就是说对那些飞机以及飞机带来的货物的崇拜。他们在模仿种种行为，模仿当然是现象和表象，希望的是看到结果。

其实我们在精益敏捷实施里面也经常看到货物崇拜，比如我们产品经理不叫产品经理，叫PO，项目经理叫PM，我们的需求不叫需求叫故事。我们也搞各种仪式、展会，也搞大规模的敏捷，我们希望对于这种形式的模仿可以带来不同的结果，事实上我们经常看到形式模仿了但本质没有改变。我经历过很多成功的团队，比如平安、招行都是非常成功的，也有很多不成功的。托尔斯泰说幸福的家庭都相似的，不幸的家庭各有各的不幸。我也看到这些成功的背后都有它的共性，不成功的根本原因是他们的表现形式有共性，不管是他不理解，还是各种管理方法、技术能力，还是领导支持不够，但最终表现的形式都是货物崇拜，只在乎形式忘记了实质。今天我会从以下四个方面去分享我们的内容：

1、第一性原理理
2、产品开发的第一性原理理
3、精益和敏敏捷的规模化路路径
4、从第⼀一性原理理反馈规模化的效果

一、第一性原理理

我们不要货物崇拜我们要什么？就是今天我们讲的叫第一性原理，我们需要回到事情的本源，我来解释一下什么叫做第一性原理。第一性原理这个词很早存在，但是最近特别热，在中国是因为李善友，本源是 ELON MUSK ，硅谷跟他说什么就做第一性原理，大家采访他的时候说我们要回到第一性原理，以至于现在硅谷投资人学会了，这个项目不错，可是第一性原理是什么呢？

第一性原理就是要用物理学的角度看待世界，要一层一层拨开事物的表象，看到里面的本质，再从本质一层一层往上走，这是我们说为什么和货物崇拜是相反的。货物崇拜看到的是表象，而我们要回到事物的本质，看看 ELON MUSK 怎么看第一性原理的。

比如他刚做电动车的时候，人们告诉他别做电动车，因为电池成本太高，电动车不可行。他作为物理学曾经的博士生，当然他不是没有毕业，他中途辍学创业的。他说我们要回到第一性原理这个问题，构成电池的基本原材料是金属元素，这些金属元素加起来成本是多少，一算成本大概是多少钱一度电，比如60美元左右一度电，今天已经逼近这个值。他说我们的任务就是无限逼近原材料的成本，因为除了原材料成本之外是人类协作过程之中产生的，我们就有机会把它消灭掉逼近它永远达不到。这是它眼中的第一性原理我们要回到事物的本质看。

讲到第一性原理不得不提到乔布斯，他的第一性原理是我们做一切事情要围绕产品做，我们的公司、管理、技术、销售、创新都要围绕产品做，这就是它的第一性原理。

比如他曾经说过的话，“我创建公司唯一的目的是为了产品，公司只不过是一种手段，可以让真正创造力的人合作打造产品。”所以我们看到公司和管理都是为产品服务的，比如说技术，他一贯认为首先要从客户体验出发，继而考虑技术的可延性，比如销售他坚信我们打造好的产品用户一定喜欢，用户喜欢一定会给钱，所以销售不是问题。大家认为他都是创新之父，乔布斯说“我对创新没有兴趣，我只在乎伟大的产品，只要把产品做好了，这件事本质做好了其他会跟着来”。所以第一性原理要回到事物的本质，从本质出发再一层一层看看我们应该怎么做看其他的方面。

二、产品开发的第一性原理理

那产品开发的第一性原理应该是什么？我们今天的话题精益敏捷规模化实施当然是产品开发当中的，我们要回到产品开发的第一性原理再看看它的规划路径。

我们看看德鲁克管理学之父所说的，任何组织的绩效只能在它的外部反映出来，所以我们看产品开发要看到它的目标，不能从组织中找，要从它的外部找，要看它的用户、价值。管理存在的目的是帮助组织取得成效，他的责任是协调内部资源取得成效。所以说他的第一性原理不在于内部，要取得外部的成效，我们称之为交付有用的价值。我们内部的种种方式，协调资源做计划，改善技术或流程都是为取得外部的成效服务的，这是通用的管理。对产品开发来说要顺畅和高质量交付有用的价值，这三个关键字。顺畅，就是交付的过程外部价值要顺畅，不管内部怎么去协作，采取什么样的流程，用什么样的技术，构件什么样的基础设施，都是要为价值的顺畅交付服务，当然顺畅还要符合质量的要求。最后交付的价值是要有用的，有用的就是用户在乎的，愿意付钱的，可以帮我们带来利益的。如果看一个接力赛，我们看产品开发这件事，我们聚焦是接力棒而不是运动员，我们作为一个4×100米接力赛，要把用户的价值最快的传递出去。

三、精益和敏敏捷的规模化路路径

接下来我们要讲讲精益敏捷规模化实施路径，第一性原理选择我们的规模化精益敏捷实施的路径。当然我们可以从组织层面看，大家也说从组织内部看可能不是一个好的方法。

3.1 康威定律实际案例

有一个著名的康威定律，产品的结构会拷贝组织的结构，如果上来说因为是一个要规模化所以要先把组织改造成一个规模化的组织这是错误的。康威定律告诉我们，如果组织结构定了，会决定产品的结构，系统的结构是产品的结构会拷贝组织的结构。听起来有点抽象，那我们看两个具体的例子。

康威在一篇论文中给了一个例子，他说当年我们有一个团队要做两个编译器，一个叫做 COBOL ，一个叫做 ALGOL ， COBOL 复杂度要比 ALGOL 复杂，有八个人我们评估了一下，于是我们给 COBOL 团队分5个人，给 ALGOL 团队分了三个人。从此以后这个世界上 COBOL 编译分5步， ALGOL 编译分三步，也就是组织的形式会决定产品的形式。

再看另外一个例子，我当年做项目经理的时候，也带过硬件团队。为了激励硬件团队，大家都说硬件团队的鸡汤叫做新机器灵魂，讲讲小型机时代大家怎么做小型机的。

当时说一个公司要做一个东西 VAX11 ，和另一个公司竞争。他们潜入用户的机房，把用户的 VAX11 打开，把电路板一个个打开后，他放心了。大概就是就说威斯特打开机器，拉开电路板的一顺间，他放心了。他在中间看到的是DEC组织结构，不是一块块电路板，他们有这样一个部门做了那个电路板，因此觉得 VAX11 过于复杂，他对 VAX11 各部分连接方式不以为然。因为电路沟通方式拷贝组织沟通中的方式，所以他觉得完全可以超越 VAX11 ，事实上最后他们真的超越了，这不是一个故事，这是一个传记。他们怎么超越 VAX11 ，这个产品最后是超过了，但是最后也被下一代打败了。

3.2 从用户价值出发

如果一开始决定了组织结构，就会决定你产品的结构。所以我们认为如果上来就考虑组织的规模化是不对的，应该避免从组织结构的规模化开始考虑这个问题，那怎么考虑？其实你应该从用户价值出发去考虑，被实际的业务需要驱动，如果用户价值决定组织，我们才要这样组织。而且在今天一个多变的世界里面，用户的价值不断的变化，我们对用户价值的交付需要有灵活性，我们的组织也应该有灵活性，这是对康威原理的一个推论。康威原理说产品会拷贝组织结构，那我们产品要灵活多变，组织也应该是灵活的。所以我们永远应该从用户价值出发，来决定我们怎么去做规模化。

我们从用户价值出发看看，有两类规模化的需求。第一类应该是各个职能之间怎么打通，这种开发方式需求、设计、开发、测试，是拓扑开发方式，不是很好。所以我们要跟拓扑对应，就是迭代开发。迭代可以迭代交付价值，每个迭代之间可以得到反馈，我们把这种方式称之为是 Scrum ，但是真实世界是这么简单吗？

还有业务规划、产品定义，需求之后还有实施和验证。更宏观看还是一个瀑布，只不过这样的瀑布我们称之为 Water Scrum Fall 。因为产品前后端的复杂性，我们要打通端到端的价值流，这是规模化出现的需求之一，这完全要从用户价值出发打通才可以顺畅交付。上面讲到要顺畅和高质量交付有用的价值，才能产生有效的反馈，通过反馈不断调整才能让我们交付的价值是用的。顺畅高质量的价值，才可以及时发现质量的问题，及时的解决，去内建质量才可以保证高质量。

3.3 规模化需求

当然还有另外一种情况，在华为做一个东西的时候，交付一个移动的解决方案，比如 VOIP 、 VOLTE 这样的解决方案需要涉及到至少一千多人做，需要基站、基站控制器、核心网、网管，所以当交付一个解决方案的时候我们分解到一个个刚才说的基站、基站控制器，我们称之为网元。

但是一个网元有几百人在做，它需要被分解到一个个功能模块做。在这个基础上，它的价值也是分层次的，在解决方案层我们称之为用户原始需求，在网元层称之为功能需求，在模块层称之为可分配的需求，需求是分层次的，不可能把一千个人变成跨功能，跨职能的团队。它只有让大家能够对齐，能够协调一致的工作，才能交付最终对用户有意义的用户价值，这是我们规模化要解决的第二个问题。刚才说是端到端打通，怎么协调各个层面，最终交付有效的用户价值、用户需求，这也是它的规模化需求，规模化精益和敏捷的需求。

现在在一个小的组织层面的实施都不能带来真正的顺畅的价值交付，那这就提出了规模化的需求。面对这样的需求我们来考虑怎么样做，下面我会分享一些例子，这种例子里面可能有华为、平安还有一家创业公司的例子。

我们把它称之为不融合、拓展、连接和层次化，这是团队级的实施，团队的融合、拓展、连接。

3.3.1 融合

我们先看一个例子，团队的融合，是两个团队被融合为一个团队。

这是一家做企业网盘的，企业网盘类似于百度云盘，比百度云盘好做还是难做？好做在于规模没有那么大，难是因为需求多样化，有安全的需求、合规的需求，跟现在办公系统集成的需求非常多样化。分两类技术，一类是前端一类是后端：后端做文件系统、集群控制，各种后端的应用；前端是安卓、IOS跟PC浏览器有机的融合，要做出PC的体验。前后端两类技术完全不通用，所以很自然他们有了两个团队，两块看板，分别做迭代。

有一个需求，比如说支持在线播放的需求，在线播放系统这两个应该系同一个需求。他们分别做迭代，两周一个迭代，后端先做前端集成，还有一个单独的缺陷系统，有了BUG先提给前端，前端发现后端的问题提给后端，再做下一批需求，事实上是做新需求，因为新需求有明确的时间要求。BUG如果没有人追，这个BUG谁做是谁的，一点不好玩，除非有人追，就是项目经理追。包括刚才排计划，告诉前端后端已经排到下一个迭代，是项目经理排，所以项目经理在这里是非常关键的角色，是一个枢纽，是一个关节点，也是一个瓶颈。

所以这个看板做的好不好？还是可以的，工作任务的分解和状态清楚，它对产品经理友好吗？不太友好，需求会被拆成什么样不知道，看不到需求端到端的流动，也看不到前后端团队的协作，也看不到缺陷和需求的关联，所以我们要改造它。改造之前我们讲戴明的一句话，“如果不能以一个清晰的过程展示你从事的工作，你不会真正了解你在做什么”。对这个团队来说他并没有清晰的过程展示前后端怎么协作的，BUG怎么关联的怎么解决的。

我们来改造一下看板，做故事看板，前后端要融合在一起。

这个团队当时29个人，还有6个产品经理，他做的故事看板在这里面是一个需求叫做 Pool ，有设计中、待澄清。到这里是白色的，是被澄清以后需求被加工成故事变得更精确了，白色是打印出来手填的。就绪以后开始跟踪故事，所以蓝色到这里结束了。接下来看一下这个 Story ，后面数据、集群、应用、Web、PC，这些是什么？是模块名称。这个蓝色的是开发任务，黄色是自动测试任务，这些任务之间没有时间顺序关系，做完了就放在完成这一列，完成之后是待验证，待验证是需求，所有任务都完成可以拿到。横向被称之为泳道，假设这个都完成，甬道空下来可以进行下一个需求。

这个团队开会的时候，会过看板上的内容，从左到右过，还是右到左？我们的目的是完成需求还是开始需求？我们目的是尽快完成需求，把泳道按照自然可以开始，开始是一件非常简单的事情，团队交付的速度以完成速度决定的，要赶快把这些接近完成的完成。从右往左是优先赶快完成已经开始的需求，有问题及时解决问题。

这是一个端到端的看板，验收是产品验收，所以产品开始到产品结束。产品代表用户，从用户开始，所以是用户价值提出到交付端到端的过程，反映了团队协作、需求的分解和合并、缺陷和问题。

做完这个看板以后我问这个团队副总裁，能不能清晰全面的反映需求和交付的过程？瓶颈和问题能不能在看板上得到及时的体现？比如这里面的需求满了，主要集中在哪个模块？我知道这个模块有问题，所以瓶颈和问题能在看板上及时体现，团队可以根据看板的信息协作做决定吗？他说有点问题，知道从右往左，但是不知道什么时候什么样需求才叫就绪了。

这个时候应该定义更加明确的规则，看板加上规则，让团队可以根据看板的信息作出决定。所以融合是第一个，融合让我们看到融合不是目的，看到端到端的价值流动，可以更加顺畅的发现解决瓶颈和问题，更加顺畅高质量的交付有用的价值。有用的价值是看板解决不了的，是精益创意解决的，但是看板让我们交付完了更快的验证，更快的做业务验证看它有没有价值，没有价值要及时调整，可以起到一定的辅助作用。

3.3.2 拓展

再看第二个叫拓展，这是平安的一个例子。

这个看板跟刚才看板非常像，这个看板在张江，他们的业务在陆家嘴。业务有一天看到这个看板，看完之后说把我们改革需求池，他说他们也要做一个看板，第一件事情把他们整个看板压缩完了叫开发。

他也有测试但是叫做UAT，还要生产验证。他们的需求池要先提出，然后产品设计要有一个初始设计，然后跟领导过，过了之后做交互设计，确认之后再做视觉设计，这是我们做的事情。

这是一个业务看到的端到端的看板，这个很好。我们有时候做一件事情一开始没有条件，我们需要从局部做起，条件成熟的时候需要向两端拓展，拓展的目的要从业务的角度更加端到端，让端到端价值的交付过程更加顺畅，这是一个拓展的方式。

3.3.3 连接

再看第三种方式叫连接，这也是平安的例子。

这个团队比较复杂，有四个异地团队构成：业务方在深圳，底层服务在上海，上海开发完了给成都做应用开发，再给深圳做接收测试。本来上海团队有一块看板，成都团队有一块看板，开发团队是一块物理看板，会担心价值交付的速度很慢，因为涉及到这么多团队之间的交互，于是想方设法把这两块看板连接起来，把业务团队拉过来，所以做了电子看板，但物理看板仍然保留着。电子看板是一个需求做完放在上海分析，分析之后做API开发，一旦进入API开发会把它放在上海团队的物理看板里面。下面信息会更细致，在上海这一段分解成更细的任务，但是电子看板里面没有任务，是业务从头可以看到尾的需求。所以等这个需求一做完，API开发完成相当于成都团队的需求池，所以成都团队把它拉到自己的看板，这个上面的信息更丰富，开发完了再给业务方验证。

我们看看做了电子看板有一个好处，它的度量会变得非常容易得到。

这个叫做累计流图，累计流图只涨不跌。业务已经提出需求的个数，最下面一条线是已经交付的需求个数，中间分析完成的API，开发完成的，开始测试的，开始UAT测试的。从左到右画的线代表这一天提出了25个需求，到12月18号完成了25个需求，说明一个需求从开始到结束要一个月。假设需求排队进去的，第25个需求进来了，这是11月18号，第25个需求出来了是12月18号。可以看需求在各个阶段之间的分布，在最前面的阶段是UAT用户验收测试，说明业务并没有那么急，所以应该及时做验收测试，当然这个需要具体的原因分析，也有可能开发给我的东西不可测试。但是无论如何在UAT这个阶段看原因，所以把它真正拦截起来以后可以端到端看，去分析改进，产生一个系统的改进不是一个局部的改进，所以这里一半时间花在用户验收的过程。

3.3.4 层次化

再看看华为这个例子，产品分层次的，价值也是分层次的。

产品是用户需求、功能性需求和模块需求，如果这样我们产品开发应该怎么做？我们怎么规模化实施？用户需求被分解成一个个故事称之为功能需求，用户需求是最小的交付单位，最下面还有子模块任务，是不可做系统测试的，子模块任务要分解分配给某个团队。上层的解决方案层看板，其实是做规划的，这里的泳道绿色的是用户需求，蓝色是故事，故事隶属于用户需求。他们在解决方案层要约束并行用户需求的数目，就是用户需求数目不能太多了，因为并行的少就逼迫我们把已经开始的要完成掉，让各个团队，各个网元更加对齐和一致，也就是这里泳道数有限的。约束并行用户需求的数目要故事向用户需求对齐，我们追求的是用户需求的快速完成，而不是每个人都有故事在做。都做了一半，都有几个故事没做完，但是需求做不完，所以他们让故事和用户需求对齐了。

再看一下这个看板，整个产品有一个，这个看板有多个，每个网元有一个。这个看板蓝色的是故事，黄色的是子模块的任务。同样项目层面要约束并行故事的个数，我们要让任务向故事对齐，我们追求故事的快速交付。现在的问题是这两块看板能够联动起来吗？因为故事在两边都出现了，我们要追求故事的快速完成，通过故事快速完成实现需求的快速完成。其实这个的确是看板，在这不是看板，这是一个规划方法，规划决定了这里不允许有过多的并行，所以在这里面他们每个星期或者每个月会同步一次，这里是每天同步的。层次化让我们能够应对我们的产品是层次化的，我们的需求是层次化的，所以我们需要一个层次的方案。

四、从第一性原理理反馈规模化的效果

到此为止我们看到从第一性原理再总结一下，我们的目标是顺畅、高质量的交付真正的价值。怎么更加顺畅、怎么更加高质量，怎么交付真正的价值这是我们要考虑的，当然我们还要建立所谓的反馈机制，有了刚才说的各种方法以后，端到端的价值流拉通以后，这条线已经开始实现了，从中间改进让我们顺畅不顺畅，比如上线周期每个月一次，对于某些组织显然不顺畅的。而这里转测试是很长时间转一次，这变成开发完了立刻测试，所以我们要去看，还是回到第一性原理看顺畅不顺畅怎么改进。横的是时间，纵的是有多少定型，斜率是速度。还有各种相应的反馈，去反映我们交付的过程，告诉我们怎么去改进。

最后的总结，我们今天讲了4种方案，我们从第一性原理出发，讲的规模化实施的四种方案，规模化应该被用户需求驱动出来的，被产品需求，被顺畅和高质量的交付价值驱动出来的。在此基础上我们要考虑不同的方案，比如团队级别开始实施，考虑融合。比如这是两个看板怎么融合起来，怎么连接上下游，怎么从一个地方开始向上下游拓展，怎么做出一个层次化的路径，但是最终都服务于顺畅的交付。

到此为止不得不说规模化的敏捷，因为今天规模化敏捷、规模化精益实施现在有很多流行的方案。最近有一个人Ron Jeffries写了一个《软件开发本质论》，他评价框架为什么突然流行，他的评价我非常认同，他说大公司开始做敏捷很自然的，因为我们是大公司所以需要大规模的框架，怎么可能用很小的看板东西。他说我相信他们会取得成功，然而那只是咨询公司的成功，而不是实施敏捷和精益的公司。大公司需要的并不是大规模，公司需要真正敏捷的方法和技术本身，我们不需要的是货物崇拜去模拟，去模仿，去搬一个框架。我们应该回到问题的本质，问题的本身，回到我们的目标来决定我们一起看怎么顺畅，怎么快速，怎么高质量的交付价值这是我们的问题，所以我们必须回到问题的本质。

这是Denning，他说微软实现敏捷规模化的16条原则，我们追求的是敏捷的规模化，而不是规模化的敏捷。也就是说我们要让敏捷变成整个公司规模层面都实施的一种方法，而不是一个规模化的框架，这个明确要考虑，敏捷规模化我们要考虑怎么顺畅交付价值，规模化这个事情的确存在，但它应该不是被组织的规模弄出来，而是架构需求交付的复杂性，用户需求复杂性驱动出来的。

我们为了顺畅和高质量的交付用的价值，第一性原理，在每个系统探索中存在第一第一性原理，第一性原理不能被省略和删除，也不能被违反，到这个层面我们认为有了高质量的交付价值，并打通端到端的交付过程，不断反馈让价值顺畅流动，快速的价值反馈和验证这是关于有用的，来探索真正的价值，这才是我们要做的东西。规模化的角度来看敏捷，是我书前言写的东西，我称之为精益和敏捷宣言，敏捷宣言是2001年发布的，当时叫敏捷软件宣言，今天我们看价值的角度需要对它进行拓展。我们个体和互动重于流程，但是我们要连接和打通组织的各个职能确保协调一致的行动，这是我们要做的这是规模化的需求。我们尊崇可工作的软件，重于面面俱到的文档，但是更重要的是要交付价值，要聚焦端到端价值流动以快速灵活交付真正的价值，客户合作重于合同和谈判还不够，在今天选择权越来越向用户侧转移的时候，我们要与客户建立更大目标，以最大优化业务成果。我们尊崇响应变化，但是响应变化是被动的，今天要有计划和系统主动的试错以支持我们有效的学习和创新，所以今天时代不同了，我们提出比过去高得多的要求，敏捷规模化是存在的，但是避免不必要各种规模化的框架，更不要做所谓的货物崇拜，我们要回到问题的第一性原理交付真正有用的价值，这是我今天讲的整个的主题，谢谢大家。