拼体力，从来都只是弱者的游戏
点击蓝字关注△ 回复“1”领取今日日签和福利大礼包
内容来源：2019年4月20日，在人民邮电出版社主办的《持续交付2.0》新书分享会上，国际持续交付领域专家，持续交付2.0方法创始人乔梁，进行了以“持续交付2.0”为主题的精彩分享。笔记侠作为合作方，经主办方和讲者审阅授权发布。
讲者 | 乔梁 今日笔记达人 | 花七
封面设计 | 子墨 责编 | 嘉琪
第 3579 篇深度好文：5827 字 | 8 分钟阅读
读书笔记•组织管理
本文优质度：★★★★★+ 口感：椰枣
笔记君说：
越专业，越卓越。很多时候，我们以为的离我们很远或者不相关的事物，其实无时无刻不在影响着我们的工作、学习、生活。
今天，就和笔记君一起走进今天的文章，了解一下总在无形影响我们的“持续交付”吧。
以下，尽情享用~
《持续交付2.0》是我过去十多年产品研发管理的经验总结，是我对“持续交付体系”的认识，它不但包括软件基础设施建设，还包括组织管理和软件架构方面的内容，其中，持续交付双环模型是全书的框架。
一、持续交付1.0和DevOps
（一组过程、方法与系统的统称）
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中的工作分成三个大领域（基础设施、组织管理和软件架构），其中基础设施又细分了五个子领域。
并用“七巧板”这个传统玩具做隐喻。即：每一个企业都要根据自己的目标和实际情况，拼出自己不同阶段的不同解决方案。
每个企业的解决方案都有差异，但前提是你要找到你的方向和目标。每个企业都可以去学习别人，但决不能照搬别人。
你可以在这个七巧板中通过不同的组合，挑选任意一个模块，不断改进，甚至改变很多模块，走出自己的路。
*文章为作者独立观点，不代表笔记侠立场。
点击获取精要
点击文末“阅读原文”也可
笔记侠好课推荐：
你的企业是否出现以下迹象：
营销、获客成本越来越高，产品利润却越来越薄，找不到突破口？
发展遇到瓶颈，用尽办法，都很难进一步快速做大？
战略方向经常变，无法聚焦，缺乏持续的竞争优势，团队越来越疲惫不堪？
如果上面三种现象中，你有其中的一个迹象，那么说明你的定位很大可能出现了问题。
6月1-2日上海线下定位大课
全年仅此1次
国内最顶级的两位定位实战大咖
“天图资本CEO冯卫东+里斯全球合伙人张云”
首次强强联授，助你做大品类、做强品牌
早鸟价9800元 原价12800元
仅剩最后50个 早鸟价名额
有关本次课程的任何疑问
扫码海报加班长咨询了解
班长电话：180 5090 7131
如果好看，点击“在看”哦~