“ 转型永远在路上。”

01 转型故事

某公司几年前开展了全公司的敏捷与 DevOps 转型。各团队风风火火地落地敏捷开发实践和 DevOps 工具栈，也做了相应的组织架构的调整。

在过去，由于预算都是以项目为单位制定的。团队构成分两类，一类是做项目交付的，他们围绕着项目预算组建团队；一类是负责项目上线后的系统运维的，相应的，也有以系统为维度的运维预算。

在转型过程中，很多人都反映，这种以项目为驱动的预算方式，以及围绕这种预算方式的团队组建方式，并不利于实现端到端的 DevOps 持续交付的目标。而且，项目是一个短期行为，项目完成后，又要把其“遗产”转交给运维团队。运维团队成了纯粹的背锅侠。

这种做法也完全违背了“开发、运维一体化”和“谁构建、谁修复”的 DevOps 原则。最理想的团队组建方式应该是，由一个以产品为维度组建的跨职能团队，负责这个产品端到端的开发与运维。原来的项目，将变成这个产品需要开发的一个个特性。维护一个产品，包括开发与运维，是一个长期的过程，这个产品团队也是一个长期存在的团队，直到这个产品消亡，更有利于知识的沉淀和团队的稳定。

这就和项目预算制产生冲突了。对于掌握预算的业务部门来说，在项目制下，他们只关心与之对应的项目交付。

不同的项目也会同时来争夺同一个开发团队的资源。

在这种环境下，不会有 Product Owner 这样的角色存在，即使有，也发挥不出其预期的作用。

有关项目预算制转向产品预算制以及相应的组织架构调整的讨论，一直在进行。

理想的情况是，以业务产品为维度确定预算，并以此来组建跨职能团队。尽量把产品开发和维护所需要的所有职能和系统都纳入到这个团队的范围内，实现自给自足，减少对外依赖，从而加快业务价值的交付，并实现持续交付。

02 试点过程

经过一番讨论，产品预算制开始在某些部门小范围试点。但是，他们很快遇到一些难题。

到底一个所谓的产品是什么范围呢？边界在哪里呢？

作为一家成立了几十年的金融企业，有多如牛毛的金融产品和服务，也有几十万个系统在支撑这些金融产品和服务。

如果以每一个现有或规划的金融产品和服务作为维度制定预算，那就意味着每一个这样的产品和服务都会有一支团队，而每个团队又要具备所有所需要的职能，哪里有那么多人组建那么多的团队。

原来的系统都不是围绕着这些产品和服务独立构建的，这些系统也无法切割给这些团队。

这势必需要对现有或规划的金融产品和服务进行汇总合并，但边界问题，意味着各部门的势力范围的重新划分，这必然牵涉到权力斗争在里面。

不管怎么分，原来的系统都不是这么构建的。要实现理想中的自给自足，必须要对所有系统进行重构，减少某个产品团队对其他产品团队负责的系统的依赖。这是个巨大的工程。

而且，经过实践，在解决依赖这个事情上，似乎比项目制更难。

在项目制下，一个项目的开发过程同样涉及到多个团队、多个系统的开发。除了主要系统的开发，很多上下游系统都需要进行一定开发和改造。项目经理除了管理主要系统的开发，还要协调负责上下游系统的团队。

由于项目掌握着财权，只要钱给够，项目经理一般都能从各个系统团队拿到支持。

在产品制下，由于各个产品团队自己掌握了财权。在没有完全实现自给自足的情况下，要从其他产品团队拿到优先级就比较难了，毕竟各产品团队的编制已经是按照自己的预算完成了，要满足其他产品团队的需要，就要加人，这不又仿佛回到了项目制？

由于那么多年以来，该公司一直实行项目制，有大量的项目经理。现在突然需要大量的产品经理类人才，能力需要其实和项目经理是不一样的。这也使得转型落地举步维艰。

要实现新的产品团队的自给自足、不对外依赖，不可避免会有一些业务、支持和系统的重复建设。

原来这些因为多个业务所需要的系统会被组建成平台或公共服务，但同时，它们也会成为所有项目团队的需求交付的瓶颈。为了打破这些瓶颈和依赖，这些系统就要在有需要的产品中重复建设。

关于边界问题，各个产品的负责人争论不休，预算和组织架构迟迟无法落实。但是业务需求从来没有停过。现有的团队在这个过渡期纷纷表示非常难受。

03 其它难点

我们也完全可以预见，即使现在把所有产品的边界划分得妥妥当当，各个新组建的产品团队终于可以在自我感觉比较舒服的状态下马力全开了。但一旦有新的需求，原来的产品边界可能就会被打破，不再适用，新的一轮边界与组织架构的讨论（zheng chao）又要开始。这似乎是一个无穷无尽的过程。组织架构能不能经受这么频繁的折腾呢？

经过一段时间的实践，该公司也发现另一个情况。那就是并不是所有业务都应该被定义为产品。像合规、风控、财务等功能，几乎所有业务都会涉及到，它们更应该被归类为平台或公共服务。在产品制下，它们的预算怎么定也需要进一步讨论。让这些功能独立存在，是否会成为产品团队新的交付瓶颈呢？

还有一些业务过程是几乎每个产品都会涉及到的，比方说现金结算等，在产品制下，如果把它们也定位为产品，当它们成为“独立王国”后，如何还能支持到其它产品就会成为问题。

04 写在最后

合久必分、分久必合。不管是哪种预算机制，或者组织架构，说到底，都是怎么切分的问题。不管哪种形式都不能完美地解决所有问题。

项目制好还是产品制好，这里没有答案。各有各的优劣。我们只能围绕着具体问题寻找当前最优解，永远没有一劳永逸的解法。转型永远在路上。

在这里我有三点建议：

1. 根据公司某些部门的具体实际情况进行推演，像上文提到的边界问题，其实在这一阶段就会有所暴露；

   先小范围试点，总结好经验后再逐步铺开。

2. 切记一刀切，没有适用于所有场景的灵丹妙药，很多时候需要多种模式并存。项目制、产品制可以共存。适合用项目制的，就用项目制；适合用产品制的，就用产品制。

觉得文章不错，顺手点个“点赞”或转发给朋友们吧。

分割线 卡通

相关阅读：

技术翻译之我见——标准、实操与收益

“现场”与体验是最好的管理

2021年发布过的文章集合，让你一次看过瘾

关于作者

刘华（Kenneth）

• 著有书籍《猎豹行动：硝烟中的敏捷转型之旅》《软件交付那些事儿》

• 《图数据库实战》中文译者之一。

• 世界 500 强银行 DevOps 与云平台中国区总监

• 敏捷、精益、DevOps 专家

• 公众号“敏于思 捷于行”博主

• 精通极限编程、Scrum、看板方法、测试驱动开发、持续集成、行为驱动开发、DevOps 工具栈、Docker、Kubernetes

• 曾在 QCon、GDevOps、DevOpsDays Meetup、中国软件技术大会、ArchSummit、Top 100 等论坛发表主题演讲

• 阿里云、谷歌云认证架构师

觉得好看，点个“点赞”或转发给朋友们，欢迎你留言。