如何开始我们的 DevOps 转型之旅？
如何开始我们的 DevOps 转型之旅？
导言
本次分享是《DevOps Handbook》的第二部分，DevOps 从哪里入手，可以说这一章在全书中是承前启后的一章，主要想要解决的是我们要做什么的问题。 第一章简单回溯了DevOps的发展历史并提纲挈领的介绍了核心的三步工作法，第三章开始会深入每一步工作法并详细介绍里面的优秀实践。 在第二章里主要关注的是企业如何去选择合适的价值流，并在价值流中进行分析改进。同时关注整个企业组织架构的建设，因为企业组织架构和管理制度是领导者发挥卓越领导力的基础。最后一部分会探讨 Dev 和 Ops 之间融合的实践方法。
今天分享分前两部分，第一部分会介绍如何选择合适的价值流，第二部分通过具体的方法理解并可视化价值流。
开启DeVOps转型之旅
相信小伙伴们或多或少对 DevOps 已经有一些基本的认识，并且也希望借由 DevOps 完成整个企业 IT 价值流交付链的建设。
很多人在真正开始做 DevOps 之前总是会有一些问题，比如我们应该如何从什么地方开始DevOps 的转型之旅，都有谁需要加入这场 DevOps 的变革，如何建立 DevOps 转型组织，如何确保成功。
每当看到这些问题的时候我总会想到“纪念碑谷”这个游戏，我们在做DevOps转型的时候就好像我们是“纪念碑谷”里的主人公，目标相对比较明确，业界已经有一些非常优秀的公司，像亚马逊、谷歌、BAT、招行等，他们在实施 DevOps 过程中在各自的领域取得了非常瞩目的成功，而我们想要达到这个目标，过程和路径实际上并不是十分清晰，有时候会误入歧途，把有限的资源用在不合适的地方。
所以经常有人会说我们认可 DevOps 的理念对于业务价值的贡献，那么应该如何去做DevOps 呢，但是他们从来没有提及我们为什么要做 DevOps，DevOps 要解决的是什么问题。在本次分享的第一部分，我们来谈谈从什么地方开始我们的 DevOps 转型之旅。
2.5、 选择合适的价值流
在开始前简单分享一下价值流的概念，价值流也就是VSM（Value stream mapping），是本书中非常核心的一个概念。
价值流图其实源于传统制造行业，源于精益思想。价值流图是通过一种形象化的方式，把整个产品生产过程中包括从原料一直到产品交付用户这样一个过程，让它变得可视化。
价值流图的主要目的是发现浪费和消除浪费，这也是精益思想中的一个核心理念。
在价值流图中如果想要消除浪费，核心关注两个时间指标，VAT 增值活动时间，NVAT 不增值活动时间，通过把增值活动时间无限放大，不增值活动时间缩小，来达到整个交付效率的提升，减少整体的浪费。
价值流图中还有两个核心状态，当前状态、未来状态，企业通过制定合理的未来状态，和当前状态去做对比，识别状态之间的差距。在这个过程中通过持续改进，典型的方法就是PDCA 的流程，通过持续改进的方法，逐渐把我们从当前的状态演进成未来想要达到的预期状态。
在做 IT 时，它不同于传统的制造行业，对于 IT 流中很多信息的可视化实际上是比较困难的，而且也不容易被量化，即便如此我们同样可以借鉴传统制造业的方法来帮助我们识别 IT 交付价值流中的各个阶段，并帮助我们发现其中的约束点和瓶颈点，通过持续改进，不断识别和改进问题。
为什么价值流的选择会是我们的第一步
为什么价值流的选择会是我们的第一步，上边的图片是阿波罗11号第一次登上月球的纪念照，这是人类航天史上载入史册的一幕，这一步的选择至关重要。
实际上我们去做 DevOps 转型的时候，价值流的选择包含了很多深层次的概念，其中就代表 DevOps 转型的工作难度，你要在什么地方、在哪个业务开始 DevOps。
其次会影响哪些人和组织会被引入变革，在这个过程中我们会跟谁去打交道。还有合理利用有限的组织资源和机会。这个事情是需要深思熟虑的，主要的原因在于如果我们这个转型的第一步方向出了问题，不仅浪费了有限的企业资源，同时也打击了企业去变革的勇气和积极性。
最终的结果是错失时间窗口和市场机遇，导致企业危机会不断放大。上图有一行小字来源于接下来的案例主人公，这句话真实反映了这种情况，“尤其当我们的企业处于危机中的时候，我们可能很难有太多的机会不断去尝试”，我们的机会是有限的，所以第一步方向选正确是对我们未来的转型奠定一个非常坚实的基础。
Nordstrom DevOps转型案例
《DevOps Handbook》引用了 Nordstrom 的转型案例，接下来让我们看一下Nordstdstrom 的案例。简单介绍一下Nordstrom是美国著名的高档百货商店，2015年时达到将近135亿美元的销售额，对于一家传统的线下百货商店，在互联网时代电子商务越来越挤压整个市场的背景下，是如何达到这样的成功呢，这其中的核心秘密就是企业的 DevOps 转型。
这个案例发生在2011年，案例中提到了在 DevOps 转型之前，整个企业 IT 运作的方式是优化费用支出，即 Optimizing for Cost。
这体现在各个方面，常见的做法包括把很多技术团队进行外包，每年一次的计划排期，以瀑布模式实施软件项目开发，并且每次发布包含大量新内容。
其中最后一条提到，这样做的结果是达到了将近97%的计划达成率，这点其实是很有意思的，虽然通过技术外包和瀑布式开发模式，每次的计划达成率都非常高，但实际上这样的结果还是无法满足企业五年的战略规划，背后深层次原因在于当时整个在线电子商务的迅猛发展，对整个企业的发展带来非常大的挑战。
如果继续保持以前这种遵循计划重管控的方式开发演进就很容易导致这样的结果，就像前诺基亚的 CEO 所说，我们可能并没有做错什么，但不知道为什么我们输了。这个并不是真实的消息，应该是网上有人杜撰出来的。
正因为 IT 交付价值效率和企业发展预期之间的差距，Nordstrom 被迫开始了转型。转型的核心理念，就是从费用的优化转向对速度的优化，他们做了几件事情，建立了独立的团队，持续调整和更新计划，通过快速开发迭代不断满足用户需求，最终达到了以往四倍的交付速度。
整个案例中主要有四点值得大家借鉴和参考，
第一是专注，整个改进过程中，Nordstrom 并没有选择一次铺开，让所有的业务都去做DevOps 转型，而是挑选了一些特定领域进行实验和学习，这些领域实际上都是当时没有达到业绩指标的团队和业务方向。
第二，通过转型，他们达到了初期的成功，并且证明了这种方式在组织内部是可以被复制的。
第三，通过改进，帮助没有达到业务目标的部门去实现业务目标，这使得他们更愿意接受新的工作方法。
第四是度量，通过可视化，减少前置时间，并识别改进点和改进结果并不断迭代改进。
在整个转型过程中，实际上他们面临着一个非常尖锐的问题，因为当时业务的需求扩大了四倍，有人就提出整个团队是不是也要相应扩大四倍，但是当时负责 DevOps 转型的 IT 主管却选择了另外一条道路，通过引入持续集成、内建质量和集中部署等优秀实践，不断提高 IT 生产效率，最终达到交付时间和失败率的下降。
在案例的最后，这位 IT 负责人也提出 DevOps 转型之旅远远没有达到终点，但是通过这一系列的改进，他们坚信自己走在一条正确的道路上，整个团队也见证了 DevOps 对于企业 IT价值交付的巨大贡献，变得更加主动和拥抱变化。在本次的分享中我们也会详细介绍每一个领域到底应该怎么样去做。
Greenfield vs Brownfield
首先需要解决的问题是，我们要在什么地方开始选择合适的价值流。通常我们所面对的大多是两种类型的系统，一种叫 Greenfield，一种叫 Brownfield，其实这个概念来源于建筑行业，Greenfield 代表的是一个全新的项目或者这个项目处于一个初期阶段，这种项目采取了一些全新的设计，拥有一个独立组建的团队，无需担心现有的代码流程组织的阻碍。
Greenfield 项目往往适用于一些新技术方法去尝试。Brownfield 代表既存产品和服务，这样一些产品和服务往往已运行很多年，有沉重的技术债务，而且难以满足组织交付能力的需求。
很多人会认为 DevOps 更加适用于新项目，也就是 Greenfield 的项目，但事实上 DevOps 不仅对 Greenfield 项目，对于既存的项目同样是有效的。通过统计发现，超过半数的转型案例是来源于右边这种 Brownfield 的项目。
背后深层次的原因在于，现有的产品和服务已经长期的提供线上服务并创造价值，客观体现了组织交付能力和需求的落差，当这样的一些现有系统实现转变，它所带来的客观利润实际上是非常可观的，而且在这些传统团队里，他们普遍认识到传统的方法是不足以支撑业务目标的，所以他们更有动力去迎接变化、拥抱变化，采用新的方法改进现有状态，以达到业务目标。
当然，对于现有系统的改造会伴随很多阻碍和问题，比如它缺乏很多自动化测试和耦合的架构等，在本书的三步工作法中对这些具体的实践方法都有一个明确的定义。
SOR vs SOE
第二种系统类型划分的方法是 SOR 和 SOE，这个概念最早是由一家 IT 咨询公司提出，也就是所谓 Bimodal 的概念，Bimodal 用中文翻译过来就是双模 IT，这个概念也非常火热，尤其是在金融领域中。
其中 SOR 更类似于现有的 ERP 或 HR、财务等系统，关注点在于业务的可靠性和稳定性，这类系统中数据的正确性是至关重要的，而且来自于外部监管规格要求也比较高。这就自然的导致 SOR 系统会关注性能，变化节奏更慢，核心理念是 Do it RIGHT。
另外一种系统是 SOE，这种系统类似于电子商务和移动应用，更关注业务的敏捷交付，关注用户价值导向、快速迭代以及如何更好的满足需求，核心理念是 Do it FAST。
SOR 和 SOE 在企业中往往是并行存在的，但是由于两种系统的显著差异，往往容易让大家区分对待。但是在今年的 DevOps 状态报告中，明确提出了 DevOps 是可以弥合这两种方式的最佳方案。
DevOps弥合两种模式
通过今年的 DevOps 状态报告的数据显示，高效能组织同时可以取得高质量和高效率，对于 SOR 和 SOE 这两类系统，不应该被割裂对待，因为对于一个复杂的系统来说，当系统耦合性较强的时候，它的变更频率适用于木板原理，短板往往成为整个系统的瓶颈点，在现有的系统中往往就是 SOR。
同时无论是 SOR 还是 SOE，同样关注快速、安全和简单的变更。Greenfield 产品或者说SOE 产品，往往基于底层可靠的 SOR，所以保证 SOR 和 SOE 的整体优化才是 IT 系统服务优化的一个最佳出路。
选择合适的初始团队
当我们决定要在哪个系统领域开始 DevOps 转型的时候，接下来要面对的就是如何去选择一个合适的初始团队。
上边这个图非常有名，反应了团队的技术认同度曲线，来源于摩尔提出的跨越鸿沟的概念。在这个图中可以看到，第一领域、第二领域代表了更愿意拥抱变化的用户群体，后面是更加偏向于保守和跟随大流的部分，他们之间有一条明显的鸿沟，而非渐进式的线性变化。
当我们想要开始一些变革类工作的时候，位于鸿沟左侧的团队是更加优先的选择。在组织中开始进行 DevOps 转型的时候其实更加适用于这些创新性的团队，因为他们往往认同DevOps 的理念和实践，往往会拥抱变化和具备更新现有流程的意愿，也就会更加配合工作开展，同时这类团队对风险承受能力和快速试错有一定认识，不会轻易的退缩。
在真正去尝试转型的时候，务必要注意的是避免在初始阶段全面铺开。即便有管理层的支持，也是要采取循序渐进的过程。
今年 Facebook 发表了一篇非常著名的文章，介绍了他们整个发布系统的演进过程，从主干开发分支发布到主干开发主干发布，这样一个发布系统，在一年内首先覆盖了50%的研发人员，同时对生产环境流量从0.1%到1%再到10%，逐步切换，完成了核心系统的过渡。
避免全面铺开，核心在于我们要识别收敛目标，要确保初期成功。同时让初期成功在组织内复制，总结成功的经验，减少后续转型的困难度。
在组织中拓展DevOps
在 DevOps 转型过程中，初期的成功是非常重要的，如何保证初期的转型是可以获得成功的，书中介绍了几种方式。 第一，把大的改进事项细分，通过渐进的方式去改进。 第二，加快改进速度，让改进效果显现。 第三，及时发现错误并及时调整，当我们在一个小的转型工作中发现方向出现了问题，可以及时调整方向，及时调整优先级。
其次，在整个迭代过程，基于不断的学习去调整后续转型的决策。初期的成功可以带给我们的是提升整个转型团队的信用，提升我们的影响力，扩展支持群体。
体现在三个方面，
第一，寻找早期支持者，企业转型离不开真正的业务团队，如何找到那些合适的团队，找到具有创新意识的团队，并且这样的团队最好是在组织内部有影响力的团队，可以提升变革的可信度。
第二，积累成功案例，通过影响更多的团队和价值流，引发从众的效应，可以帮助相对保守的团队看到这些初期的效果，以至于他们愿意接受这样的改进方式。
第三，回避顽固保守者，保证这样的改进可以持续成功。
本章总结
总结一下，这一章核心理念如何找到合适的价值流，如何找到合适的业务方向去开始DevOps 转型。书中介绍了几种系统类型，也介绍了不同的团队类型。
总结过程中引用了一个理论，这个理论是由管理大师彼得·德鲁克提出的，翻译过来是大鱼小池的效应，这个效应更多是认知方面的一些理论。举例来说，有一万块钱，如果跟一千块钱比，我可能是富翁，跟一百万去比，我可能是一个比较穷的人。
当我们在跟不同人比较的时候，我们的心理落差不一样。回到 DevOps 转型过程中，通过大鱼小池的效应，可以帮助我们在有限范围内获得更多的资源，相当于在小的鱼缸里，这只鱼可以享受更多的水，水就是我们可以调动的资源。
同时在这样一个小的团体内，一个细小的成功可能是至关重要的，有助于提高转型的信心和主动性。同时在小的范围内尝试转型，尝试一些新的技术、新的方法，不会影响整个组织，小范围的试错不会影响整个组织的效能。
当我们在一个小池内逐渐成长为值得信任或者我们的实践理论方法得到验证之后，我们再去更大范围扩展，以一种循序渐进的方式帮助 DevOps 转型可以获得有效的成功。
2.6、 理解并可视化价值流
第二部分是理解并可视化价值流，在第一章中我们已经找到了需要改进的业务方向，接下来要做的就是去识别整个价值创造过程中的所有环节。
精益所倡导的方式是价值的流动，价值流动的前提是识别出整个价值交付链条中的各个环节。实际上在很多复杂的项目中是需要多人去合作的，而且价值交付过程非常复杂，很少有人能够对整个价值交付的全局有统观意识。
并且多团队协作容易导致组织上和地域上的隔离，进一步加剧工作移交和信息壁垒，容易以偏概全，陷入局部优化的怪圈。举个简单的例子，在一家公司测试团队经常是最忙的，普遍的做法是采取增加测试人员或者测试外包的方式去缓解测试压力。
这样的改进结果会导致测试的人力成本逐年上升，但效果却不好，依然无法满足产品质量的要求。这就是为什么如果我们只关注下游，关注局部，而不关注上游，关注全流程，影响价值流动的根因并没有被我们发现。
测试忙的原因可能在于整个软件质量并没有达到可测试的状态，导致测试的大量重复劳动和返工，甚至研发测试之间踢皮球。如果我们在上游在开发团队引入类似持续集成或者自动化测试的方式，让整个质量左移，这样或许可以更加有效缓解后端测试的眼里，避免头痛医头、脚痛医脚的现象，保证组织有一个全局的视野。
这个过程中不仅要识别整个价值流交付的各个阶段，同时要识别这里面的主要角色。在书中提供了一些参考的角色，如右图所示，在每一个且内部都不尽相同，大家可以做以参考。
召集价值流图分析WorkShop
在识别价值流的过程中有一个非常好的实践，召集价值流图分析 Workshop，在这个Workshop 里会召集价值流交付各个环节的主要人员，大家在一起协作去识别，并画出价值流交付的过程，原则上希望参加 Workshop 的人员是有一定决策权的。
往往一个复杂系统需要上百人的协作，细化所有的步骤需要消耗大量的精力，所以在这个过程中要掌握合适的颗粒度。
识别出来的价值流主要包含5-15个左右的步骤，在这个过程中可以充分了解彼此的工作内容，格外需要关注两类问题，一类是存在大量等待的环节，比如线上环境的准备，或者开发需要很长时间才能得到用户反馈。
另外是产生显著返工的环节，比如部署频繁失败或者测试不通过，质量可能存在一些潜在的风险。核心理念在于无需面面俱到，而是聚焦影响快速流动和可靠产出的环节。
在这种 Workshop 中很有可能有些人是第一次跟一些经常通过电话微信沟通的人员见面，而且对于运维人员来说他有可能是第一次真实的去理解研发缺乏一些线上日志或者具体信息的沮丧，对开发来说他们也才发现，每每他们去标记一个完成之后，后端的测试和部署团队需要花多大努力才能交付到真正的用户价值。通过这样一种彼此的分享去了解彼此的工作，去寻求一些潜在的价值点，才是我们真正要去关注的核心内容。
可视化价值流图
通过这样一个 Workshop，可以初步梳理出价值流图主要的阶段和核心的时间，在价值流图中重点关注的是三个要素，Lead time、Process time、准确率，前两个概念在上次分享时其实已经有说提到，Lead time 是整个价值流交付完整的时间，也就是我们常说的前置时间，而 Process time 是真正去执行这个时间的具体时间。
这样的对比就可以识别出一些潜在待改进的度量指标。如果我们要去改进的指标 Lead time，这里面潜在的问题可能是我们有一些约束点和瓶颈点，导致很多工作处于等待的状态，无形中延长了 Lead time 的过程。如果指标更多关注于 Process time，就说明在整个工作真正执行过程中可能存在很多手动或者低效的方式，导致价值在生产的过程中是低效的。
如果我们关注的是准确率，这里面客观体现的是质量和信息不健全。通过识别潜在的改进点，通过不断迭代、循环，最终达到整个组织效率最佳的目标，这个循环是不断演进的过程。
同时在这个过程中我们要重点关注的是约束理论，因为所有不在约束点去进行的改进，实际上都是一种伪改进，因为在价值流过程中，如果你在约束点之前进行改进，实际上约束点还是瓶颈。如果在约束点之后改进，价值交付同样没有得到很好的释放。所以在整个价值流过程中如何良好的识别约束点也是要重点关注的内容。
变革推进小组
当我们识别了要去改进的指标的时候，接下来就要去组建变革推进小组，可以说组织内唯一不变的事情就是组织变革，当组织开始发生危机的时候，组织的变化也就会停滞，响应速度开始变慢，信息也会开始脱节。
在一个组织中或多或少都有一些现有的流程和实践，这些原有的流程和实践帮助组织从小到大，获得了很多业务上的成功。
每一次组织变革，都意味着去颠覆和改变原有的团队职责，在这个过程中毫无疑问会产生一些 DevOps 转型和现有业务的冲突，如何解决这样的冲突，最好的办法就是建立独立的变革改进小组，也是所谓特区的概念。
在这样一个小组中会有一些特殊的属性，比如说变革小组中的成员需要全职加入 DevOps 转型改革的，而不是一个兼职的状态，另外倾向于具备全面能力的人员，第三倾向于资历较深、在组织内受到尊敬的角色，这样当我们的转型方案真正跟业务整合的时候，往往会通过一些良好的沟通达到更好的效果。
当然这样一个转型工作小组最佳的运作方式是在同一个办公区域去做面对面的沟通，可以优化组织内部沟通效率。目标只有一个，通过一个全新的流程或知识体系来达到变革转型的效果。
在张乐老师之前的分享过程中也提供过这样一个参考变革组织小组的组织架构。上边这个变革推进小组是 ETC 小组，会统领整个跨职能团队的组织变革，同时在下端会有一些平台型的组织提供技术支持和平台型的能力。两方面共同作用迁移各个业务领域内部的变革实施，保证变革工作的成功。
团队共享改进目标
在改进过程中，团队需要制定清晰的改进目标，比如需要降低50%现有的预算，比如说可以减少95%从代码变更到线上交付的过程。
通过制定清晰和可度量的目标和时间点，可以帮助我们明确将要改进的工作范围和计划，同时目标达成是可以为组织和用户带来显著价值的，这就代表了改进工作的初期胜利，通过具体的价值来体现，这对于团队管理层来说更加直观。
同时改进目标最好跟管理层和全体人员达成一致，避免上下理解偏差而影响改进效果的评价。第一个建议在实施过程中减少并行开展的工作，组织资源是有限的，如果同时开展工作，往往会导致组织陷入改进困境之中。
减少并行开始的改进工作，有点类似于限制在制品数量的理念，通过减少 WIP，加速改进过程的落地实施。第二是采取周期迭代和增量式的方法推进改进，因为我们很难确定这样的变革之路到底是不是有效的，所以通过快速迭代、增量的方式去推进改进，往往是成功的不二法则。
在每一次迭代之后要及时进行回顾和反思，为下一次迭代做好准备，从而建立持续改进的闭环，让团队不断的超正确的方向前进。
控制初期改进范围
在改进项目初期，我们建议要控制改进的范围，控制改进范围可以帮助我们灵活应对优先级和计划变更，同时可以把一些小的改进效果以最快的速度体现出来，加强反馈环建设，增强改进信心，激发更多投入，快速学习，持续迭代。
最重要的是，投入了这么多资源去做改进，如果迟迟没有效果，项目有被砍掉的风险。在今年的 DevOps 状态报告中，重点提出了变革领导力的概念，在整个项目改进过程中，变革领导力能起到非常重要的作用，它可以提供个体的支持，同时鼓励改进，明确改进目标，对团队现状进行挑战，并提供一些可行的方案。
可以说团队领导奠定了团队的氛围和文化，改进工作不可能一蹴而就，而需要更多的鼓励和包容，以及各方面的投入和支持，这对团队长远来说的发展至关重要。
预留20%时间处理非功能性需求和技术债务
本书中特别提到技术债务处理，建议预留20%处理非功能性需求和技术债务。
之前看过一则笑话，为了保持产品的改进空间，产品经理要求程序员降低程序执行的速度，于是程序员在代码里加了一行命令，sleep 20，通过这个方法拖慢了整个程序执行速度。
当然这只是一个笑话，实际上当我们面临很强的交付压力时，不排除真的有这样一些性能瓶颈风险存在，比如随意添加本地变量，没有及时处理错误，引入来路不明的外部代码库等。
虽然这样做也可以达到短期的目标，实际上对组织留下了潜在的技术债务。技术债务的堆积会导致一个非常严重的后果，也就是往往最需要改进的组织在改进上的时间投入是最少的，因为他们技术债务的堆积侵占了很多研发工程师的时间。
之前跟一个研发工程师在沟通时，他们有点自嘲说，我们哪里是研发工程师，就是一个解bug的工程师，但是我们认为研发才是企业价值流中真正增值的环节，研发工程师是不等于解bug工程师，这里面的原因很有可能是来源于技术债务。
通过四象限图来说明，左边是用户可见的功能需求，带来的正向反馈是需求和功能，负向反馈是缺陷，这样的问题相对易于把握和修复。右边往往是用户不可见的部分，包括一些架构上的内容，如非功能性的需求，过程改进等。如果我们不能很好的去处理非功能性的需求等用户不可见的内容，往往就会导致技术债务堆积，进而拖慢组织发展速度。
增加团队工作可视化
增加团队工作可视化，为什么要做可视化？
管理大师戴明曾经提出，如果你不能可视化你所做的事情，那么你就无法优化这个过程，其最主要的原因在于可视化可以帮助组织内所有人了解当前的工作状态，识别当前价值流动的瓶颈点，通过暂缓开始加速结束，加快在制品的快速流动。
可视化要确保信息是及时更新的，所有人看到的是最新的状态信息。同时调整指标来应对改进变化，因为随着改进工作的开展，其侧重点也不尽相同，每一个改进目标都需要响应的度量和可视化体系来帮助我们识别改进效果。
下面的这句话来源于人类学家的总结，自从人类发明火和掌握火的使用之后，所有的文化进步都跟工具密切相关，可以看到整个人类发展过程其实就是一部工具的进化史。
使用工具来加速行为转变
通过工具来加速行为转变。第一是使用统一的作业平台，在组织发展过程中，经常出现的青匡师，开发和运维使用不同的问题追踪系统的，比如开发是使用 Jira 这样的系统，运维可能是使用一个自建的系统。
通过整合作业平台，开发和运维可以共享他们的目标，也可以共享待办事项，这样做的价值在于整个组织的资源优化被统一协调、统一调配，研发和运维的工作也符合组织业务价值目标的需求，不会因为彼此的依赖而拖慢价值交付的过程。
另外，使用相同的作业系统、相同的语言，很容易在同一个系统内进行工作展示，进行任务传递和内容更新、降低沟通的成本。
最后通过全局视角进行任务优先级排序和编排。右边是即时通讯软件和聊天室的系统，这里提到一个典型的工具 Slack。Slack 在国外研发团队中普及率相当的高，他是一个 SaaS工具，在国内由于网络等方面原因不太适用，当然国内也有一些类似的工具。
它核心的理念在于使用一个统一的交流通讯系统平台，可以快速帮助我们解决问题，同时培养组织互信文化，其主要特点在于，
- 外部工具聚合，通过将各种工具聚合在一个统一的平台，我们可以实现通过聊天的方式启动编译系统，或者完成一项工作，查询各个系统中的信息，这样研发人员只需专注一个工作平台，不需要频繁在各种系统中切换，比如查看 bug 的时候跳到 Jira 系统或者查看一些编译构建状态跳转到 Jenkins 系统上。
- 团队知识积累，组织内很多知识或者案例可以使用平台保存起来，平台资深提供强大的知识搜索的功能，遇到问题，可以通过关键字检索，查找到之前的解决方案，快速解决问题。
- 人员快速沟通，这点显而易见，每个人都使用同样的系统，可以在系统中快速沟通，建立讨论频道，而无需邮件，电话等传统方式。当然这里也有一些负面因素，比如频繁打断，所以在使用即时通讯软件或者内部沟通软件的时候，团队需要去明确一些规则。总体来说，其实我们很多的浪费是发生在协调、沟通和组织间信息传递的过程中，通过打破这样一些浪费的环节，可以提升组织运行效率。
本章总结
总结一下，本章核心理念在于持续改进，识别价值流的一些过程。下图是网上找的比较有意思的图，原文是西班牙语，通过图示可以看到很多非常有趣的点。
比如在这个地方提到改进需要一步一步去做，同时改进需要有一个教练的环节，并通过PDCA 环节识别出不太适合我们组织企业的改进，同时进行一些反思和回顾帮助我们改进会更加有效。
总结起来，设定一个可预期的目标，通过小步迭代的方式去执行改进，纳入日常活动，在错误中学习，改进是每个人的工作，不应该局限于具体的某个团队，作为一种文化存在，这也是丰田方法核心的价值所在。