上一回，我们主要聊了DevOps的实践应该从哪里切入呢？那我们先花点时间回顾与复习一下。

（1）优先级（Priority）-最有价值的产品与项目，背后是高层的支持；

（2）绿地产品与项目（0=》1）- 新的领域、创新的项目与产品；

（3）服务买单的客户（To C）- 交互式，需要进行快速迭代，不断尝试；

（4）选择最乐于创新的人们 - 为了这些勇于改变的人才能创造出未来；

当我们具备上述条件后，那我们应该从哪里开始呢？那就现在工作机制/模式的可视化与价值流的梳理。而且这个方法，在任何场景里面都实用。例如：今天我们处理一天的incident。。如果我们非常情况一个C/S结构，客户端通过IE访问服务端，所做的一些列的事情，那我们就会非常容易知道问题出在哪里？同样，一个团队、部门、公司，如果大家非常清楚的知道为了做一个项目、产品整体的价值流，并将其可视化，那所有人都会很清晰的看到哪里是短板？哪些是问题的所在？我们应该采用哪些具体的方案进行提升？是需要引入更加高阶的工具？还是需要增加人员与提供人员技能？还是需要优化流程？还是需要增加治理与管控机制？

这又回到最本质的问题，公司、部门、个人生存的价值为客户提供有价值的服务，客户愿意为其掏腰包来购买。那我们提供的服务到底如何呢？客户满意吗？如果不满意，到底哪里有问题呢？需要如何进行改进呢？那你必须将服务进行价值流的分析梳理，以及可视化的展现。

在此，强烈推荐一本书Karen Martin与Mike Osterling写的《Value Stream Mapping》，可以说是价值流的圣经。非常喜欢书的封面的一句话 - “How to Visualize Work and Align Leadership for Organization Transformation”。

我没办法在此用简短的篇幅就把Value Stream讲清楚，但是我想我学到的，总结的一些思考分享给大家。

三步走的方法

（1）绘画出As-Is的value stream的整体流程，包括：人员（Who）、流程（What-When-Where）、工具与交付物（How-information flow and Material flow）、价值（Why）。包括：一些关键性的指标：前置时间、处理时间、等待时间、返工时间。

（2）设计出To-Be的value steam的整体框架，进行沙盘推演，或者MVP的实践；

（3）分析出差距（Gap），需要提升的能力（Capability）。然后，制定计划进行能力的搭建与提升，并周期性的进行总结并进行不断的调整；

比较粗暴的解释：

（1）As-Is的分析，时间都花在哪里啦？资源都花在哪里啦？值得吗？对产品与服务有机制吗？

（2）To-Be设计，如果给你计划重新设计，你会把时间、资源花在哪里？

（3）Gap与Capability的分析，需要提升哪些能力？才能真正的满足客户的需求，让客户愿意买单。

最后，跟大家分享一些在进行value stream分析与设计的时候，需要遵循的重要原则，具体如下：

（1）以终为始 - 所有运营模式的设计，都需要围绕value（Why?）-更好的服务客户，客户到底需要什么样的服务？我们如何来满足他们？customer experience, customer centric thinking。并且让整个团队的目标都达成一致，都是共同的目标而努力，奋斗。

（2）透明化/可视化 - 将所有过程，全部进行可视化、透明化，让团队成员都可以看到整体，让整条链路的团队成员，更加了解所有岗位的所做的事情，站在对方的角度去思考，特别是上下游的合作伙伴。这样可以让我们很清晰的知道，到底哪里流不下去了？堵住了？（快速流动）。哪个环节经常出问题？是否第一时间进行反馈（快速反馈）；

（3）用工具强化预期 - 使用工具来强化文化、强化标准、规范，人总是会疲劳、“偷懒”的时候，但是机器是不会的，如何将好的控制流程、文化intergate到工具中那可以提供我们整体的战斗力；

（4）用数据说话，持续进行优化 - 将整体value stream进行数字化的运营，用数据来衡量，不断进行调整与持续的优化实验，再进行调整，形成PDCA的持续数据搜集、分析、优化方案、实践运营、数据搜集的持续学习与优化的反馈环。

下一回，我们聊聊组织结构，以及开发、测试、运维等如何将合作融入到每天的日常工作中，来达到整体的优化。