物理结构对系统是至关重要的，但它们很少是杠杆点，因为改变物理结构通常不太容易而且见效慢。恰当的杠杆点，需要从一开始就被设计好。一旦实体的结构建立起来了，要想找到杠杆点，就需要理解系统的限制和瓶颈，在尽可能发挥它们的最大效率的同时，避免出现较大的波动或扩张，超出其承受能力。——德内拉·梅多斯《系统之美》
笔者认为，敏捷转型是一个系统性的改进工程，具有时间和空间两个维度的复杂性，故要用动态的眼光来观察。作为参与组织全局优化的改进工作者，视野不能局限于研发过程，更要避免深陷于诸如“在某个小技术团队内推行三三五五”之类流于形式的过程中。
推动敏捷转型和做其他改进工作一样，目的是帮助组织成功，故不可能一蹴而就。更何况组织的使命是达成商业目标，而非敏捷转型成功，切勿舍本逐末。如果强行导入，则好比通过大跃进方式达成共产主义，结果可想而知。甚至可能出现转型尚未成功，公司却已经在残酷的市场竞争中倒闭了的情况，与“帮助组织成功”的目标背道而驰了。
企业的成长阶段决定了组织当前的结构。所以，既然组织的使命是达成商业目标，更合理的转型杠杆点，是着眼于宇宙的大尺度，基于组织处于不同阶段时的结构和组织对项目经理（下称： PM ）的定位，解决组织“难以达成商业目标”的痛点，然后逐步拓展系统边界和提升 PM 的职责范围，不断地进行全局的敏捷化。
#阶段〇：小作坊
这个阶段，组织对 PM 角色的诉求并不太高，因为初创团队才是真敏捷。有赞 CTO 崔玉松也经常感慨早些年奋斗的日子：团队小，沟通成本低。哪需要什么项目管理啊，吼一嗓子的事儿，上午与负责产品和业务的同学讨论完毕，下午捣鼓捣鼓就弄上线了。
只是这种模式不可持续，有两股力量在推动组织往不同的方向进化：业务和技术（如下图）。其中：
1）一般来说，技术侧的复杂度风险会比业务侧更早暴露，所以管理者介入技术侧并在此沉淀的管理方法也较多，技术团队的管理成熟度逐渐提高。 2）技术侧的学习门槛高于业务侧，故对人员技术深度的要求高于广度。 3）初创企业需要尽可能多的人员能支持所有业务，业务广度优先于深度。
#阶段一：职能结构
彼时，有赞业务主要围绕微信商场城SaaS展开，组织结构相对简单，从作坊式分工过渡到了职能结构形态。为提升技术管理的成熟度，有赞在该阶段引入了 PM 角色，故该阶段的 PM ，最重要的使命，就是关注研发生命周期管理，建立研发项目的管理体系，用“项目”这种形式来建立研发人员的合作方式，目的是使组织从无序到有序，并培养群体的规则意识，提升研发团队的管理成熟度。
有赞在研发项目管理体系的搭建过程中，适当地导入了一些敏捷的元素，一方面让规则建立在当下研发人员熟悉的工作流程上，另一方面又不至于太重，给人留下瀑布式项目模式的烙印，为未来的调整留出空间。随着组织成熟度的提升，可以加入更多的敏捷元素。
敏捷转型的过程，就是在不断试探中逐渐减少管理投入及加强自组织能力的过程。
#阶段二：事业部结构
有赞启动云业务，抽象底层能力，并在此基础上嫁接出更多的垂直领域（比如：美业、零售连锁、教育等等），没有人能全局掌握如此宽泛的业务知识，业务复杂度变得很突兀了（如下图）。于是，在商业目标的驱动下进行了新一轮组织架构调整，事业部的特征慢慢形成。事业部制也就是德鲁克所推崇的“联邦分权制”，在该模式下，各职能部门被拆解，人员以小组单元形式重组到以达成特定商业价值为目标的各独立业务领域中。
从宏观上看，这种模式像极了敏捷团队，角色齐全，目标唯一。但在事业部内部观察的话，每个角色并非单个人，而是一个由 TL 管理的小组，所以微观上还是职能结构（甚至有一些提供共享能力的角色仅以虚线形式存在于事业部内，实线的职能特征更强）。但总的来说，商业目标使得原来职能结构时期的部门墙正在瓦解。
此时， PM 可以腾挪的空间开始变大。与原来单一业务下的大组织相比，事业部化之后各团队的规模变小（但还是有上百人），对接该业务线的 PM 可以夯实大部分在阶段一的改进点，并根据小团队做更深入的优化。其中特别有效的一个手段，是基于事业部下各二级业务线的需求生命周期管理。
随着 PM 在研发生命周期的作用的发挥，我们发现流动效率的瓶颈，已从技术侧左移到代表需求生产的产品侧，故 PM 的职责范围不再只是研发侧，而是从需求生产到研发上线的整个需求生命周期的项目管理。系统的边界就变成了：商业目标落地为业务需求，是系统外部的驱动力。同时，由于在研发侧有充分的沉淀和赋能，研发过程的管理可以逐步交接给技术团队自己完成。
一方面， PM 可以酌情降低研发管理细节的关注度，而应把精力重点放在产品侧的过程管理（比如：设置 APO 和 PO 、产品侧里程碑、需求价值跟踪等），以及需求从产品侧到技术侧的界面（比如：统一需求池、需求预估、资源冲突处理等）。另一方面， PM 逐渐引导事业部，在不改变组织结构的前提下，进一步划分为以商业目标为导向的多个虚线特性团队，并尝试解耦。
隐藏细节，本质上是一种为了站到系统更高层级上做更全面思考的必要手段。
#阶段三：矩阵结构
为了提升市场竞争能力，有赞需要在更多的垂直行业提供解决方案。和事业部模式相比，这是一种更灵活的组织形式，是面向新商业模式的一系列尝试。它不改变现有的组织架构和汇报关系，以临时组建全链路项目的方式，拉动整个组织上下游资源，围绕短期业务目标进行的一场综合行动。它的特点是短频快，打得赢就打，打不赢就跑。
PM 在本阶段需要关注的全链路项目管理，包括了销售、市场、产品、技术、运营、服务等多个环节，而每个环节都会有一系列的动项，每个行动项都需要用子项目的方式管理其过程。阶段二所关注的产品研发项目，在这里只是其中的一个行动项而已。站在更全局的视角，细节进一步被隐藏。
该阶段仿佛又回到了“临时组建项目”的工作方式，而且细节操作层面可能会散在各处。但实质上，这类项目的各方资源在宏观上更内聚，因为每个职能角色都会有一个核心人员参与其中，在核心团队实践“三三五五”反倒更加容易和有效（类似于 Scrum Of Scrums ，但会做得更重），组织典型的特征是：目标更聚焦、市场反馈更早、需求迭代更快。当然，因为各行动项须由核心人员带回各自职能单元落实，故仍然要归属在统一需求池的框架下。
与产品研发侧相比，协调各职能角色的难度更大。故 PM 需要将产品研发业已沉淀的管理能力赋能给其他职能单元，有助于各职能角色对齐目标和行事方式，避免 PM 既要顾全大局，又要因为组织中各职能单元成熟度不够而不得不到处救火。
#阶段四：战略业务单位结构
在该阶段，组织将在大型的多元化产品市场中进行多种经营，提供不相关的产品与服务。有赞尚未走到该阶段，故笔者暂无实践经验可以分享。但可以预见到的是，随着组织的壮大，单个 PM 可以触达的组织范围是有限的，故需要依托组织的力量，是归属于 PMO 还是事业部，取决于项目管理专业技能和改进对象的业务复杂度对该角色的影响当前谁占主导（参考上图特性团队和组件团队的决策模型），敏捷转型的方向和节奏也会受此影响。这也将会是一个有趣的话题，但限于篇幅，不在此展开。
组织的进化是一个存在即合理的过程，从系统思考的角度来说，敏捷思想的引入只是作用于系统的无数个悬摆之一。且在组织的不同阶段（时间或空间），会产生不同的时延作用，甚至可能违背当事人的初衷。作为组织级敏捷转型的导入者，我们一方面要积极面对组织现状做系统思考，并因地制宜地导入有利于组织成长的敏捷元素，另一方面也要及时观察该系统的反馈效果，分析各回路的变化和主次关系切换，合理做出调整。
我惊恐地意识到，我急迫地希望重建民主，有些做法却几乎和理想主义者一样了。我一直希望更快地推动历史的发展，却犯了“拔苗助长”的错误。我意识到，当我们试着创造一个新事物时，我们必须学会等待。我们必须充满耐心地播种，精心浇灌土地，让种子自己发芽、生长，它需要时间。你不可能愚弄植物，你更不可能愚弄历史。——瓦兹拉夫·哈维尔（捷克共和国第一任总统、剧作家）
发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/100927.html原文链接：https://javaforall.cn
