从项目制到产品制，日子变美好了吗？

刘华Kenneth——敏捷、精益、DevOps专家

猎豹行动 硝烟中的敏捷转型之旅 作者

软件交付那些事儿 作者

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

在这里我有三点建议：

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

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

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

觉得文章不错，顺手点个“点赞”、“在看”或转发给朋友们，欢迎您留言。