敏捷与规模兼得的高绩效组织打造

本文主要是介绍敏捷与规模兼得的高绩效组织打造，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

导语

一谈到组织结构创新，管理者总是格外强调绩效管理的议题。与此同时，如何在新的组织结构下实现内部协同运作，如何通过规划机制保障组织的柔性可持续，当建立新组织时是否会形成新的部门墙，这些都是备受关注的问题。故本文将从传统组织结构模型出发，剖析其面临的挑战；进而提出高绩效组织结构创新模式——产品部落制，并延伸出该结构之下的绩效体系、业产研协同与规划机制，尝试将敏捷与规模这看似相悖的两者进行有机结合，打造高绩效组织。期待能够对关注上述种种实际问题的管理者有所启发。

挑战重重，转身势在必行

进入数字时代，社会迎来高速发展，传统组织很难高效响应当前快速发展的态势，业务部门和研发部门常常会产生冲突。

近两年业内开始追捧研发效能，一方面是整个市场的变化，从以前的跑马圈地的增量市场开拓演变为精耕细作的存量市场争夺，如果不能快速挖掘客户的深度诉求，争夺客户资源将会十分困难。

同时，以前业务增长速度迅猛，可以宽松的研发投入，但随着业务面临压力的增大，压力会传导给研发。而面对日趋饱和的市场，不是简单通过提升研发效能就能解决问题，业务也是如此。

具体到敏捷研发交付过程中，常常面临的痛点主要有：

组织部门墙高筑，沟通全靠流程和文档，繁重低效；
需求交付进展不透明，临近交付日才发现时间紧迫，于是拼命加班，忽视研发质量，事倍功半；
跨系统跨团队全靠关系好不好，协作沟通低效；
迭代冲刺1~2周发布交付，实际上根本做不到；
开始需求不多人数充足，随着各种需求的加塞，开发进度严重拖累；
项目经理只会每天催进度；
有改进之心，却不知从何入手；

导致组织内部产生诸多问题的本质原因有许多。

首先是业务跟IT目标不一致。

在组织中，IT与业务的KPI设置往往是不一样的，IT在KPI中会提到产能高、需求数上涨、质量好、生长环境稳定率高等。但是这些对业务而言没有感知，业务的逻辑很简单，就是每年增长多少个百分点，因此当目标不一致时两者很容易出现矛盾。而且在传统组织中，业务通常被视为创收中心，而IT更多被视为成本中心。因此当业务不好时，IT很难说自己做得好；只有业务好IT才能好，应该秉承这样的逻辑。除了类似亚马逊那种IT即业务的企业，其他大多数企业在大部分场景下还是业务引领，尤其是在金融组织中。

其次是建设目标不明确。

企业中常常会面临一种情况，业务部门认为所有的业务都很重要，而IT在做完部分需求之后会觉得没有价值，导致两者之间产生冲突。其实一个相对成熟的组织应该应用“7/2/1”法则，即70%的资源用到核心业务，为组织持续盈利贡献，创新性相对较少，不会出现大量价值不确定的工作；20%的创新类项目，近两三年的方向，有时能够快速带来价值，有时不能快速见效；10%探索公司未来走向的工作，不以短期盈利为目的。因此本质上应该区分看待不同类型的业务，不要简单因为建设目标不明确，双方就产生冲突。

除此之外，一年一规划也是组织常面临的问题。

工作中我们常常会用甘特图规划好所有的项目，创建很多子任务，试图按部就班将子任务一个个进行落地。但实际上外部环境变化很快，像2020年突然爆发疫情，计划必然被迫改变。所以甘特图不太适合现在的精细化管理要求，它只是提供一个方向，具体落地细节要根据实际情况动态调整。

回归到一个组织，其实资源是有限的，各方出于自身价值的考量，都希望花费尽可能小的成本，实现快速高质量的交付价值。然而传统的组织结构之下显然桎梏重重，因此通过哪种组织结构和管理方式实现这一目的，也是企业想解决的本质问题。

延伸阅读：三种传统组织结构模型

职能型组织，按职能来组织部门分工，即把承担相同职能的人员组合在一起，设置相应的管理部门和管理职务。职能型组织的好处是，同一职能的人可以在一起持续打磨，在各自领域持续深耕，同时部门内部成员可以灵活调配，支持多个个项目。资源利用率看似相对较高，然而由于职能部门会过于关注自身的利益，会形成职能竖井，使部门间不能以业务交付为导向进行协作，实质上有损组织创新与协同。

矩阵型组织，分为弱矩阵、平衡矩阵和强矩阵，它的项目协调是由职员来做，它也有职能所在，但是与职能型组织有点不同。矩阵型组织有个比较大的缺点，就是多头管理的问题。通常在企业中会发现，如果该矩阵型组织的项目经理权力不那么大，他给职员安排了工作，然后职能经理也会给职员安排工作，但是职能经理有绩效权。从人性的角度来讲，职员肯定会听职能经理的，因为绩效考评、成长路径在职能经理手上，所以这是矩阵型组织的一些问题，横向项目团队看上去有很多人，其实管理起来很复杂。

项目型组织，很多人喜欢的一种组织模型，”如果有足够的授权，一定能够把项目干好”。这种组织让很多人向往，因为项目经理有人事权和管事权，职员向他汇报，他可以给职员打绩效。但是权力的集中有时也是一种缺点，项目经理可能会把重要资源都拿走，团队会越扩越大，甚至涉及本来不是他的业务。对大企业而言，如果任由这种管理模式无限扩张，未来一定会存在问题。

以上是三种传统组织结构模型的大概情况，它们的特征主要涉及项目经理的职权、可用的资源、项目预算控制、项目经理的角色和项目管理行政人员整体的权限情况。从上图可以看出，从职能型到项目型组织，职权、资源的权限由少变多，角色也从职能经理到项目经理进行转换。

大象如何优雅转身？

前面提到的内容是基于规模化的金融组织而言，由于人数规模的扩大，组织管理的复杂度也会增加，而且金融机构本身的业务、职能、组织和系统都具有较高的复杂性。在规模化的组织中，提高组织效率和交付效果是核心目标。在以职能为导向的传统模式中，通常做的都是某个职能内部的局部优化，对组织整体却乏善可陈；而敏捷型组织，做的是流动效率与资源效率的全局优化。规模化敏捷就是帮助大型组织突破流动效率的困境，而产品部落制则是落地规模化敏捷的组织结构创新，能够为大象平稳、优雅地转身创造关键的内部条件。

产品部落化组织结构设计中（如下图），每一个部落对应的一个业务领域，有横向的职能线与纵向的业务线两大块，也会有跨多领域的项目组织。事实上部落化组织就是一个精心设计的矩阵型组织，而且部落化组织是既能发挥大型组织协同规模化效应，也能像小公司那样快速响应业务的两全其美解决方案。

产品部落组织结构可以从纵向和横向两个维度进行解构：

纵向来看，小队和部落面向价值交付，偏重于“用兵“，以价值交付和业绩提升为方向。小队是业务端到端交付的最小单位，包含所需业务、研发人员，人数一般约10人。小队长通常由开发负责人担任。部落是相同业务领域所有小队的集合，面向具体业务稳定输出，人数一般小于150人。设置部落长对整体交付过程负责，通常由具体业务领域CTO担任。

横向来看，分会和行会面向能力提升，偏重于“养兵"，以专业化为方向。分会是同一个部落中相同能力领域内拥有相似技能的人员。设置分会长负责发展员工、设置薪酬等，分会长常由职能团队负责人担任。行会是跨部落的组织形态，可以是横向项目团队，也可以是兴趣社区，定期进行知识、工具、代码和实践的分享，设置协调员来组织。

有一点需要注意的是，部落是一个虚拟的组织结构，所以当前部落划分出来后在未来能够便捷地持续演进。另外，划分部落时应遵循“IT的结构体现业务结构”的原则，当业务发生变化时，IT也随之变化。传达的理念就是，不要有人员边界的概念，要能够将业务与IT融合在一起，IT服务于业务，IT组织结构服务业务战略。

双线考核，推动高绩效

部落层级有五大角色，业务负责人、部落长、测试分会长、架构师和版本经理。有三个小队级角色，产品经理、小队长和研发小队成员。

部落长通常由科技侧的分组经理来承担，管理整个团队，跟业务一起负责交付，同时调配资源；业务负责人会授权产品经理去做优先级高的事情，有优先级冲突时业务负责人会进行协调；测试分会长就是测试的职能经理，负责守护部落的交付质量；架构师负责把关部落的技术质量；版本经理负责系统版本交付。

部落长与业务负责人，这两个角色非常重要，通常分别由科技侧和业务侧的人担任，只有他们进行很好地融合，才有可能让目标一致化。

原本职能部门既要负责资源整合与分配，也要负责交付与绩效考核。带来的问题是，没有形成跨职能团队，快速交付，网状结构沟通线复杂，协作困难；同时负责交付与考核，不利于推进改进。

在形成部落化组织之后，资源整合与分配、能力画像与培养、技术标准与方案评审、效能分析与人员考核、系统创新与系统优化、持续学习与反馈等职责还是由职能线负责，但是像需求交付、版本规划、质量守护、系统维护等应该交给部落负责，因为部落对业务负责。

在部落化组织中，对职能经理的要求有所转变，职能经理更应该注重对人员的培养，基于业务未来的发展方向，应该规划哪些能力，持续对成员进行赋能，这样才能提升组织的整体能力。

部落制下个人绩效的考核主要有两个部分（如下图），一个是职能线的考核，涉及个人效能、领导评分、行政考核；另一个是交付线的考核，涉及整个团队的交付产能、交付速度、交付质量和业务达成度。通过这种模式，个人既能在交付团队拿到考核分数，也能考量职能的发展，而且考核权还是职能经理手上，因为只有职能经理才能更好地比较不同部落之间人员的整体情况。因此绩效的设计，考核权还是职能经理手上，同时绩效还会来源于业务交付相关的部落团队，进行综合评分。

绩效考核涉及到指标的度量：

在职能线，个人效能包括产出吞吐量、质量情况、代码情况、点亮情况、个人贡献度；领导评分包括部落复杂度、个人效能、部落长评分、小队长评分；行政考核包括考勤、合规等。

在交付线，交付产能包括需求吞吐量；交付速度包括端到端时效、阶段时效；交付质量包括缺陷等级分布、缺陷修复时效、版本合规性；业务达成度包括评分机制、业务达成等。不同组织可能存在差异，总体上需要进行双向考核。

跨越鸿沟，业产研一体协同

在部落化组织中，业务的产品经理与技术团队需要融合，因此需要对产品经理进行定位，主要有三种模式；第一种是产品即业务模式，是目前的前沿模式，产品经理属业务团队，职责为产品端到端管理，含产品规划、设计、交付、运营等；第二种是独立产品经理模式，产品经理设置独立部，职责含产品交付与部分产品设计；第三种是技术产品经理模式，产品经理属技术团队，职责偏产品交付管理。

在小队中，产品经理是产品的总负责人，当业务不熟悉产品时，IT需要帮他们理清需求，帮助团队把需求质量、交付质量做得更好，要从团队整体出发，实现目标的最大化。在实现产品即业务模式的过程中，产品经理的培养需要循序渐进，逐步形成交付+管理+规划的能力矩阵。产品经理要做的事，包括产品短期核心指标、改进方向与预期梳理、产品季度目标和产品路线图，本质就是加强产品规划能力，促进组织协同力提升，才有可能跨越业务领域与IT之间的鸿沟，以更好更快达成组织目标。

除此之外，业产研协同还需要建立科学的需求管理机制。Adapt需求漏斗（如下图）是经过许多大型金融机构验证过的有效模型，其目标是加强需求存量管理，确保产品迭代有活水，不泛滥。基于这个规划，去看需求意向数，需求数量的多少代表创意够不够；编写评审中需求数，看规划快不快；待排期需求数，判断容量够不够；本月研发测试的需求数，看交付快不快；比较上月需求的吞吐量，看速率稳不稳。从这每一层级可以判断，需求是否都进行捕获，价值思考是否充分、人员是否充足、当前时效能否支撑业务、需求是否稳定等。

业产研协同中的项目管理，包括过程管理和规划管理。就是基于某个已排需求的月份排布情况，去看整体的规划，业务需求按计划完成展现规划图，看上去像产品路线图。我当时对团队有一个要求，任何提出来的需求，在提出需求时就要写上计划完成日期。一个连完成日期都没有的计划就像没有计划的愿望，很难进行管理。所以需求一经提出就应该有计划完成日期，然后进行滚动规划。关于需求规划的情况，需要工具的支撑，将规划进行可视化的展现，帮助大家对齐信息（如下图）。

持续规划机制，致力全局最优

部落化组织在形成之后是否会形成新的部门墙？为了避免这种情况的出现，组织需要进行持续规划（如下图）保持自身的柔性。

首先是年度规划，即使现在的敏捷组织面对未来充满不确定性，但年度规划的全景图仍然要有，比如规划给每个部落多少人，投入多少，要做大概的预算。

其次是季度规划，回顾每个季度最重要的事情，在季度末看看下个季度最重要的是什么。在做规划时，产品经理、部落长都会参与盘点季度的重点项目，这时就会根据重点项目的情况去调配人力，甚至跨部落去协调人力。因为一个业务领域对应多个部落，所以业务领导进行跨部落调配显然较为高效。

再者是月度规划，室经理主导，业务领导也会参与，这时需要考虑的是部落内人力的调配和需求优先级，因为重点项目已经在季度规划中协商好。

接下来是版本规划，这时产品经理唯一要思考的是在当前现有的人力和资源下，到底能完成多少需求，并确定需求的优先级。

在形成部落组织之前，项目中声音大的一方可能会让领导觉得更重要，这也是职能型和传统的矩阵型组织靠职能经理协调资源时常见的问题。因为大家都看不清整体的情况，缺少按业务线对齐的机制，不清楚每个领域初始的人力情况，然后形成所谓的“公地悲剧”，大家过度占据公共资源，不能整体考虑全局。

只有按业务领域去划分人力，又有动态调整的机制，才能保障整个公司全局的最优化。通过季度规划中的IT检视会，月度规划中的业务内审，版本规划中的迭代计划，来落实整体规划。其中，产品经理日常中需要考虑的是，能拿到多少战略项目，业务的价值以及需求总量，通过季度检视作为输入输出，调整运行，将团队做大做强。

随着部落人员的增多，管理也面临挑战，相应的系统支撑可以有效解决这个问题。通过实时展示部落人员、需求开发进展，能及时了解部落之间的关系与人员的投入情况，帮助组织进行过程管理，知微系统就是这样一个人事合一的数字化管理平台（如下图）。借助IT侧透明所有的人员情况，业务与科技共同定义一个研发与业务协同的价值流，部落状态一目了然，摆脱了以往资源散落各处无法利用的窘境。