笔者认为，从系统动力学的观点来看，由于受到自身发展的驱动，一个组织必然是在「混乱」与「有序」之间震荡，而且没有任何管理制度能成为银弹，让平衡一直维系下去。于是，我们所要做的，是不断调整管理手段，形成动态平衡，让组织得以进化。而研发管理，正是这样一种能让研发过程变得「乱中有序」的手段，尤其是「项目制」的管理方式，进可攻，退可守，既能阻止组织继续混乱，又能在时机成熟时，让组织的研发过程转危为机，进一步向「敏捷制」继续演进。

笔者所在的效能改进团队，在有赞承担组织优化的重任，相当长的一段时期内，在产研侧持续采用「项目制」的方式，缓解症状，化解矛盾，实现组织现状与发展诉求之间的动态平衡。

背景

彼时，有赞员工 400 人，其中产品研发团队 200 人，共同迭代开发核心产品「微商城 SaaS」。随着公司的发展，软件系统日渐庞大。为应对技术领域可预见的复杂性，在组织层面，初步划分了若干组件团队（Component Team）：营销、商品、店铺、会员、交易等域，在技术深度上尽量做到内聚，而在业务相关性层面则继续保持耦合状态。

笔者回忆起当时的组织设计，这样的决策意味着有赞并不打算止步于当下小而美的规模并深耕业务，而是强化技术能力，以应对业务在横向和纵向的灵活扩展（题外话：关于这一点， 在此后重点布局的业务中台和有赞云上得以印证）。

当然，任何组织形式都有其利弊，管理的艺术在于如何扬长避短，找到动态最优解。组件团队式的组织结构，虽然各团队的技术成果不断涌现（内聚的好处），但深井病的现象也十分明显（耦合的弊端）：部门墙开始出现、跨团队协作中存在三不管地带、目标达成过程中的信息黑洞及管理真空。

初探

在笔者介入后发现，产研团队虽然未曾接触过项目，而且过程管理存在诸多纰漏，但此间早已渗透了朴素的项目管理理念：

1）项目范围管理。由于有赞的基因，天然决定了其拥有缜密的设计思维。而且它作为 B 端 SaaS 产品，在需求收集阶段，会考虑完整场景和业务闭环，所以产品需求的范围是相对可控的。然而，也正是由于上述原因，产品需求的颗粒度普遍偏大，研发周期一般在 1 个月上下，相对 C 端产品需求可以拆分到 1 至 2 个工作日的程度，是不可想象的。虽然也会有需求拆分和评估的动作，但显然是无法独立交付和产生价值的。

2）项目时间管理。有赞当时虽然没有明确的研发流程，但普遍存在不成文的协作方式：从产品经理那边获悉需求后，研发人员会相互沟通方案和接口，然后才会投入开发，经过上下游集成和调试后，提交给测试人员做验证，最后安排发布上线。显而易见，可以据此作为里程碑，来制定进度计划。

3）人力资源管理。组织架构一旦按组件团队方式被划分，就意味着相当一部分产品需求，会依赖于用跨团队协作模式进行生产和交付。尤其是当业务中台从原有产品的底层剥离出来之后，为了抽象出中台能力，需要配合参与大量业务场景的开发。于是，参与研发的人员复杂度不但没有降低，反而愈发高了，进而越来越需要投入精力在团队的组建和管理上。

如何基于现状找到高杠杆点，并再因势利导地突破现状，实现组织成熟度的跃迁，是我们的最终目标。而关于姓「项」还是姓「敏」的抉择，事实上，在日后的工作中，我们并未排斥任何一种方法论，反而能转化意念、借假修真，走出了一条标本兼治的「中西医结合」道路。

实践

有趣的是，虽然前期我们打算基于组织现状，整合已有的协同工作模式，进而落实「项目制」，但站在当下反观过去实践的整个过程，反倒是「敏捷」的：我们试探性地往前拱一拱，然后看看是否奏效，再考虑继续往前拱。本文将整个过程抽象成三个迭代予以呈现（实际操作过程中是交替进行的）。

迭代 1：提升组织透明度

项目制的好处是能给干系人一个「看得见的未来」，不至于焦虑重重。既然研发有里程碑的意识，那我们就把它们串在一起作为项目计划对外公示，告诉所有人哪天提测、哪天上线，并且定期站会确认进度，及时同步进度报告和风险。

项目制催生了 PM（项目经理）角色的崛起，受托于干系人来管理项目，填补了项目过程中各项技术工作之间的管理真空。既然当前的组织结构就是「组件团队」式的，那咱们就夯实跨团队协同工作的模式，由 PM 带起节奏，在项目规范中明确角色和职责，建立需求评审和验收的机制、前后端接口定义先行的机制、多系统下的发布机制等。

项目制兼容并包，从不挑剔需求大小，反而越是复杂的和明确的需求，用项目来进行管理越是有效。毕竟，在一片混乱中，当务之急是稳住局面，解决当下的燃眉之急，阻止病情的恶化，而不是说服产品经理花时间学习并掌握需求切片的技术。

迭代 2：唤醒自组织意识

项目管理的最终目标，是实现组织的成功。据笔者了解，各家互联网大厂 PMO 的布局都做得很彻底，几乎每条业务线都配有 PM，并与业务线绩效绑定，以达到「组织成功才是 PM 成功」的目的。

但笔者认为， PM 角色习惯着眼全局，善于捕捉风险，积极补位，但一旦完全下沉到团队中，可能会限制该角色优势的发挥，且不利于组织进化。比如说，遇到复杂项目，团队的第一反应会是寻求 PM 协助，甚至一些非专业性的日常事务，也都会依赖 PM 推进。长此以往，团队将会逐渐削弱在项目管理方面自我成长的动力。

有赞效能改进团队在初步「提升组织透明度」，使病情稳定后，便开始着手推广项目管理的方法论，在各组件团队中培养兼职 PM，以承担大部分项目的管理工作。「授人以鱼不如授人以渔」，该措施的效果还是很明显的，团队中的大批中坚力量快速成长，「套路心中藏，遇事我来扛」，自组织意识得到有效激发。

与此同时，效能改进团队则开始积累组织过程资产，为各组件团队提供人员效率、流动效率等度量数据，并像 ScrumMaster 那样，以教练的视角，在各种场合反馈给团队并进行引导，进一步唤醒了组织通过改进效能这一手段得以进化的欲望。

迭代 3：顺势而为化敏捷

随着有赞的发展，尽管在单个需求中依然保持「项目制」的管理方式，但此时组织已经基于业务中台，催生出了零售连锁、美业、教育等多条业务线（ PS ：这就是中台化的力量），由于业务线与中台耦合，造成了上游多个业务方争夺中台项目资源的现象（组织早期也会出现某组件团队资源不足的情况，但由于规模尚小，不足以引起如此重大的影响）。

此时的效能改进团队，早已度过了紧盯单个项目的阶段，而把更多精力放在关注组织发展的全局上，在时机成熟时，运用 LeSS （ Large-Scale Scrum，大规模敏捷）的思想，根据各组件团队间的业务划分和人员合作的内聚状况，全局性地组建虚拟的特性团队（ Feature Team ），引导建立面向特性团队的公司级业务月度规划（产品侧的生产计划）和需求月度规划（研发侧的生产计划）机制，并基于价值的维度，在其中明确定义需求的优先级，缓解资源冲突的状况。

众所周知，除「组织设计」之外，「工程实践」是另一个推动规模化敏捷的高杠杆点。在测试和运维等多个部门的共同努力下，效能改进团队结合项目的过程管理，积极推动有赞内部 CI / CD（ Continuous Integration / Continuous Delivery ） 的落地，为快速交付扫除障碍。

小结

兵无常势，水无常形。在组织发展的过程中，须因时因地因人，而选择合理的手段，且既要解决眼前问题，又能宜于长远未来。运用「项目制」快速稳定局面，跟随组织的发展进程动态地调整游戏规则，择机布局敏捷，助力组织进化，是具有深远意义的。但由于组织文化尚未成熟，不宜兜售太多概念，故在具体实践中，虽然没有任何一项工作被称为敏捷，但细心的读者可能已经发现，效能改进处处敏捷。正所谓：

天下 PM 出我辈，一入 IT 岁月催。

井深销得人憔悴，理念朴素莫伤悲。

过程管理待栽培，自我意识在沉睡。

透明欠佳愿未遂，不见未来夜无寐。

标本兼治蛹渐蜕，远虑近忧分寸微。

项目敏捷共荟萃，组织成功是回归。

如果读者对效能改进也有兴趣，欢迎在底部留言，与我们共同探讨和实践。