跨职能团队分工做不好，常见原因往往在起点：还没拆清要交付什么，就先按人头分活了。更稳妥的做法是先定团队目标与本期交付范围，把目标拆成可交付的成果单元，再为每个单元设置唯一主责角色和协作关系，最后用一份可维护的分工表固定输入、输出与交接节点。本文按这条顺序给出角色定义表、分工表字段、完整演示示例和上线后的检查清单，并说明分工机制与任务分配、技能配置各自负责的范围。ONES 可作为分工表与交接记录的承载方式之一，下文在相应环节自然提及。
要点总览（TL;DR）
- 分工从成果出发：先写清团队共同目标与本期交付范围，再拆成五到十个可独立验收的成果单元，最后列出必备职能与阶段性参与职能。
- 每个成果单元只设一个主责角色，协作、评审、支持角色围绕它定义；角色按成果命名，可一人多担、也可跨岗位承担。
- 分工表按成果单元串联输入、动作、输出、交接对象与完成标志，并指定维护人和更新节奏，让任何人能判断工作卡在哪、下一步找谁。
- 分工机制只定职责归属：单任务负责人交给任务分配，人员技能评估与岗位匹配交给资源与技能管理，冲突时按类型回到对应层面处理。
- 上线后按目标变化、成员变动、交接反复出问题等条件校准，并用检查清单核对主责唯一性、交接物可验证性和表格与实际协作的一致性。
分工前先定清楚：目标、成果边界与职能清单
分工的起点是成果，而非人员。先写清团队为什么存在、本期要交付什么，再往下拆角色，能避免出现“每个人都很忙，但没人对结果负责”的局面。这一步的产出是一份团队目标与成果单元清单，附所需职能列表，通常半天到一天可以完成初稿。
第一步：用一句话写清共同目标与本期范围
共同目标要包含服务对象、交付内容和时间范围，例如“在第三季度末为内部客服团队上线一套工单分类规则，使人工分拣量下降”。范围要同时写明本期做什么、不做什么。目标写得越具体，后续判断某个角色该不该设、某项工作该不该接，就越有依据。
第二步：把目标拆成可交付成果单元
成果单元是分工的基本单位，它应当能被独立验收。拆分时问三个问题：这个东西交付后，谁可以直接使用？它完成的标志是什么？它依赖哪些其他成果？一个成果单元通常对应一份文档、一个可运行版本、一套规则或一次评审通过的方案。拆得太粗会导致职责模糊，拆得太细会让分工表变成任务清单，一般控制在五到十个单元较为合适。
第三步：列出所需职能，区分必备与阶段性参与
职能是完成成果所需的能力类别，例如产品设计、数据分析、前端开发、法务合规、运营推广。区分两类：必备职能从头参与到交付完成；阶段性参与职能只在特定节点介入，例如法务只在规则上线前做合规评审。这个区分直接影响后面角色怎么设——阶段性职能适合设为评审或支持角色，不必占用主责位置。
第四步：明确不在本团队范围内的事项
把边界外的事项写下来，例如“系统底层架构改造由平台团队负责”“对外宣传物料由市场部统一出品”。边界清单的作用是在协作中被临时拉入新需求时，有一个可以对照的依据，避免职责无限扩张。以下是一份目标与成果单元清单的填写结构：
| 字段 | 填写要求 | 示例（演示情景） |
|---|---|---|
| 团队共同目标 | 服务对象＋交付内容＋时间范围 | 第三季度末上线工单分类规则，降低人工分拣量 |
| 本期交付范围 | 做什么、不做什么各列几条 | 做：规则设计、灰度验证；不做：工单系统改造 |
| 成果单元 | 可独立验收的交付物，附完成标志 | 分类规则文档，经评审通过并可执行 |
| 所需职能 | 标注必备或阶段性参与 | 数据分析（必备）、法务合规（阶段性） |
| 范围外事项 | 明确由谁承接 | 系统改造由平台团队负责 |
角色怎么设：主责、协作、评审与支持的分层
角色分层的目标是让每个成果单元都有且只有一个主责角色，其他角色围绕它形成清晰的协作关系。笼统写“大家一起负责”，等于没有人负责。角色设计完成后，应产出一张角色定义表，包含角色名、职责范围、决策权限、对接对象四个最小字段。
四类角色的职责差异
主责角色对成果的结果和推进节奏负责，是外部询问进展时的第一联系人，也是争议时的拍板人。协作角色按约定提供输入或共同完成部分工作，对交付质量有贡献但不承担最终结果。评审角色在特定节点给出通过或不通过的意见，拥有否决权但不参与日常推进。支持角色提供资源、信息或工具保障，例如提供数据权限、协调外部供应商。四类角色的关键区别在于对结果的责任程度和决策权，而非工作量大小。
角色与岗位的区别
角色是围绕成果定义的，岗位是围绕组织编制定义的，两者不必一一对应。一个人可以承担多个角色，例如数据分析师同时担任某成果的主责和另一成果的评审；一个角色也可以由跨岗位的人承担，例如运营人员承担规则验证的主责。这样设计的价值在于：当成员变动时，交接的是角色和职责，而非重新划分岗位。
角色定义表的最小字段
| 字段 | 说明 | 填写示例（演示情景） |
|---|---|---|
| 角色名 | 按成果命名，避免用岗位名代替 | 分类规则主责人 |
| 职责范围 | 对哪些成果单元负责，做到什么程度 | 负责规则文档从初稿到评审通过 |
| 决策权限 | 可独立决定什么，什么需上报 | 可决定规则阈值；涉及系统改动需与平台团队确认 |
| 对接对象 | 主要输入来源与输出接收方 | 输入来自数据分析角色，输出交给灰度验证角色 |
角色定义表定稿后，分工的骨架就立起来了。接下来要解决的是角色之间怎么衔接，这正是分工表要承载的内容。
分工表怎么填：输入、动作、输出与交接节点
分工表把角色落到可执行的协作链条上。它的填写逻辑是按成果单元串联上下游：每个单元写清谁主责、谁协作、需要什么输入、做什么动作、产出什么、交给谁、怎样算完成。填写完成后，任何人拿到这张表，都应能判断一项工作当前卡在哪个环节、下一步该找谁。
分工表的核心字段
| 字段 | 填写要求 |
|---|---|
| 成果单元 | 与目标清单中的单元一一对应 |
| 主责角色 | 唯一，对结果负责 |
| 协作角色 | 列出提供输入或共同完成的人 |
| 输入 | 启动前必须具备的材料、数据或决策 |
| 动作 | 该角色实际执行的工作，用动词描述 |
| 输出 | 产出的具体物件，注明形态 |
| 交接对象 | 输出交给哪个角色，何时交 |
| 完成标志 | 可验证的验收条件 |
标出关键交接点与等待风险
交接点是跨职能协作最容易出问题的地方。填写时把每个交接点单独标出，注明交接物的形态——是文档、评审记录，还是可运行版本——以及接收方的验收方式。对依赖外部角色或需要排期的交接，额外标注预计等待时间，作为风险提示。例如“规则文档交给灰度验证角色，需等待测试环境排期约三个工作日”，这样的标注能让计划环节提前预留缓冲。
明确维护人与更新节奏
分工表要指定一名维护人，通常由团队负责人或项目协调角色担任，负责在目标调整、成员变动或交接反复出问题时更新表格。更新节奏建议与团队例会同步，例如每两周核对一次，重大变更随时更新。表格版本要可追溯，避免出现多份口径不同的分工表。在工具层面，ONES 的工作项与文档可以承载分工表和交接记录，让职责归属与交付物状态在同一处被查看和更新，减少表格散落带来的口径不一致。
职责边界怎么划：与任务分配、技能配置分开管
分工机制只解决一件事：某个成果由谁负责、谁协作、谁评审。把任务分配和人员技能管理混进来，分工表会迅速膨胀成任务清单和人员档案的混合体，反而失去可维护性。三者的分工如下：
| 机制 | 回答的问题 | 典型载体 |
|---|---|---|
| 分工机制 | 哪个成果由哪个角色主责，协作与评审关系如何 | 角色定义表、分工表 |
| 任务分配 | 某个具体任务今天由谁做、做到什么进度 | 任务看板、项目计划 |
| 技能与资源管理 | 成员具备什么能力、如何匹配岗位与调配资源 | 技能档案、资源计划 |
三者的关系是：分工表定职责，任务看板定进度，技能管理定人选。分工表回答“这件事归谁管”，任务看板回答“这件事现在做到哪了”，技能管理回答“谁有能力做”。人员技能评估与岗位匹配不写进分工表，只在角色分配时作为参考依据。
边界冲突时的处理原则
遇到问题时先判断它属于哪一层：如果两个角色都认为某件事该对方做，回到分工表核对职责范围与决策权限；如果任务延期但职责清晰，回到任务层检查排期与依赖；如果某个角色长期无法胜任，属于技能与资源问题，应调整人选或补充支持，而非修改职责定义。这条原则能防止用改分工表的方式掩盖进度或能力问题。
一个完整示例：从目标到分工表
以下为演示情景，用于说明分工全过程，不作为真实案例引用。假设一个跨职能团队要在六周内为内部客服上线工单自动分类规则，成员来自数据分析、产品、运营和工程四个职能。
目标与成果单元拆分
共同目标：六周内上线分类规则，使人工分拣量下降。成果单元拆为三个：分类规则文档（评审通过）、灰度验证报告（覆盖主要工单类型）、上线切换方案（含回滚步骤）。范围外事项：工单系统本身的改造由平台团队负责。
角色分配与分工表填写
| 成果单元 | 主责角色 | 协作角色 | 输入 | 输出 | 交接对象 | 完成标志 |
|---|---|---|---|---|---|---|
| 分类规则文档 | 规则主责人（数据分析） | 产品、运营 | 历史工单样本、业务分类口径 | 规则文档 | 评审角色（产品负责人） | 评审通过并签字确认 |
| 灰度验证报告 | 验证主责人（运营） | 数据分析、工程 | 规则文档、测试环境 | 验证报告 | 规则主责人 | 主要工单类型覆盖率达标 |
| 上线切换方案 | 上线主责人（工程） | 运营、平台团队 | 验证报告、系统接口说明 | 切换方案与回滚步骤 | 团队负责人 | 方案评审通过并可执行 |
关键交接点与典型争议处理
本示例有两个关键交接点：规则文档交给评审角色时，需附上样本数据来源说明，否则评审无法判断规则依据；验证报告交给规则主责人时，需注明未覆盖的工单类型及原因，避免上线后出现盲区。
典型争议一：运营认为规则阈值应由自己定，数据分析认为属于规则设计范围。处理方式是回到角色定义表，确认阈值调整属于规则主责人的决策权限，运营通过验证报告提出调整建议。典型争议二：灰度验证因测试环境排期延后，团队一度想修改分工表把验证工作并入规则主责人。处理方式是判断这属于进度与资源问题，保持职责不变，由团队负责人协调环境排期。这两个争议说明：分工表稳定，进度和资源问题在各自层面解决，协作才不会反复推倒重来。
分工落地后的校准与完成检查
分工表不是一次性文档。上线后需要用固定节奏校准，并用检查清单判断它是否真正可用。校准不必频繁，但触发条件要明确。
校准的触发条件
- 团队目标或本期交付范围发生变化，成果单元需要增删；
- 成员变动导致某个角色无人承担或一人承担过多；
- 同一交接点反复出现延误、返工或信息缺失；
- 出现两个角色都认为不归自己管的事项。
出现上述任一情况时，由维护人发起分工表更新，并在团队例会上同步变更内容与影响范围。
分工完成检查清单
- 每个成果单元是否都有唯一主责角色，且该角色知晓自己的决策权限；
- 协作角色、评审角色与支持角色是否都有明确介入节点，而非全程挂名；
- 每个交接物的形态是否具体，完成标志是否可验证，例如“评审通过”需注明评审人和通过标准；
- 分工表是否与实际协作一致：随机抽取三项近期工作，核对实际执行人与表中角色是否吻合；
- 范围外事项是否仍由约定团队承接，没有悄悄回流到本团队；
- 分工表是否有明确维护人和最近一次更新时间。
检查中发现偏差时，按偏差类型修正：职责归属不清的，更新角色定义与分工表；进度落后的，回到任务层调整排期；能力不匹配的，交由资源与技能管理环节处理。把分工表当作一份随团队演进而持续维护的协作约定，跨职能团队的责任归属才能在每次交付中保持清晰。
常见问题
团队规模很小，还需要单独做角色定义表和分工表吗？
需要，但可以精简。小团队同样会出现“以为对方在做”的空档，角色定义表至少保留角色名、职责范围和决策权限三项，分工表至少保留成果单元、主责角色、输出和完成标志四项。人数少时一人多担更常见，把兼任关系写清楚反而更重要，避免同一件事被两个人同时推进或同时搁置。
阶段性参与的职能，比如法务或安全评审，应该设成什么角色？
适合设为评审角色或支持角色，不必占用主责位置。关键是在分工表里写清介入节点和评审标准，例如“规则上线前完成合规评审，评审不通过则暂停上线”。如果只写“法务参与”，实际执行时容易出现要么介入太晚、要么全程被拉进会议的情况。
分工表定好后，成员临时请假或离职，职责怎么交接？
交接的是角色，而非岗位。先看该成员承担了哪些角色，把每个角色的职责范围、决策权限和对接对象原样转给接替者，再更新分工表中的主责角色与协作角色。如果短期内找不到接替者，由团队负责人临时承担主责并明确期限，避免出现无人拍板的成果单元。这类变动属于校准触发条件，应在例会上同步影响范围。
分工表和项目计划、任务看板会不会重复，能不能只保留一份？
三者回答的问题不同，合并会牺牲可维护性。分工表回答“这个成果归谁负责、谁协作、谁评审”，项目计划回答“什么时候做到哪一步”，任务看板回答“今天谁在做哪件事”。实践中可以让分工表保持稳定、按季度或触发条件更新，任务层随进度每日变动。若团队规模很小、交付周期很短，可把分工表压缩成一页，但仍建议与任务看板分开维护。
分工表执行一段时间后发现某个角色长期无法胜任，应该改分工表吗？
先判断问题类型。职责范围本身设计不合理，例如一个角色同时主责三个成果单元导致顾不过来，属于分工问题，应调整分工表；职责清晰但执行者能力或资源不足，属于技能与资源问题，应调整人选、补充支持或重新匹配，而非修改职责定义。用改分工表的方式掩盖能力问题，会让职责边界越来越模糊。
