组织级敏捷转型的四个阶段
2020-02-27
来源：有赞技术
物理结构对系统是至关重要的，但它们很少是杠杆点，因为改变物理结构通常不太容易而且见效慢。恰当的杠杆点，需要从一开始就被设计好。一旦实体的结构建立起来了，要想找到杠杆点，就需要理解系统的限制和瓶颈，在尽可能发挥它们的最大效率的同时，避免出现较大的波动或扩张，超出其承受能力。
——德内拉•梅多斯《系统之美》
笔者认为，敏捷转型是一个系统性的改进工程，具有时间和空间两个维度的复杂性，故要用动态的眼光来观察。作为参与组织全局优化的改进工作者，视野不能局限于研发过程，更要避免深陷于诸如“在某个小技术团队内推行三三五五”之类流于形式的过程中。
推动敏捷转型和做其他改进工作一样，目的是帮助组织成功，故不可能一蹴而就。更何况组织的使命是达成商业目标，而非敏捷转型成功，切勿舍本逐末。如果强行导入，则好比通过大跃进方式达成共产主义，结果可想而知。甚至可能出现转型尚未成功，公司却已经在残酷的市场竞争中倒闭了的情况，与“帮助组织成功”的目标背道而驰了。
企业的成长阶段决定了组织当前的结构。所以，既然组织的使命是达成商业目标，更合理的转型杠杆点，是着眼于宇宙的大尺度，基于组织处于不同阶段时的结构和组织对项目经理（下称： PM ）的定位，解决组织“难以达成商业目标”的痛点，然后逐步拓展系统边界和提升 PM 的职责范围，不断地进行全局的敏捷化。
阶段〇：小作坊
这个阶段，组织对 PM 角色的诉求并不太高，因为初创团队才是真敏捷。有赞 CTO 崔玉松也经常感慨早些年奋斗的日子：团队小，沟通成本低。哪需要什么项目管理啊，吼一嗓子的事儿，上午与负责产品和业务的同学讨论完毕，下午捣鼓捣鼓就弄上线了。
只是这种模式不可持续，有两股力量在推动组织往不同的方向进化：业务和技术（如下图）。其中：
1）一般来说，技术侧的复杂度风险会比业务侧更早暴露，所以管理者介入技术侧并在此沉淀的管理方法也较多，技术团队的管理成熟度逐渐提高。
2）技术侧的学习门槛高于业务侧，故对人员技术深度的要求高于广度。
3）初创企业需要尽可能多的人员能支持所有业务，业务广度优先于深度。
阶段一：职能结构
彼时，有赞业务主要围绕微商城SaaS展开，组织结构相对简单，从作坊式分工过渡到了职能结构形态。为提升技术管理的成熟度，有赞在该阶段引入了 PM 角色，故该阶段的 PM ，最重要的使命，就是关注研发生命周期管理，建立研发项目的管理体系，用“项目”这种形式来建立研发人员的合作方式，目的是使组织从无序到有序，并培养群体的规则意识，提升研发团队的管理成熟度。
有赞在研发项目管理体系的搭建过程中，适当地导入了一些敏捷的元素，一方面让规则建立在当下研发人员熟悉的工作流程上，另一方面又不至于太重，给人留下瀑布式项目模式的烙印，为未来的调整留出空间。随着组织成熟度的提升，可以加入更多的敏捷元素。
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
-
延伸阅读：
-
