组织结构模型到底是什么？数据治理场景下又如何应用？

原创熊小龙 msup

在谈到组织结构模型时，我们需要思考组织为什么是当前这种结构。如果你了解组织的完整历程，那么可能是清楚的；如果你未经历且未深入了解，就可能不清楚，并且认为存在很多似乎不应该存在的问题。就像一段传承的代码一样，如果有迹可循，你会知道它为什么会如此设计；如果没有人告诉你，你也许会抱怨代码怎么会写成这样。

本质上，任何脱离背景的有关组织结构优劣的谈论，都是不合适的。对一家公司来说，没有最好的组织结构，只有最适合的组织结构。

组织结构

组织结构的概念及类型

根据项目管理知识体系（Project Management Body of Knowledge）中的描述，组织结构是一种事业环境因素，它可能影响资源的可用性，并影响项目的管理模式。组织结构的类型包括职能型组织结构、项目型组织结构，以及位于两者之间的矩阵型组织结构。

基于不同的组织结构，我们从项目经理的职权、可用的资源、项目预算控制者、项目经理的角色、项目管理行政人员五个维度进行了阐述。由此可见，组织结构在某种程度上决定着公司成员的协同模式。

1. 职能型组织结构

典型的职能型组织结构是一种层级式结构，即每位雇员有一位明确的上级，如图1所示。人员按专业分组，如测试组、前端组、后端组、架构组等。各个专业领域还可以根据人数或业务领域进一步划分为职能部门。在职能型组织结构中，各个职能部门可以相互独立地开展各自的项目工作。

2. 项目型组织结构

如图2所示，在项目型组织结构中，团队成员通常集中办公，组织的大部分资源都用于项目工作，项目经理拥有很大的自主性和职权。项目型组织结构是项目经理期待的组织形态，是他们认为“我说了算”的组织形态。

图1 职能型组织结构

图2 项目型组织结构

3. 矩阵型组织结构

矩阵型组织结构兼具职能型组织结构和项目型组织结构的特征，如图11-3所示。我们以平衡矩阵型组织结构为例进行说明，其拥有全职项目经理，但并未授权他们全权管理项目和项目资金，这种组织结构常见的问题是如何处理好“多头管理”，项目经理的能力在一定程度上决定着项目的成败。

图3 矩阵型组织结构

组织结构的选择

面对不同的组织结构模型，组织怎样选择？特别是大公司，如何在发挥组织规模优势的同时，还能享有小公司那样的灵活应对客户需求和市场竞争的能力？

精心设计的矩阵型组织结构就是唯一的解决方案（通常为偏业务型组织）。但是，如果公司没有充分了解这种组织结构就开展变革工作，往往会阻力重重，不能取得预期的效果，进而过早宣告“矩阵型组织结构不适合本公司”，并再次回到职能型、项目型的组织结构。我们从金融保险行业总结了一套对应的Adapt产品部落化组织结构落地方案，为大型企业提供参考。它不仅包含了组织结构的组成方式，也包含了在产品部落化组织下如何进行产品管理和项目管理。

Adapt产品部落化组织

Adapt产品部落化组织来源于Agilean的多年实战经验，是适合中国金融行业的规模化敏捷框架。在帮助金融组织进行数字化落地和敏捷转型的过程中，我们意识到SAFe、Less、Scrum等框架在金融组织落地时，都面临着不同的阻力和困难。而金融组织根据自身特点运用Adapt框架，可以建设敏捷型组织，在科技侧建立与业务对齐的敏捷产品部落，助推业务价值端到端的高质量敏捷快速交付，实现组织数字化战略的落地。

产品部落化组织概览

产品部落化组织（见图4）由对齐业务的产品部落组成。在整个组织中，有不同的职能线组成部落，也有企业级的角色来支撑产品部落运行，如总架构师、总业务负责人、敏捷教练、PMO等。我们认为，在传统的项目管理中，存在“万物皆项目”的情况，难免追求短期利益而忽略产品管理。在产品部落化组织中，建议进行“项目管理+产品管理”双维管理，辅以跨部落月度规划与检视，帮助组织快速解决跨部落协同和高效决策等问题。

图4 产品部落化组织

产品部落

产品部落是与业务对齐的基本单元。

产品部落（见图5）类似于矩阵组织，有横有纵。纵向组织小队和部落面向价值交付，偏重于“用兵”，以价值交付和业绩提升为方向。横向组织分会和行会面向能力提升，偏重于“养兵”，以专业化为方向。

1. 小队

小队是业务端到端交付的最小单元，包含所需业务的产品经理、研发人员，人数一般约为10人。小队长常常由开发负责人担任。有时候小队又被称为“迷你型创业公司”，而产品经理为这家公司的“迷你CEO”。产品经理通常包含在小队内，小队长对产品经理负责，主要任务是管理交付。

图5 产品部落的组织结构

2. 部落

部落是指相同业务领域所有小队的集合，面向具体业务稳定输出，人数一般少于120人。部落长常由具体业务领域的研发负责人担任，对整体交付过程负责。有时候，部落又被称为创业小队的“孵化器”。

3. 分会

在同一个部落中，相同能力领域内拥有相似技能的人员组成的集合称为分会。分会长常由职能团队负责人担任（通常为组长级别），负责员工的发展、薪水设置等。

4. 行会

行会为跨部落的横向组织，常设行会长与协调员，并由协调员进行组织。定位为学习赋能、标准协作，并推动解决行会成员所提出的问题，行会也可作为推动解决端到端特定领域问题的组织。

5. 职能线

职能线为实体职能组织，面向能力培养和提升，偏向于“养兵”，以专业化为方向。职能线负责资源整合管理、人才能力画像、培养体系与晋升路线制定、员工绩效考核、技术专业标准制定、创新管理、持续学习文化。在变革过程中，必然会与原有的职能线有差异，后续会描述在产品部落组织下职能线的差别。

产品部落设计原则

1. 专属的科技团队

拥有专属的科技团队是产品部落制划分的原则之一。这一原则表明，部落内的人力投入情况是相对稳定的。通过团队的专属来保障研发团队能在某一业务领域进行专业深耕，同时对系统更加了解，以保障高质量且快速的交付。由于IT研发并不是简单的逻辑实现，而是需要业务产品研发的思维碰撞，因此这个过程需要长期合作才能达成。只有建立具有业务归属的科技团队，才能更好地提升团队的归属感和成就感。

2. 小队是特性小队或是系统小队

在相对稳定的部落内，小队也是相对稳定的。通过加强与小队的对应，产品经理可以保障稳定的需求输入，为小队的稳定性提供基础。在小队内部划分时，包含了各类角色，基本可以保障端到端的可交付。有时候，有些小队的系统特点比较明显，将它们划分为一个系统小队也是可以的。

产品部落的特点

1. 小队的特点

• 在一起办工。

• 自主管理。

• 拥有设计、开发、测试和发布产品所需的所有技能和工具。

• 拥有长期的使命或任务。

• 专职的产品经理。

• 负责人：小队长。

小队通常是长期稳定的，有特定的使命。比如，专注于个人账户产品的研发工作。小队长不属于行政头衔，这样做的好处是可以把合适的人放在这个位置上，并且可上可下，按需调整，不用经过烦琐的“行政升职”程序。

一个小队长通常只管理一个小队，对小队的交付负责，并统筹协调小队内的工作。由于小队长通常由开发负责人承担，其是一个管理与技术并存的角色，因此小队长需要长期深耕技术，而不应单纯地注重管理。

• 关于工作安排，小队的工作来源于产品经理，小队内的工作安排通常在小队内部完成。职能线的负责人不直接干预小队的工作安排。

• 关于交付需求，小队的需求在大部分情况下可以在小队内实现闭环，根据“二八原则”，80%的需求闭环可以有效提升小队交付效率和决策速率。

• 关于小队人数，在实践过程中，还需要参考小队交付产品的复杂度、角色分工的现实情况、小队长综合能力等情况来考虑，通常不会超过15人。

2. 部落的特点

• 同一办公地点（如果有条件）。

• 每个部落的人数约30~120人。

• 从事相关领域的工作，解决特定的业务问题。

• 为小队提供交流、合作、分享、创新、改进的环境和支持。

• 负责人：部落长。

部落是与业务领域强对应的组织，在业务领域不变的情况下，部落通常是长期稳定的。比如，零售运营部落对应的业务科室是零售运营管理室，只要零售运营管理室存在，对应的零售运营部落就存在。

• 部落调整策略：部落跟随业务的调整而调整，部落的形态即业务的形态。我们也可以说组织结构应该服从于组织战略。当零售运营管理室的业务扩展或调整时，零售运营部落的小队需要跟着做出调整。

• 部落长人选：通常由研发团队的技术经理担任，此职位拥有一定的正式权利，会较好地推动部落内的研发。偶尔也会将业务侧负责人作为部落长，特别是当一个原有的研发组织结构存在不同研发分组或部门对应同一个业务科室时，由业务侧负责人来统筹部落会是一个更好的选择。

• 部落大小：如果公司规模尚小，可能总人数不到120人，这个没关系，遵循以业务领域对齐优先的原则，再参考人数规模。比如，我们曾划分过数字办公部落，此部落主要处理办公室行政类的业务，这类业务被定义为非产粮食类的业务，不得不做，但价值不好体现。我们就在原有的组织架构中，让每个技术组承担一点，总人数不到20人，利用业务领域优先的原则划分为一个部落。

3. 分会的特点

• 每个分会定期开会讨论专业领域中的问题和面临的挑战。

• 分会负责人由分会成员的直线经理担任，负责所有的传统工作。

• 负责人：分会长。

在部落制转型后，受影响最大的就是职能经理（各技术线负责人、技术经理、测试经理等）。我们建议职能经理要切换管理思路，从管人管事转向技术赋能，成为技术专家类与宏观掌控业务方向的人才。

我们认为职能线不可缺少，甚至有时候需要加强。我们常常会看到一些奇怪的现象，后端研发负责人作为技术经理统管前端、后端、Android、iOS等，由于技术栈的壁垒，他们的发展一般不太理想。这时，我们建议增设分会长，增强横向人才的赋能培养。

分会长作为部落内同一技术栈的负责人，承担着人员绩效反馈的职责，同一技术栈内的人才的可比性更强，同时促进共享共建、知识分享。

另外，由于分会长的增加，让散落在各个不同小队的同一技术领域的人员能得到更好的发展，在一定程度上也为公司打造了更多的技术型人才。

4. 行会的特点

• 跨部落的横向虚拟组织。

• 为常驻成员组织培训赋能，并定期处理行会主题相关决策。

• 推动实际工作与问题解决落地。

• 负责新入职人员面试、行会成员绩效反馈。

• 定期进行知识、工具、代码和实践的分享，为兴趣成员提供学习机会。

• 设定行会长、协调员、常驻成员、兴趣成员、观察员等角色。

• 负责人：行会长（长期）。

这里的行会组织，是从组织协调的角度跨各部落组建的具备同一职责的组织。我们定义行会有四大主题：抓对子、用工具、办活动和融工作。

• 抓对子：通过行会组成对子，明确每一周期的目标，并通过定期考核机制同步检视进展。

• 用工具：行会工作线上化管理，并推进部落内工作的线上化管理。

• 办活动：通过行会行事历，定期组织活动，保障行会的活跃度与成员的贡献。每周组织例会，明确主题和事项。

• 融工作：结合实际工作，推进行会协同管理，部落内较难解决的问题由行会成员共同推进。

5. 职能线的特点

• 实体组织。

• 存在的形式多样化，有小队级、分组级、部门级、领域级、公司级等。

大多数企业在业务高速发展的过程中一般都是“野蛮成长”的，缺少整体规划，哪里缺人就补哪里，能力强的人最终负责的部门或分组就多。结果就是产生各种形式的职能线，如有技术经理管理的测试团队，有团队级的测试团队，还有领域级的测试团队，或者公司级的测试团队，这是企业发展多样化的必然结果。

我们承认实体职能线的重要性，在赋能、绩效管理上应该加强。而部落制的魅力在于可以在基本不破坏职能线的情况下，建立以业务对齐的交付部落，把职能经理从协调人力资源中解放出来，使之更好地关注整体技术方面的把控和人员培养，有时间走近业务，提前做好能力储备和规划，给出行之有效的科技侧的方案，更好地服务业务，从此告别“10口锅、8个盖”的低效协调工作。

如果把现有的组织结构定义为组织的第一套操作系统，那么产品部落化组织结构就为企业的第二套操作系统。第二套操作系统依托第一套操作系统，在不动其根基的基础上构建快速响应市场的产品部落化组织。

如何设计产品部落

管理大师明茨伯格预言，矩阵型组织结构是未来组织的终极模式，但同时又指出矩阵结构是不稳定的。很多公司因为没有信心或无法应对矩阵架构中的“多头管理”而选择放弃，仍坚持传统的“统一指挥”原则，导致公司集权和官僚化，无法快速响应市场需求，成为创新的一种障碍；或者走另一个极端，把公司拆分为若干个独立的业务单元，难以实现资源共享。某股份行在转型过程中，主动选择了这种精心设计的矩阵型组织结构，并用它来管理超5000人的研发队伍。产品部落组织中的部落把管理千人降维为管理百人，小队从百人降至十人。产品部落组织同时还解决了企业快速、灵活地响应市场和发挥规模优势之间的平衡问题，最终让大公司像小公司一样灵活运作。下面我们来看看如何划分部落和小队。

部落组建原则：对齐业务领域的纵向交付单元，如图6所示。

图6 部落组建原则

在通常情况下，业务部门作为一家公司的顶层架构，是相对清楚明确的。科技团队需要做的事情：第一，对齐业务的科室；第二，明确部落小队的切分方式（关键业务或系统）；第三，明确小队对应的业务产品经理。

我们总结了部落的划分路径，如图7所示。

这是一种自上而下的划分方式，在划分过程中，需要做好充分的准备和信息的收集与整理。首先确定每个小队主要负责的业务，然后对小队人员根据其负责的关键业务进行调整（一个人只属于一个小队）。当有一个人员负责的关键业务跨小队时，需要做相关工作的交接。图8展示了一个快速划分部落小队的模板。把主要人员（业务人员、产品经理、小队长、测试负责人等）的姓名及每个小队开发与测试人员的总数填上，如果有内外编区分的，需要明确，这样有利于可视化划分的合理性。

图7 部落的划分路径

图8 部落小队划分模板

除了明确小队人员和关键业务或系统，还存在人员、系统共用的情况。比如，UI/UE人员在模板的各个领域是相通的，表示支持所有小队。通常UI/UE人员共用是被允许的，虽然共用，但需要明确主要对接的小队。公共系统支持类，因为它不直接对齐某个子业务领域，本质上是横向支持所有小队，又同时对整个大业务领域负责，这可以是系统小队存在的一种形式。因为测试人员通常职能特点比较强，我们需要明确每个小队有一个测试负责人。

验证部落小队划分是否合理：第一看人数，小队需要在10人左右，如果有内外编的，同样作为一个参数考虑；第二看需求数，如果需求数很少且未来的需求也不确定，就需要考虑划分这样的小队是否合理。

业务人员与产品经理的确定。当团队业务人员又是产品经理时，这两项可以合并。当有产品经理时，尽量避免出现产品经理跨多个小队的情况，如果难于避免，可以让有多个产品经理的小队选出一个主导的产品经理负责最后优先级的确定。业务人员的选定和产品经理稍有差异，以主要提交业务需求的人员为主，不需要列明所有人，通常每一个业务人员都可以提需求，而我们要找的是经常需要提需求的人员。在划分完之后，与产品经理或业务人员对齐服务小队的人员情况及后续的协同工作方式，如对接需求的人员、需求排期的原则等。

至此，部落的初步划分基本完成，如果需要更进一步划分，可以考虑部落外支持人员的情况，包含部落外的公共系统、支持组等。通过划分透明，对应部落的业务人员和产品经理能够更好地理解可编码人员的数量与总人数之间的差异，更好地理解研发的工作模式。

产品部落化组织下的项目管理

在产品部落化组织中，每个小队有自己的产品或业务。而公司始终是有项目的，如产品从0到1的建设过程、产品需要扩展新功能、重点活动支持等，会使用项目方式进行重点跟踪管理，这就是产品部落化组织下的项目管理。

而项目可大可小，涉及的小队、部落、部门或多或少，项目如何进行管理呢？我们认为，还是按原有的方式进行项目管理。唯一的区别在于，小队成员通常不会被抽调进项目，而是在所属小队对涉及的产品或业务进行新增或修改，项目有自己的任务分配和同步机制。而涉及各小队的部分，由各小队的产品经理统一纳入产品规划，根据项目和小队成员情况，进行安排协同。项目管理的组织形式如图9所示。

图9 项目管理的组织形式

产品部落化组织下的绩效

在新的组织结构模式下，如何进行绩效考核是必须要考虑的问题。原职能线有关需求交付、质量守护、版本规划等的职责都交给了部落。我们设计的考核模式如下。

个人起评分 × 个人考核系数 = 个人绩效结果（见图10）

注：个人起评分 = 70%部落起评分+30%小队起评分

其中，个人起评分来自部落+小队，个人考核系数来自职能线，最终得出个人绩效结果。我们注重整体目标和部落指标的达成，同时也关注个人在小队中的表现，这样能使成员从整体上考虑最优的交付，另外表现优异的小队也能有所体现。个人的绩效结果通过纵向交付线被反馈给职能线上级，职能线上级最终给出综合评价。职能线的负责人建议的几个考核维度包括个人效能、领导评分、行政考核等；而部落与小队的考核维度包括交付产能、交付速度、交付质量、业务满意度或业务达成等，如图10所示。

考核指标如图11所示。

图10 产品部落化组织下的绩效考核

注：P85是指第85百分位数。

图11 考核指标

产品部落化组织如何高效协同

在建立新的组织结构并有了新的协同模式之后，这种模式能保持高效吗？能长期指导团队向前演进吗？我们会不会构建出一道新的部门墙？在组织划分时，这通常是领导们所担心的。我们可以从以下两方面解决这些问题。

一方面，强调组织的虚拟性。在组织建立之初，明确这是一个虚拟组织，部落内的各种角色会按需调整。

另一方面，建立部落小队检视机制。按需动态调整人员，让团队成员看到其虚拟性。

我们通过以下方式来动态规划部落和小队。

第一、通过年度规划，把控各部落的整体投入情况。

第二、通过季度规划，根据重点项目和需求情况，提前做好跨部落或部落内的人力调整。

第三、通过月度规划，按需对部落内部的小队人员进行临时调整，如图12所示。

图12 部落人力规划全景图

同时，我们把相关规划内嵌至日常管理并对齐到会议中。对于年度规划，通常大企业都会有第二年的整体预算；对于季度规划，我们会应用IT检视会机制（此机制按月度进行，业务、产品、研发负责人参与对齐重点事项及问题）；对于月度规划，召开部落内的业务内审会议，根据优先级的情况按需做好人力调整；通过各层级对重点事项的把关，最后的迭代计划需要产品经理根据需求的优先级排期。由此，可以保障部落小队机制成为一盘活水，具备动态稳定的能力。这就是产品部落化组织使企业快速、灵活地响应市场并发挥规模优势的秘籍。

如何引入产品部落化变革

企业组织变革是企业为了适应外部环境变化而进行的，以改善和提高组织效能为根本目的的管理活动，其中外部环境的变化是企业组织变革的最大诱因。而如何建立组织的紧迫感和创建转型的“引爆点”，永远不是一件容易的事情。

变革的方法论已经十分成熟，可以参考约翰·科特的《领导变革》一书。产品部落化组织级别的变革，通常是自上而下进行的。康威定律认为：组织的系统设计必然是内部沟通结构的翻版。而产品部落化组织是一个虚拟的动态组织，以交付为目标，并且明确提出原职能经理应更多关注技术赋能职责，前置赋能业务，使这个变化不用伤筋动骨。

下面是一个渐进式引入变革的过程，适合想尝试的中层或高层，如果你只是一个具备理念的个体，需要有一个说服的过程。

渐进式引入变革的过程：在整个产品部落化组织中，最基本的单元是小队，可以先尝试按小队划分工作的方式，对齐业务人员和产品经理。通常，业务人员和产品经理的诉求是能够稳定解决的，实现产品所需要的功能。运营好自己所负责的领域，等到有效果了，再向高层领导建议，并逐步扩大范围。

在大型组织中，我们也常常发现产品部落化组织的影子，只是影响范围小，需要外力的助推，打通和扩大跨部门的协作。

总之，引入变革有自上而下的方式，也有自下而上的方式。关于组织结构的调整，通常自上而下地进行，能够更加快速、有效；如果仅自下而上，会是一个十分漫长且不确定性很高的过程。无论采用哪种形式进行变革，都建议发起转型或主动推动转型的人员，借助外部的力量共同推进。

数字化时代的组织结构

构建以客户为中心的组织能力体系

以客户为中心是企业数字化转型的目标，其含义是打造多层次的以客户为中心的组织能力，包括围绕客户设计组织结构的能力、基于客户场景的创新能力、满足客户体验的互动能力，并在数据、IT、考核机制等各个方面体现“以客户为中心”的理念。

组织结构：从以产品为中心转向以客户为中心的全渠道小队

基于这样的理念设计的组织结构，有利于客户数据打通和洞察，统一客户体验，提高企业资源利用效率。由于企业通常会对组织结构调整牵扯较多的利益方有顾虑，因此组织结构调整需要分步进行。第一步，以关键业务为指导调整部落小队，并将建设以客户为中心的能力作为阶段目标；第二步，在产品部落运作一段时间后，等时机成熟再次做全渠道小队调整。

比如，银行的开户产品既存在于柜面系统中，又存在于移动端。如果以产品为中心划分，则柜面系统有一个产品经理，移动端可能是另外一个产品经理，这样在用户体验上就很难保持一致性。同时，不同的平台在同样的功能优先级存在冲突。而在系统建设时，由于负责的小队不一样，逻辑公用部分同样会产生重复建设、要求不统一的问题。在全渠道小队的建设中，我们面临两个问题：第一个是利益分配的问题，第二个是技术栈的问题。第一个问题的解决需要领导的决策和外部力量的推动，需要我们站在全局最优的角度考虑，同时在绩效考核时要考虑产品经理所负责的产品本身如何有效度量；第二个问题的解决需要科技团队在技术上的升级改造，并组建适当的平台类产品，在平台能力支持的情况下，不同的平台可以通过H5等技术保障技术栈的一致性。

通过建设以客户为中心的全渠道小队，可以进一步降低沟通的复杂度，提升客户体验的一致性，这也是现阶段数字化转型所构建的最优的小队形式。

行会案例—

教你如何打造行之有效的数据行会

背景

在数字化转型的大背景下，数据已成为组织的重要战略资产，数据质量一直是企业面临的巨大挑战，那么通过数据汇集，实现业务状态透明可视，提供基于“事实”的决策支持依据，对数据可信和一致化的要求不言而喻。数据行会应运而生。

面临的问题

在企业内部的系统之间，业务数据不一致。在出现问题后，定位困难，无人全权负责。问题发现后置，同样的问题重复出现，无长效的解决机制。

在一个具有前台部落、中台部落、后台部落、大数据部落的组织中，中台部落、后台部落面临的数据问题严重，需要花大量时间去解决。最终大数据部落面临不少的数据清理工作，并且无法保障数据质量。

数据行会应运而生

数据行会在诞生之初就背负着数据治理、提升数据应用效能的使命。如何让数据在企业内部的系统中保持高效可用，及时发现问题，同时让数据的应用得到用户的反馈，形成闭环，成为行会的主要工作之一。

1. 行会的主要职责

行会的主要职责除了通用的职责，还包含以下特定职责。

• 负责数据相关规范标准的建立，协同机制建设。

• 负责新入人员面试和行会成员绩效反馈。

• 定期进行知识、工具、代码和实践的分享，为兴趣成员提供学习机会。

2. 行会的五大角色

行会的五大角色包括行会长、协调员、观察员、常驻成员、兴趣成员。

行会的角色及其职责如表1所示。

表1 行会的角色及其职责

3. 行会成员的要求

• 掌握数据工作流程。

• 分享数据专业知识及技能。

• 设计并落地数据应用场景。

• 推进数据治理问题解决。

• 思考并优化数据工作协同机制。

• 积极参与或组织行会活动。

4. 行会的四大主题

行会的四大主题：抓对子、用工具、办活动、融工作，如图13所示。

抓对子：行会成员通过结对工作或学习。此案例采用的是一带一机制，本质上一带一的形式多样，资深成员带初级成员，领域互补，结对学习，工作上下游配合等。这是驱动协作的基础，非常重要。我们采用一带一机制的主要原因是新人较多，各部落需要相互学习数据相关知识和业务知识。

图13 行会的四大主题

用工具：所有的协同线上化管理都是前提条件，在企业内部，信息透明且对称从来不是一件简单的事。作为行会，把“用工具”作为四大主题之一，奠定了大家统一口径的基础。通常在企业内存在各种不能进行线上化的理由，如我还不确定这是不是个问题，殊不知不知道是不是问题才是最大的问题，记录下来才是推进问题的基础。

办活动：行会有哪些分享、活动、例会，主题是什么，在什么时间进行，需要行会行事历把行会的工作项有机地整合和推动起来。

融工作：通过数据应用和数据治理两项工作，把行会成员有机地链接起来。参加行会，不仅能促进学习成长，还能帮助快速推动问题的解决，打通不同部落间数据建设相关的工作。而这个工作是长期有效的，行会内工作的好坏与部落内的工作相同，不存在额外的时间投入不被认可的问题。

5. 行会成员评分

行会内有明确的评分规则，从数据治理、数据应用、团队学习、行会贡献四个维度，结合工作对成员进行评分，同时打造学习型组织，鼓励积极推动行会活动的成员。表2所示是特定数据行会的评分规则，可以参考。

表2 特定数据行会的评分规则

6. 行会成员的等级

在每周的行会例会上，同步每个成员的当前等级情况，让有贡献的成员得以体现（并且作为绩效输入）。

行会成员的等级如表3所示。

表3 行会成员的等级

7. 行会的准入准出及相关机制

准入申请：与所在部落的部落长沟通，发入会申请给行会长、协调员（我是谁？我的优势是什么？我能够给行会增添什么价值？我希望从行会工作经历中获取什么？我对行会有什么建议？），经部落长、行会长同意后加入行会。这样的准入申请让成员体会到仪式感。

• 每季度为一期，每季度末进行10%～20%的人员更换。

• 换届评分规则：在成员换届后，在原有评分上减10分，不足10分的重新开始计算。

• 数据行会常驻人数上限：20人。

• 退出机制：在每季度末进入下一期前，将有其他工作安排、参会率低、分享率低、自我提升目标对齐率低的成员退出。

• 评优机制：每季度进行当期优秀一带一结对评选，有书面嘉奖抄送观察员和所在部落的部落长，作为工作绩效表现的参考。

• 一带一结对调整：每季度按需进行一带一结对调整。

• 请假机制：由行会成员正式发邮件向部落长请假，抄送行会长及协调员。注意：你没看错，是向部落长请假。

行会的准入、定期评价和退出机制可以保障行会的活力。在每一季度，行会会评出三类标杆：数据治理标杆、数据应用标杆、行会积极分子。

8. 活动管理

活动管理可以让每个成员有机会参与并同步信息。行会每周例会包含的主题有上次例会待决策项进展、人员组织（行会成员得分、成员加入、人员面试情况等）、数据治理与应用工作、行会议事（需要行会讨论的事项）、专题分享与活动预告。

行会行事日历如表4所示。

表4 行会行事日历

行会通过四大主题，把不同部落的人员连接起来，形成一个强大的赋能型组织，并且融合现有的工作。因为工作的融合，才得以保持行会的活力，并让每一个参与的人员在行会中受益。正是因为行会的存在，才可以打通整个数据链，快速响应客户的诉求，让离客户不同距离的人员能够同样感知到客户，帮助客户解决问题，带来价值，让整个工作更有意义。

某股份行一个部落的划分与进化

这个部落属于某股份行运营部落近期划分的十个部落之一，十个部落划分耗时约1个月。我们采用了上文提到的产品部落划分路径。

划分准备

划分发起方为研发侧，我们成立了专门的组织结构划分专项小组，主要参与人员包含团队长、PMO、架构师、研发分组经理、测试分组经理、BA、系统负责人等。这也是准备阶段的一个重要事项，因为识别重要的干系人能够给后续部落的划分提供很大的帮助。在此阶段，与管理层对齐划分目标和收益有利于获得后续信息的收集重点和注意事项。此项目为CTO发起的项目，得到团队长和PMO的大力支持。

注意：准备阶段通常不会遇到太多阻力，因为才开始找对接人员。

信息收集

获取到组织结构、人员信息等有利于对整个组织的初步认识。在信息收集过程中，我们需要通过一系列访谈来了解组织是如何协同的。从访谈和人员信息中，我们得知这个百人团队有5个测试经理，负责不同系统或模块。通过系统清单，我们获取到每一块投入的开发、测试等情况，我们当时发现，有超过50多个子系统，大的系统有40多个开发人员与30多个测试人员，小的系统仅分配到5%的人力。通过这些信息，我们更深入地了解这个团队是如何聚合在一起的。收集信息应该以一个大部门来收集，因为部门不同的分组可能存在业务交集，只有全局收集，才能把控部落划分的准确性，以上数据是以大部门为基础收集的。

注意：在不同公司中，信息收集的难易程度不同。如果找到合适的人员，你可以当天拿到信息，并在几天之内整理好。如果转型发起部门与研发部门不是一个部门，则可能拿不到你想要的信息，这时候就要想其他办法了。

信息整理

跨过信息收集这个鸿沟，信息整理的质量直接决定部落划分的效率。在架构师的帮助下，我们对系统进行了一些聚合，知道了哪些系统属于一类，以及系统之间的相互依赖关系是什么。比如，与工作流相关的子系统可以支持其他多个系统，属于公用系统，有单独的人员负责。比较大的系统可以按业务领域进行拆分，寻找聚合点。比如，柜面系统本质上包含政府业务、中间业务等。把系统和人进行关联匹配，按照一个人只属于一个小队的原则进行匹配。这里最大的挑战在于，需求的不稳定，人员的共用，关键人员负责多个重要系统，切分后发现找不到合适的人来担任小队负责人，重要的人员被划分到不同的小队，难于割舍。在划分上，不能受限于所获得的现状，深入挖掘有能力的人员或暂留空小队负责人，往前推进。

注意：人员永远是重点和难点，你会得到没有了某人这个系统就运作不下去了、没有合适的小队负责人等反馈。总而言之，对原有负责人来说，一个都不能少。小队负责人可以不用一步到位，由资深人员培养新的小队负责人，待确认其有能力负责时，再正式任命。

部落方案

在信息整理过程中，已初步形成部落方案，这个过程主要是多方对齐信息的一个过程，保障各方对划分达成一致意见，按需进行优化调整，形成最终方案。此外，还需要明确在新体系下的人员职责和协同方式，进行公示，让所有人看到这个变化，让人员正式上岗履行职责。

注意：有仪式感的启动能给新上岗的小队长、测试负责人授权。工作的推进靠的是这些关键人员行为的变化。划分完后需要关注部落小队成员的工作是否在变化。我们曾经在其他客户现场看到过，基于原有组织职能的存在，职能领导会对新小队长提要求，必须按照原有方式协同工作，导致新小队长无法成长。部落方案落地，需要辅导，发现异常情况及时纠正，经过一段时间后，才可让部落和小队机制运作起来，这个需要领导的关注。

以下是一个试点案例，如图14所示。在这个部落划分中，有一个小队由其他分组经理组成，他们按业务维度进行了聚合，同时也存在一个人担任两个小队的小队长的情况，但整体不影响我们的大原则，8个小队共有7个小队长，能够保障以小队形式进行推进。

图14 部落划分案例

部落演进

在运行约3个月后，我们在业务侧进行了变革，实行所有业务产品化，产品经理对应具体的业务产品，不再是一个个零散的业务或系统。研发侧响应以客户为中心的产品思路，打造全渠道小队，进行必要的技术规划，抽象出平台小队，而原有的类似对公柜面这种小队不再存在，变身为对公存款及电子政务、对公金融服务等以业务命名的小队。在公共业务小队运作半年后，我们发现其与其他部门交集更深，最终剩下7个小队，将各小队负责的业务变成产品，这里不再展示调整后的效果。

基于稳定的产品、产品经理、部落、小队，得以分析部落和小队的效能。在有问题的时候，我们能够明确是哪个产品、哪个小队出了问题，进行快速响应。

注意：在运行过程中，通过季度检视、月度检视进行长效管理，保持动态性。在运行十分稳定后，有的部门会渐渐将部落划分为实体组织。最终无论是实体组织还是虚拟组织，都遵行一个原则，即业务变则IT变。在这个案例中，后来的确变成了实体组织，并且年度预算也能够按照部落进行。

部落、小队、行会属于柔性组织，在经过精心设计后，最终形成卓有成效的产品部落化组织。在这个案例中，6个月后推广至10个部落，涉及800人左右。部分部落在落实后，涉及实体组织架构的调整。年底预算已按产品部落方式进行，针对产品规划，进行人力的调配。在部落制落地后，可以让业务产品可视，让人员可视，让协同可视，让规划可视，让进展可视，兼顾宏观视角与微观视角，使优秀小队更易展现，让领导决策得到可信的数据支撑。

展望

某互联网公司在短短8年内，迅速扩张到10万多人。在这样的大背景下，组织变革下一步该何去何从？我们也在积极探索互联网行业的组织结构模型，发现存在类似的部落级结构，也存在按事业部运行的方式。在组织内部，根据产品组建交付团队，在这种情况下，我们也需要谨防以业务对齐的组织实体之间过于隔离而导致的组织柔性不足。建议参考产品部落化组织的结构模型进行优化。

对于任何变革，我们都是从公司整体最优的角度考虑的，不太可能有利于所有人。坚持以业务对齐的IT团队，无论是实体组织还是虚拟组织，都能保障业务和IT目标的一致性。管理层应放弃以部门为权力中心的想法，只有这样才能让团队走得更远。我们要让变化成为工作的日常，而不是等到最后不得不发起变革时再出手。

活动预告：随着数字化浪潮席卷银行创新，FinTech正在悄无声息地改变着金融业的方方面面。对金融社会来说，这是一个由量变到质变的过程。那么，如何通过更加低成本的方式，准确地改变金融行业的方方面面？给大家分享三个落地实践，助力更多金融机构完成数字化转型：

如果大家想了解更多关于研发效能的一线落地实践，欢迎大家来2023ee卓越工程生产力峰会，此峰会将于将于6月2-3日登陆北京，旨在帮助研发团队持续提升工程能力，通过对以BAT、Microsoft、Google为代表的公司在软件工程的标准、实践、度量、工具和改进方面的经验分享，以案例研究的方式和业界共创，共同加强工程能力建设、研发工具投入、工程标准更新与工程素养提升，共同推进软件工程的发展。

首发精彩案例如下：

最后为大家放送一个福利：扫描下方二维码，填写报名信息，即可获得开幕式直播观看资格，同时组委会还将在报名名单中，免费抽取3张大会体验票作为福利，快快行动起来，在现场感受与大咖面对面！如果大家想了解EE大会的更多议题，欢迎点击“阅读原文”查看。

继续滑动看下一个