在新的一年，我们将为你提供VSM每周观点，并于每周三早上7点准时在本公众号进行发布。VSM每周观点仅代表作者对价值流管理（VSM）的个人理解和看法，同时我们会在每一期的文末推荐与当期观点相匹配的一本书籍。
01
狭义DevOps VS 广义DevOps
如下图所示，我们对DevOps的理解通常分为狭义DevOps和广义DevOps。
狭义DevOps：一般只涉及科技（IT）的开发（Development）和运维（Operations）团队，涉及从“需求分析、开发、测试、上线投产和运维”的研发运维过程的优化，专注于软件的快速交付；
广义DevOps（即BizDevOps）：要求业务和科技团队的高度融合协作，涉及从“想法、价值定义、解决方案、需求分析、开发、测试、投产和运营”的端到端价值交付周期，专注于价值的快速实现。
02
你是在做局部优化吗？
从2009年提出 DevOps 至今已经有13年了，通过 DevOps 思想、方法和实践，促进开发和运维团队之间更好地协作，建设 DevOps/CICD 流水线，从而提升软件交付效率和缩短软件交付周期。DevOps运动对研发效能的提升是毋庸置疑的。
然而，狭义的 DevOps 只是业务价值端到端交付过程中的一个局部环节，根据约束理论（TOC），对局部环节的优化不一定会带来整体价值效能的提升，除非这个局部环节是整体价值交付过程的瓶颈。
如下图所示，狭义的DevOps和CICD流水线更聚焦于研发过程的自动化（也就是从代码提交到部署上线过程的自动化），当然狭义DevOps过程一般还包括需求分析、设计和编码阶段。
在用户提出想法开始，到最终将价值交付给用户，并获得收入的整个价值实现过程中，狭义的DevOps只是其中的一个局部环节。
当这个局部环节不是整体价值流的瓶颈时，继续对局部环节的过度优化对整体价值实现时间（最终用户能感知到的价值实现周期）不一定会产生效果，或是说产生的效果是微乎其微的。
我们再看下图的例子，在整个价值交付过程中，我们可以看到从商业案例到开发Backlog花费了6个月的时间，从编码完成到发布上线又花费了6个月的时间。
也就是说，在端到端价值交付过程中，更大的瓶颈在于价值交付过程的前期阶段（构建商业案例、等待案例审批等）和后期阶段（等待测试、等待上线），而不是在开发编码阶段。
在这种情况下，我们需要将优化的关注点放在价值交付过程的前期阶段（构建商业案例、等待案例审批等）和后期阶段（等待测试、等待上线），而不是在开发编码阶段。
由于当前开发编码阶段不是端到端价值交付过程中的瓶颈，如果我们还是将更多的人员和资源用于开发编码时，将会出现什么情况呢？
显而易见，端到端的价值交付周期不会有明显的缩短，同时这样还会产生大量已开发完成但是排队等待测试和上线的“半成品”，而这些“半成品”是无法交付给用户的，也就意味着无法产生价值和实现企业营收的。
因此，识别价值交付端到端过程的瓶颈，并针对当前最大的瓶颈进行优化，才能最大化缩短端到端的价值交付周期，从而提升用户体验和加快价值实现。
03
如何避免局部优化？
最简单也是最具成效的方法是，我们可以采用价值流映射（Value Stream Mapping）实践，花费2-4小时的时间与价值交付过程的每个角色一起绘制价值流图（Value Stream Map）。
价值流图的绘制要尽可能涉及价值交付的全过程（涵盖业务和IT），同时要求每个过程步骤的角色（每个角色可以只派1-2名代表）都参与进来。如下是价值流图绘制的例子：
从价值流绘制实践中，我们至少可以得到如下好处：
- 建立价值流动的全局视角，有助于各个职能团队建立以客户为中心的系统思维；
- 直观的看到每个环节的事实数据，而不是依托员工的经验主义
- 识别当前最大的瓶颈，将精力聚焦于当前瓶颈的优化上。如上图数据显示67%（即32天）的时间花费在流程等待中。由此可见，我们应当把优化的重点放在流程优化，而不是局部的资源效率提升上。
04
本周推荐阅读
《价值流图：工作可视化和领导力匹配》
价值流映射是一种实践，更是一种思想。本书是精益和价值流践行者的必读书籍之一，书中介绍了价值流思想和价值流图相关概念，并提供了价值流图绘制的具体步骤和案例。
