下载掌阅APP，畅读海量书库
立即打开
Adapt框架源自Agilean公司的多年实战经验，是适合我国金融组织的规模化敏捷框架。在10多年帮助金融组织进行数字化落地和敏捷转型的过程中，我们意识到，SAFe、LeSS、Scrum等框架在金融组织落地时由于存在一定简化而面临着不同的阻力和困惑，而金融组织根据自身特点运用Adapt框架，可以建设敏捷组织，在研发侧建立与业务领域对齐的产品部落，助推业务价值端到端的高质量敏捷快速交付，实现组织数字化转型落地。产品部落组织阵型本质上也采用了研发是一种投资行为的理念，蕴含使用产品预算的方式来规划小队。
Adapt框架中的产品部落组织由与业务领域对齐的产品部落组成，如图3-6所示。
图3-6 Adapt框架全景
在整个组织中，有由不同的职能线组成的产品部落，还有中心级的角色（如首席信息官、首席架构师、效能经理等，注意此处是科技管理视角）来支撑产品部落运行。在传统项目管理中，存在“万物皆项目”，追求短期利益而忽略产品管理的情况。在产品部落组织中，建议采用“项目管理+产品管理”双维管理，并加强跨部落的月度规划和检视，以帮助组织快速解决跨部落协同和决策方面的问题。3.3节和3.4节聚焦在Adapt框架的产品部落部分。
产品部落是与业务领域对齐的基本单元。产品部落组织阵型（见图2-4）类似于矩阵型组织阵型，有横有纵。纵向组织小队和部落面向价值交付，偏重“用兵”，以价值交付和业绩提升为方向。横向组织分会和行会面向能力提升，偏重“养兵”，以专业化为方向。部落、小队、分会、行会、职能线的定义以及它们之间的关系参见2.2.2节。
这里需要特别提出的是，除了面向交付的部落和养兵的职能线，仍然有职能型部门不属于我们通常理解的产品部落，如运维部门。运维部门的人相对较少，且需要隔离运维的复杂性，通常这个部门的人员需要统一管理，部门内流程相对刚性以保障生产的稳定。有时候在部落化时我们会直接把运维部门作为一个部落，再在该部落下按能力域划分职能小队，以与不同的开发部门进行运维工作的对接。
产品部落的设计原则有以下两条。
（1） 部落对齐或拉通相关业务与产品线 。专属的研发团队是产品部落划分的主要原则，这一原则表明，部落内的人力投入情况是相对稳定的。通过研发团队的专属性来保障研发团队能在某一业务领域进行专业上的深耕，同时对系统更加了解，以保障高质量、快速地交付。由于软件研发并不是简单的逻辑实现，而是需要业务产品研发的思维碰撞，因此这个过程需要长期合作才能实现。只有建立具有业务归属的研发团队，才能更好地提升团队的归属感和成就感。从预算的视角来看，研发预算作为一种投资行为也是一种很好的体现。
（2） 小队是特性小队或系统小队 。对于相对稳定的部落，小队也是相对稳定的。我们通过加强产品经理与小队的对应，产品经理通过规划保障稳定的需求输入，为小队的稳定性提供基础。在小队划分时，其中包含各类角色，基本可以保障端到端的可交付。有时候，有些小队的系统特点比较强，将它们组合为一个系统小队也是可以的。我们主张平台类的系统也需要有产品经理，以从支撑业务发展的角度进行平台能力规划和建设，有时候此类产品经理可以设立在研发侧。
下面详细介绍一下产品部落的特点。
（1）部落是与业务领域强对应的虚拟组织，在业务领域不变的情况下，部落通常是长期稳定的。例如，零售运营部落对应业务科室的零售运营管理室，只要零售运营管理室存在，对应的零售运营部落就存在。部落的特点如下：
● 同一办公地点；
● 每个部落为30～100人；
● 从事相关领域的工作，解决特定的业务问题；
● 为小队提供交流、合作、分享、创新、改进的环境和支持；
● 负责人是部落长。
部落调整策略是指部落跟随业务的调整而调整， 部落的形态即业务的形态 。当零售运营管理室的业务拓展或调整时，零售运营部落的小队需要随之做出调整。
部落长人选通常为研发团队的技术经理，此职位要有一定的正式权力，才能较好地推动部落内的研发工作。偶尔也会选择业务侧负责人作为部落长，特别是当一个原有的研发团队组织阵型存在不同研发分组或部门对应同一个业务科室时，由业务侧负责人来统筹部落会是一个更好的选择。
部落大小依据公司规模而定，如果公司规模尚小，负责某个业务领域的技术人员数量远小于100人，原则上部落优先与业务领域对齐，再参考人数规模。例如，我们曾划分过数字办公部落，此部落主要负责行政类内部系统，被定义为“非产粮食类”的业务，这种业务不得不做，但价值不好体现。我们就在原有的组织架构中，将这种业务分给每个技术组，让他们各自承担一点儿，利用优先与业务领域对齐的原则将各技术组人员划分为一个总人数不到20人的部落。
（2）产品部落包含多个小队，这些小队通常是长期稳定的，有特定的使命，例如专注个人账户产品的研发工作。小队的特点如下：
● 成员通常坐在一起；
● 自主管理；
● 拥有设计、开发、测试和发布产品所需的所有技能和工具；
● 拥有长期的使命或任务；
● 有专职的产品经理；
● 负责人是小队长。
小队长为一个虚拟的角色，非行政头衔。这样做的好处是可以把合适的人放在这个位置上，并且可上可下，按需调整，不用经过烦琐的行政升职方式。一个小队长通常只管理一个小队，小队长对小队交付负责，并统筹协调小队内的工作。由于小队长通常由开发负责人担任，是一个管理与技术并存的角色，因此我们建议小队长长期深耕于技术，而不只是担任管理角色。
关于小队工作协同和人数有以下几点说明。
● 关于工作安排，小队的工作来自产品经理，小队内的工作安排通常由小队内的各种角色完成。职能线的负责人不直接干预小队的工作安排。
● 关于交付需求，小队负责的需求在大部分情况下可以在小队内闭环。根据“二八原则”，八成需求“自闭环”，可以有效提升小队的交付速度和决策效率。
● 关于小队人数，在实践过程中，还需要结合小队交付产品的复杂度、角色分工的现实、小队长的综合能力等情况进行考量，通常不会超过15人。
（3）产品部落可以包含多个分会，聚焦部落内专业领域能力的提升。分会的特点如下：
● 每个分会定期开会讨论专业领域中的问题和面临的挑战；
● 分会负责人是分会成员的直线经理，承担所有的传统职责，如管人、管绩效；
● 负责人是分会长。
分会长作为部落内同一技术栈的负责人，承担着人员绩效反馈的职责。从同一技术栈视角评估，人的可比性才更强，也更能促进共享共建和知识分享。
另外，由于增加了分会，让散落在各个不同小队的同一技术领域的人员能得到更好的发展，在一定程度上也为公司培养了更多的专业人才。除此之外，原职能线既管人又管事的职责实际上由部落内分会承担，并且分会长可以根据人员技能、事情紧迫性在一定程度上对部落内人员调配提供建议。
（4）产品部落可以包含多个行会，聚焦跨部落专业领域能力的提升。行会的特点如下：
● 跨部落的横向虚拟组织；
● 为常驻成员组织培训、赋能，并定期处理与行会主题相关的决策；
● 推动实际工作与问题解决落地；
● 新入职人员面试，行会成员绩效反馈；
● 定期进行知识、工具、代码和实践的分享，为行会成员提供学习机会；
● 设定行会长、协调员、常驻成员、观察员等角色；
● 负责人是行会长（长期）。
这里定义的行会并非兴趣组织，而是从协同的角度组建的跨部落、具备同一目标的组织（有时候是技能行会，有时候是跨职能的具有特定组织目标的行会，如数据治理行会）。我们定义行会有四大主题：抓对子、用工具、办活动和融工作。
● 抓对子：通过行会组成对子，明确每一周期的目标，并通过定期机制同步检视进展。
● 用工具：行会工作线上管理，并推进部落内工作的线上管理。
● 办活动：制定活动行事历（把活动标记在日历上的一个计划表），定期组织活动，保障行会的活跃度和行会成员的贡献率。每周组织例会，明确例会主题和事项。
● 融工作：结合实际工作，行会内跨部落协同管理，部落内较难解决的问题由行会成员共同推进。
（5）产品部落包含多个职能线，类似于行会的职责，又同时考虑职能经理的个人能力等情况设立管理团队的大小和范围的大小。职能线的特点如下：
● 实体组织；
● 存在形式多样化，如小队级、分组级、部门级、领域级、公司级等。
如果采用部落制，受影响最大的就是职能经理（如技术线负责人、技术经理、测试经理等）。我们建议职能经理要转换管理思路，从管人管事转向技术赋能，成为技术专家与宏观掌控业务方向的人才。
职能线不可缺少，甚至需要加强。我们常常会看到一些奇怪的现象，后端研发负责人作为技术经理统管前端、后端，以及不同的操作系统等，由于存在技术栈壁垒，他们的发展受限于技术经理这个“天花板”。这时，我们反而建议增加职能经理，增强横向人才的赋能培养。
我们观察到，多数企业在业务高速发展的过程中总存在“野蛮成长”现象，缺少整体规划，哪里缺人就补哪里，能力强的管理者最终负责的部门或分组就越多。结果就生长出各种形式的管理汇报线，如有技术经理管理的测试团队，有团队级的测试团队，还有领域级的测试团队，或者公司级的测试团队。这是企业发展多样化的必然结果。
我们承认实体职能线的重要性，并在赋能、绩效管理上应该加强。而产品部落机制的魅力在于可以在基本不破坏职能线的情况下，建立与业务领域对齐的交付部落，把职能经理从协调人力资源中解放出来，更好地关注整体技术方面的把控和人员培养，有时间走近业务，提前做好能力储备和规划，给出行之有效的研发侧的方案，更好地服务于业务，从此告别“10口锅8个盖”的低效协调工作。
如果把现有的组织阵型定义为组织的第一套操作系统，那么产品部落组织阵型就是组织的第二套操作系统。第二套操作系统依托第一套操作系统的组织阵型，在不动其根基的基础上构建适合组织快速响应市场需求的产品部落组织。业务是动态发展的，研发团队坚持以虚拟阵型对齐业务领域的形式存在，才能永葆组织的弹性。通过将此思想贯穿组织的管理，组织的每个成员才能更好地关注价值交付。
