2019，软件产品研发理念与管理模式新纪元

本文来自于2019年4月20日《持续交付2.0》北京线下交流会的主题分享。

《持续交付2.0》是我过去十多年产品研发管理的经验总结，是我对“持续交付体系”的认识，它不但包括软件基础设施建设，还包括组织管理和软件架构方面的内容，其中，持续交付双环模型是全书的框架。

1.持续交付1.0

传统的企业应用软件项目，发布周期时间一般都比较长。项目都是从完整的需求收集开始，经过瀑布模式开发以后，将软件部署到生产环境下。

此时，对于软件开发团队来说，一个版本就结束了。这是大多数传统软件公司的开发模式。

也就是说，软件项目团队仅负责从代码提交到发布这个阶段。而对于互联网公司，还要扩展到“产品监控”这个节点。这样就形成了一个闭环，这个闭环也是一个迭代开发的过程。

我把这一个环叫做持续交付1.0，关注的就是从代码提交开始，一直到能够保证它能够正常在生产环境运行。

它更强调的是快速把代码放到生产线上，让用户能用到。这也是目前DevOps聚焦推动的一件事。

2.DevOps （一组过程、方法与系统的统称）

讨论“持续交付”，就不得不提一下“DevOps”。DevOps术语是由当时在传统软件项目上工作的咨询师 Patrick DeBois提出的，它是一组过程、方法与系统的统称，用于促进开发 (应用程序/软件工程) 、技术运营和质量保障 （QA） 部门之间的沟通、协作与整合。

案例1：Flickr网站

DevOps的引爆点实际上是2009年。十年前有个互联网图片分享社交网站，叫Flickr，有点像现在手机端的Instagram。

2009年，Flickr的一个开发工程师和一个运维工程师在Velocity大会 （一个国际著名软件技术大会） 上做了一个分享，题目是《Flickr每天部署10次》，通过开发团队与运维团队紧密合作，使用尽可能相同的软件与工具，达到高质量快速部署。在这之前，整个软件行业普遍认为这是不可能的。

2010年，我查了一下Flickr网站的公开资料 （http：//code.flickr.com） ，该公司在当时的发布次数如图所示，一周内部署54次，这54次里包含了23个工程师的636次代码变更。

案例2：Etsy公司

Etsy的公司 （国外电商网站，模式类似淘宝） ，2010年时,主要卖手工制品，像手工制作的钱包、皮夹等。

2010年，该公司启动持续交付之旅，截止到2012年，每天可部署50多次。如果按每天工作8小时，相当于15分钟就会有一次部署，如下图所示。

所有人向同一个代码仓库提交代码变更。每次提交代码变更后，立即进行自动化构建和测试 （需要15分钟左右） 。只要自动化测试通过，代码就会部署到生产环境上。即便是现在，在国内也是比较罕见的工作方式。

案例3：领英公司

2016年，领英有3000名工程师，从图中，大家可以看到IOS、安卓和Web网站的发布次数。 Web端、API、IOS、安卓提交代码变更的次数总计一周905次。

为什么会有这样的工作方式呢？

在2016年之前，他们曾经做过一个设想，这个设想就是每年发布12次，为了达成这个目标，做了完美的时间规划。即：前3周进行开发工作，在第三周的星期四开发完成，可以创建发布分支，并交接给测试团队进行测试。

经过四天的测试之后，到第四个星期的星期三就可以发布了。发布后交给运维工程师。此时开发团队可以启动下一个版本的开发。国内的很多公司直到现在也是采用这种规划方式的。

然而，实际情况并没有像规划上面那样真正的发生过。现实状态是：前3周仍旧是在开发阶段，到了要转测的时候，由于期限已到，为了达到时间点，开发人员匆忙提交代码 （很可能是半成品） 。

创立发布分支，测试人员进行手工测试，结果会发现很多缺陷。更可怕的是，到了最后时刻，还有一个新功能要添加到这个版本发布。

开发人员经常说：“马上就好，只是一点点改动，放到这个版本里就可以了，肯定没有问题”。结果一测试，发现还有缺陷，只好延迟发布，然后再测试，又发现问题。来来回回又用了一周时间，这个版本才能发布。

保守一点估计，我认为，现在国内软件公司中，仍旧有50%左右的公司处于这种状况，但对于领英来说，他们认为，这是无法忍受的。

第一 ，开发人员不能忍受，因为加班太严重，压力太大。

第二 ，产品经理不能忍受。因为他们希望能够更多地尝试新的想法，更快得到真实的用户反馈数据。

第三 ，管理者也不满意，因为没有办法调动资源，所有资源一直在救火。人员压力大，离职率就高，团队就很不稳定 。

所以，2015年的时候，领英启动了一个项目，叫“航海家”。这个项目对整个领英产品做了改造，同时也希望变换一种产品研发工作方式。于是，制定了一个目标：3×3×3。

第一个3是指 ：要示每周Beta （测试） 发布3次 （周一、周三、周五） ，将新版本推送给外部测试用户。如何实现这一目标呢？通过实现第二个3来完成这一目标。

第二个3是要求 ：每天发布3个Alpha版本 （上午11点、下午1点和4点） ，即每天都有三个内部版本，给公司内部人员体验。其目的是让内部人员更快更早地拿到新增的功能进行体验。那么，又如何实现这一目标呢？

第三个3 是从开发人员提交代码到能够拿到一个试用版 （Alpha版本） 给内部人员进行体验，这个时间长度为3个小时。

这个时间包括代码提交后，code review （代码评审，指在软件开发过程中，通过对源代码进行系统性检查的过程） ，经过静态扫描、构建发布包、单元测试、界面测试、场景测试，然后是Alpha发布。

下图是团队的工作流水线。

3.DevOps的文化与工具

▲ 长按图片分享给需要的人

我认为DevOps运动最重要的是文化与工具。文化里包括：数据验证文化、快速反馈文化、工程质量文化。工具构建时需要考虑的因素是：员工自服务、让机器等待、流程自动化。

思考的方向是自上而下，要做到数据验证文化，就必须有快速反馈文化；要有快速反馈文化，就必须有工程质量文化。

所以顺序很重要， 你思考的方向是从上到下的，但是，行动方向应该是自下而上的 。

工具部分也是一样。什么是员工自助化？就是当一个团队成员要完成他自己一项工作时，不需要其他人的协助。

比如说，当开发人员想发布版本时，要找测试人员测试、运维人员审批。假如，我能够自助完成这些审批流程背后的各类要求的话，我就不需要找很多人，这样，所有人都节省时间。

二、持续交付2.0之双环模型

1.持续交付2.0

持续交付2.0的起点是业务价值探索，而非软件需求，强调业务问题的完整闭环。

也就是说，所有的起点都是从想法 （问题） 出发，设定目标，分析洞察，找出尽可能多的解决方法，然后开发上线、数据评测，得到数据之后，决定是发布还是下架，然后再次快速迭代。

▲ 长按图片分享给需要的人

持续交付2.0的双环模型强调的是从问题出发，所有的事情都应该从问自己下面的问题开始。问题是什么，目标是什么，有多少种方案，如何从这些备选方案中选择。这部分才是真真正正我们需要首先思考的问题。

持续交付1.0和DevOps的落地通常都聚焦在从需求开始，而不是从产品想法开始，我们都在努力地把我们的需求变成软件，发布给用户，但是并没有真正形成完全闭环。

我并不是说后面这个验证环不重要，恰恰相反，我认为非常重要，但是其更多的是在讨论如何正确的做事。

▲ 长按图片分享给需要的人

亚马逊的贝佐斯和Facebook的扎克伯格，他们所坚信的产品理念是“一万次实验法则”。这两句话真正体现硅谷互联网公司产品的研发理念。

我认为，只有在先进的研发理念指导下，才能够设计出先进的产品研发模式。为了支撑先进的产品研发模式，就必须重新定义这个流程模式中各环节的输入和输出，以及职责与参与者和决策机制。

这样，才能知道每个环节应该做什么事情，要做到什么标准，以及如何达成这些标准。

当我们提出问题时，事实上我们是在问：

客户在哪儿？

他遇到了哪些问题？

现在他们是怎么解决这些问题的？

为什么你会认为你的解决方案比现在的解决方案优秀？

无论进军2C领域，还是2B领域，你都逃不开这几个问题。所有的问题都会有一些解决方案，你的方案到底差距在哪里？

当你自己在头脑中谋划出这些问题后，下一步是回答类似下面的问题：

如何衡量你找到了你想要的这些客户？

如何衡量你的方案特别优秀？

这就是在定义明确的目标，即：找到问题后，再去找到衡量问题是否被解决的标尺，怎么看你达到了你的目标。如果这两个问题清楚了，才会有下一步的问题：

到底有多少种途径找到我的目标客户？

他的问题有多少种解决方案？

这些解决方案的投入和产出到底是如何评估的？

正如《这就是OKR》一书的作者约翰道尔所说：“解决一个业务问题，一定并不只有一种方案。”

事实上，人们经常会沉迷于自己想到的解决方案，因为解决方案是我们自己想到的，像自己的孩子一样。谁会说自己的孩子不好呢？

科学探索环就是为了破除心中的障碍，一定要考虑问题到底有多少种解决方案。如果你认真地回答前两个环节的问题后，你能找到比你现有的解决方案还要好的解决方案。

在“共创”这个节点，你可能找到了10个、20个，甚至50种解决方案。那么，如何决策哪些方案应该实施呢？此时，“精炼”环节就十分重要了。

我为很多产品研发团队提供咨询时，总会去提到一个问题：你现在遇到最大的困难是什么？基本上会得到三个固定的答：

第一，我们需求太多。

第二，我们人手不够。

第三，我们这个软件系统特别复杂。

试想一下这三个答案有没有解决办法？……不用想了……大部分情况下，这三个问题都不是真正需要解决的问题，它们只是结果或者表象，而不是问题。

如果一个产品没有很多很多的需求，说明这个产品已经快死掉了。

任何一个组织都不会雇佣超过它认为的最大员工数。另外，也没有哪个负责人会说自己负责的系统是简单的。

想要解决上面的问题，最重要的就是“精炼”环节。从众多可能的解决方案中选择其中一部分，进行快速验证。

快速验证则是后面环节要解决的问题，通常来说是只要以正确的方式做事情，你就能够做到快速，但前面更多的是科学分析和探讨如何选择正确的事情来做。

▲ 长按图片分享给需要的人

这两个环是相辅相成的。如果快速验证环的成本足够低、足够快，就可以在相同的时间内做出更多次的科学探索。

如果科学探索环产出的解决方案是一个能够快速实现的方案，也会令快速验证环的反馈时间更短。

假如探索环产生的解决方案就是个巨无霸，也会导致后面的快速验证运行很慢，导致结果反馈周期较长。

就像我们有一份搬砖的工作。如果在科学探索环里，确定的是“一块砖”，那就很容易在快速验证上完成了。

但如果是“一整吨砖”，你的验证速度很难比“一块砖”时更轻盈。

正如腾讯公司副总裁曾宇所说：

敏捷，就是极致地缩短每一次尝试、反馈和决策的时间 。

对技术来说：更厚的积累；

对组织来说：是更小的团队和更合理的研发运营模式；

对个人来说：是更强的工程技术素养。

2.持续交付2.0的两个关键点

精益思想 与 系统思考 是持续交付2.0的指导思想与落地工具。精益思想的核心是“消除一切浪费”。软件产品的生产浪费在哪里呢？就是那些无用功能、等待、工作项的移交、库存、软件缺陷等。

▲ 长按图片分享给需要的人

我们的日常活动有两种类型。一是增值活动，二是浪费。在“浪费”这个类型中，又可分为“必要的浪费”和“不必要的浪费”。我经常问大家：“测试是不是浪费？”很多人认为不是。

然而，从客户价值出发，“测试活动”就是一种浪费，但对于企业来说，它是有价值的活动。所以它应该被归到“必要的浪费”这一类。项目管理也是一样。

我们要消除所有不必要的浪费，同时，尽可能减少必要的浪费。如果你秉持消除一切浪费的思想，你就可以从另外一个视角审视当前的软件开发流程和生产流程。

当年，我与同事去某公司做持续集成实践的指导时，客户会问：“为什么我们应该快速地修复失败的构建？我们的发布时间还在两个月以后呢……”

因为在持续集成实践中要求，如果你的某一次构建失败了，是不允许其他人提交新代码的，因为此时再提交新代码，构建也会失败。并不能发挥持续集成的快速反馈作用。

如果修复构建所用的时间长，就会累积很多未提交代码，而潜在问题的可能性和数量就会增加，而这可能就会导致下一次构建失败的可能性变大。修复就会花费更长的时间。这就形成了一个渐进增强环了。

在这个渐进增强环中，你唯一能够有所行动的点就是在“快速修复”这里，其它节点都只是结果，可以观察，但无法采取行动。

修复的方式有两种 ：一是再次提交代码，把问题修复，二是把引起问题的代码删除，这也是最快的修复方法。

3.持续交付2.0里面的四大基本工作原则

① 坚持少做

为什么要坚持少做呢？大家刚开始就会纠结这一点。

比如“我为什么要坚持少做？我有100个人为什么还要坚持少做？”其实他的意思是说“我有100个人，怎么能只做一点点事情呢？”

事实上，持续交付2.0中所强调的“坚持少做”，并不是说100个人做一点点事情，而是说： 当你在想“究竟哪一件事情对你最重要”的时候，你才能够真正思考要投入多少资源把它完成 。

任何人都想把他想到的所有事情做完，但你永远有做不完的事情 （需求） ，永远有事情在等着你。

所以，作为一个管理者，唯一要思考的就是怎么少做。只有坚持这一个观点，才能发现真正重要的东西。

② 持续分解任务

想要“少做”，就必须将大问题持续分解成多个小问题，在其中找到那几个真正最重要的问题，把它们挑出来，然后去做。

而在做的过程中，因为问题比较小，所以也能够得到快速反馈，从而验证自己最初所定义的问题是否正确。

例如，我们在开发软件需求的过程中，可能某个大需求需要做5天，那是否意味着你要在五天之后全部做完，才提交代码变更呢？

显然不行，因为你没有和其他人的工作成果 （他们的代码） 进行集成，你就没有得到真实的反馈。

所以，对软件开发工程师来说，也要将这个需求分成很多次的少量代码提交，快速验证每行代码是否正确，是否影响到别人的工作了。

这也是精益思想中所强调的，做好每一个环节的质量管理，避免在后期发现问题，带来更大的浪费。

③ 坚持快速反馈

如何支撑软件的快速交付与快速反馈呢？当然是加快交付频率，获取更多的机会将功能及时发布到生产环境中，但是在保障软件质量的前提下。一旦频率提高，就不用过分在意功能完成了多少。

这种方式会让工程师很高兴，因为他们不需要在版本发布前加班，火急火燎赶进度。产品经理也很高兴，因为他不需要再等一个月才把自己设计的功能发出去。

所以，事实上他的产品研发理念改变了整个的研发模式和思考模式，即： 只有高频 发布和 短周期交付，才能有更多 试错 的机会 。

对于大团队来说，尽量减少没有必要的沟通，可以减少很多浪费。

④ 持续不断改善

“持续不断的改善“这一点来自于丰田管理。 任何时候、任何地方你都可以改善。

没有人能够一下子立即消除所有的浪费，它是一个漫长过程，甚至可以说，无法消除所有的浪费。

但是，我们必须学习，如果识别这些浪费，并在下一个目标里程中，将消除这些浪费做为正式目标。从而不断提升能力，消除它们，这也就相应增加了更多的增值活动时间。

持续交付2.0本身关注的是端到端的业务协作，并不仅仅是产品开发、测试和运维，还要与市场、业务联动。

持续交付2.0应该成为企业的组织能力，应该具有可持续性。这一点是我特别要强调的一点。

可持续性并不是每周冲刺加班，那样很难具有可持续性。因为， 最开始可以拼体力，但一段时间之后， 只拼体力就无法做到可持续了 。

我再次强调的是，我们要能够提供真正的业务价值，这个才是目标。

4.持续交付七巧板

我将持续交付2.0中的工作分成三个大领域 （基础设施、组织管理和软件架构） ，其中基础设施又细分了五个子领域。

并用“七巧板”这个传统玩具做隐喻。即：每一个企业都要根据自己的目标和实际情况，拼出自己不同阶段的不同解决方案。

▲ 长按图片分享给需要的人

每个企业的解决方案都有差异，但前提是你要找到你的方向和目标。每个企业都可以去学习别人，但决不能照搬别人。

你可以在这个七巧板中通过不同的组合，挑选任意一个模块，不断改进，甚至改变很多模块，走出自己的路。