从DevOps看高绩效组织是如何处理产品和项目的关系的？

DevOps 的理论来自于基于价值流的三步法。这三步法分为以下三个步骤：

1. 流动
2. 反馈
3. 持续学习和实验

“流动”是指快速实现从“构想”到“交付”的价值传递过程。传统上认为软件团队从客户的“需求”做起，其实软件团队实现的所谓“需求”只是产品经理的“构想”，这种“构想”要交付到客户手上才能验证是否真正的满足了客户的“需求”，所以软件团队要让价值快速流动，一方面可以验证构想得到“反馈”，另一方面完成价值的交付。

团队在研发软件的时候会把一个又一个“构想”做成软件功能交付给客户。客户的反馈也会一个又一个的送到软件开发团队的手中。不管是功能改进的意见，或是新功能的建议，还是缺陷，都需要团队及时跟进解决。团队也通过这种持续交付和反馈中学习到了应该从哪里建立软件的竞争力，改进流程提高交付速度和质量，甚至可以实验一些新的方法提高开发、运维效率，改善产品质量，提高用户体验。

上图表示的是 DevOps 推荐的沿着价值流动的方向进行绩效度量的建议。这其中能区分高绩效组织和低绩效组织的 3 个指标时：

1. 处理时间 (Cycle Time)
2. 前置时间 (Lead Time)
3. 反馈处理时间

每年 Puppet 这个著名的代码及基础设施的工具厂商都会围绕着上面的 3 个指标给出 DevOps 报告。下图是 Puppet 2021 年给出的 DevOps 报告中提到的高、中、低绩效组织在 DevOps 关键指标上的对比。可以看到其中的指标都是紧紧围绕价值流展开的。Deployment frequency 和 Lead Time for changes 关注的是处理时间和前置时间。MTTR (Mean Time to Recovery) 和 Chang Failure Rate 关注的是反馈处理时间。

项目结束后是否就应该解散团队呢？

上文提到的团队实现 DevOps 三步法方案的前提是团队一直存在。如果组织希望实现 DevOps 的目标，那么就需要建立长期的团队责任制，负责目标的实现。如果团队按照项目组建，每次软件发布后开发人员就被打散并重新分配，开发人员就没有机会得到自己工作的反馈，所以建立高绩效组织有两个大前提，它们是：

1. 有战略目标
2. 保持团队的完整性

如果组织只是一门心思关心的财务指标，只想赚钱那么它可以天天围绕着项目转，以项目为考核对象，以时间、成本、范围为考核指标，在需要的时候组建项目团队，项目结束后解散团队，那么上文所说的 DevOps 就没有了实施的基础，更谈不上建立高绩效的组织或者团队。这种组织大概率是营收很高但是利润率低，应收账款高，因为虽然项目多，但是团队不稳定没有持续改进，效率低。

高绩效组织通过稳定的团队打造过硬的产品。团队通过持续交付，在不同的项目中验证和改进产品，以团队为考核对象，以公司营收、客户终身价值以及客户采用率为考核指标。同时因为团队稳定，成本相对固定，不会蔓延。如下图所示，产品的生命周期要远远长于项目的生命周期。在产品的生命周期内可能会被应用到时间长短不一、范围大小不同的项目中。产品团队通过持续稳定的交付和项目团队建立信任关系，实现组织的战略目标。

结论

DevOps 的流动、反馈、持续学习和实验的三步法需要由一个稳定的团队来实现。在每次软件发布后开发人员就被打散并重新分配，开发人员就没有机会得到自己工作的反馈，团队就不能通过持续交付和改进变为高绩效的团队。组织应该制定自己的战略目标，通过稳定的团队持续改进产品提高绩效实现战略目标，达到建立高绩效组织的目的。

参考链接

1. DevOps 实践指南
2. Puppet - State of DevOps Report 2021