团队职责说明书要解决的是角色边界和协作接口问题：谁负责什么、能决定什么、交付什么、和谁交接。本文按“定范围—填字段—走步骤—分编写角色—看示例—发布前检查”的顺序，给出可直接套用的字段表、责任分工表和检查清单，帮助团队负责人或流程负责人写出一份可评审、可维护的说明书。
要点总览（TL;DR）
- 编写起点是团队要交付的业务结果，先定目标，再列角色、归并职责域，避免说明书变成岗位罗列。
- 核心字段包括角色与所属团队、职责域、具体职责条目、决策权限与升级路径、关键交付物、交接对象与接口约定。
- 职责条目用“动词+对象+结果”写法，每条能对应一个交付物或完成标准，换人也能据此判断该不该做、做到什么程度算完成。
- 用责任矩阵按关键活动逐格标注主责、参与、审批、知会，校验职责重叠与空白，再组织跨角色评审定稿。
- 发布前逐项核对职责无重叠无空白、接口双方描述一致、权限与升级路径可执行、版本与维护责任人已确定。
先定编写范围：说明书要回答哪几个问题
编写前先把范围写清楚，能避免说明书变成任务清单或人员档案。职责说明书的编写起点是团队要交付的业务结果：团队为什么存在、对谁交付、交付物是什么。围绕这个结果，说明书回答四类问题：有哪些角色、每个角色负责哪些职责域、角色之间的接口如何约定、出现边界争议时按什么规则处理。
以下内容适合写入说明书：角色名称与所属团队、职责域与具体职责条目、决策权限与升级路径、关键交付物与交接对象、协作接口与响应约定、版本与维护规则。以下内容不宜混入：单个任务的负责人指派、人员技能盘点与岗位匹配、绩效考核与薪酬设计。这些属于相邻管理事项，混写会让文档随任务变化频繁失效。
编写范围说明建议包含三部分：团队目标一句话描述；涉及角色清单（按角色而非按人名列出）；明确不写入的内容清单。范围说明经团队负责人确认后再进入字段填写，可以减少后续返工。
职责说明书的核心字段与填写规则
字段统一是说明书可读、可核对的前提。建议使用下表结构，每个角色一行或一个区块，字段含义和填写要求如下。
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 角色名称与所属团队 | 用组织内通用称呼，注明归属团队和汇报关系；一个角色可对应多人，不写具体人名 | 产品经理，归属产品团队，向产品负责人汇报 |
| 职责域 | 用3–6个字概括职责范围，一个角色通常2–4个职责域，避免过细 | 需求管理、版本规划、跨团队协调 |
| 具体职责条目 | 采用“动词+对象+结果”写法，每条只表达一个可判断的动作 | 审核需求变更单，确保影响评估完成后再进入排期 |
| 决策权限 | 写清可自主决定的事项、需审批的事项及审批人 | 可自主调整迭代内需求优先级；跨版本范围变更需产品负责人审批 |
| 升级路径 | 写明争议或超权限时的上报对象和触发条件 | 与研发负责人对排期无法达成一致时，24小时内升级至项目负责人 |
| 关键交付物 | 列出该角色对外的产出物及完成标准 | 版本需求清单，完成标准为需求描述、验收标准、优先级齐全 |
| 交接对象与接口 | 双向书写：输出给谁、对方需要什么输入、响应时限 | 向研发负责人交接需求清单，研发在2个工作日内反馈可行性结论 |
| 协作接口与响应约定 | 约定常规协作的触发方式、响应时限和例外处理 | 紧急线上问题由值班角色发起，相关角色30分钟内响应 |
填写粒度以“换一个人能否据此判断该不该做、做到什么程度算完成”为标准。动词尽量使用审核、编制、确认、发起、归档等可观察动作，避免“负责”“参与”“支持”单独成条。每条职责尽量对应一个交付物，写不出交付物的职责条目通常说明边界还不清楚。
编写步骤：从角色梳理到成稿评审
按以下五步推进，每步都有明确输入、动作、输出和完成标志，便于控制进度。
- 梳理团队目标与业务对象。输入为团队年度目标、主要业务流程和上下游关系；动作为与团队负责人确认团队交付结果和关键业务对象（如需求、版本、客户问题）；输出为一段团队目标描述和业务对象清单；完成标志是负责人确认目标描述无歧义。
- 列出角色并归并职责域。输入为现有组织角色、协作记录和流程节点；动作为列出全部角色，把相近职责归并为职责域，检查是否有角色缺失；输出为角色清单和职责域草案；完成标志是每个业务对象都有对应角色覆盖。
- 逐角色填写字段表。输入为角色清单和字段模板；动作为由各角色代表提供素材，编写人按统一格式整理；输出为完整的职责字段表初稿；完成标志是所有角色字段无空缺，职责条目均含动词和结果。
- 用责任矩阵校验重叠与空白。输入为职责字段表；动作为以关键活动为行、角色为列，逐格标注主责、参与、审批、知会；输出为责任矩阵和待处理项清单；完成标志是不存在两个主责或无人主责的活动，或待处理项已逐条给出处理结论。
- 组织跨角色评审并定稿发布。输入为字段表、责任矩阵和接口约定；动作为召集相关角色逐条核对边界与接口，记录异议并当场或限期消解；输出为评审通过的定稿、版本号和生效日期；完成标志是评审人确认、维护责任人确定、文档完成发布。
角色分工与交付物：谁写、谁审、谁维护
编写过程本身也需要分工，否则容易出现“一个人写完、没人认账”的情况。建议按下表明确各角色的动作、交付物和时点。
| 编写角色 | 主要动作 | 交付物 | 时点 |
|---|---|---|---|
| 团队负责人 | 确定编写范围、团队目标和角色清单 | 编写范围说明 | 启动阶段 |
| 各角色代表 | 提供本角色职责素材、交付物和接口信息 | 角色素材稿 | 字段填写阶段 |
| 编写人 | 按统一字段整合成稿，统一动词和粒度 | 职责字段表初稿 | 整合阶段 |
| 评审人 | 校验职责重叠、空白和接口一致性 | 评审意见与处理记录 | 评审阶段 |
| 维护人 | 登记版本、生效日期，触发修订 | 版本记录与修订说明 | 发布后持续 |
评审人与编写人建议分开设置，评审人优先选择上下游接口较多的角色代表，因为他们最容易发现接口描述不一致的问题。维护人通常由团队负责人指定，组织调整或关键流程变化时触发修订，并在文档中记录修订原因。
说明书定稿后需要在协作工具中承载评审流转和版本管理。以ONES为例，可将职责说明书作为团队文档管理，评审意见在文档评论中留痕，版本与生效日期随文档状态更新；与说明书相关的关键活动可关联到工作项，便于后续按角色核对执行情况。具体功能以团队实际使用的产品版本为准。
示例：一个跨角色协作场景的职责写法
以“需求从评审通过到上线”中的一个交接环节为例，示范职责条目、接口和升级路径的写法。
职责条目示例（产品经理）：编制版本需求清单，确保每条需求包含背景、验收标准和优先级，并在需求评审通过后1个工作日内提交研发负责人确认。
职责条目示例（研发负责人）：评估需求清单的技术可行性与工作量，在收到清单后2个工作日内反馈可行性结论和排期建议；对存在技术风险的需求提出替代方案。
接口约定示例：交接方产品经理输出需求清单，完成标准为字段齐全、优先级明确；接收方研发负责人输入需求清单，响应时限为2个工作日，输出可行性结论和排期建议。双方对同一条接口的描述需保持一致，一方修改时同步通知另一方。
升级路径示例：双方对排期或范围无法达成一致时，由产品经理在1个工作日内升级至项目负责人裁决；涉及跨团队资源冲突的，升级至双方团队负责人共同确认。升级结论记录在需求清单备注中，作为后续追溯依据。
这个示例说明三点：职责条目要写到可判断完成的程度；接口要双向写清输入、输出和时限；升级路径要写明触发条件、上报对象和时限，避免争议悬置。
完成检查：发布前逐项核对
发布前按下表逐项核对，任一项不通过即暂缓发布，处理后再复核。
| 检查项 | 通过标准 | 是否阻断 |
|---|---|---|
| 职责无重叠 | 责任矩阵中每个关键活动只有一个主责角色 | 是 |
| 职责无空白 | 所有关键活动和业务对象均有主责角色 | 是 |
| 每条职责有交付物 | 职责条目均能对应至少一个交付物或完成标准 | 是 |
| 接口双方描述一致 | 交接双方的输入、输出、时限描述相互匹配 | 是 |
| 决策权限与升级路径可执行 | 权限事项明确，升级对象、触发条件和时限齐全 | 是 |
| 版本与维护责任人已确定 | 文档含版本号、生效日期和维护人，修订触发条件已写明 | 是 |
全部通过后即可发布，并把评审记录、责任矩阵和版本信息与说明书一并归档。后续每次组织调整或关键流程变化时，由维护人发起修订，按同样的检查项复核后再更新版本。
常见问题
团队规模很小，还需要写职责说明书吗？
需要，但可以写得更轻。小团队的说明书不必按完整字段表逐项展开，保留角色名称、职责域、关键交付物和接口约定四类内容即可，重点写清容易产生争议的交接环节。人数少时角色常由一人兼任，可以在角色清单中注明兼任关系，避免同一件事出现两个主责。随着团队扩张或流程变化，再按完整字段补充决策权限和升级路径。
职责说明书和岗位说明书有什么区别，能不能合并成一份？
两者关注点不同。职责说明书面向团队协作，写的是角色在业务流程中负责什么、与谁交接、边界争议怎么处理；岗位说明书通常面向人事管理，侧重任职资格、汇报关系和岗位等级。合并会带来两个问题：文档随人员变动频繁失效，且协作接口部分容易被任职信息淹没。实践中可以保持两份文档，职责说明书引用岗位名称，人员技能盘点与岗位匹配放在人事侧维护。
责任矩阵里出现两个角色都主张主责，怎么处理？
先回到活动本身判断：这项活动的完成标准由谁定义、结果由谁对外承担，承担结果的一方通常就是主责，另一方改为审批或参与。如果双方都能说清理由，说明活动颗粒度太粗，可以拆成两个前后衔接的活动，各自设主责。仍无法达成一致的，按说明书中约定的升级路径提交上级裁决，并把结论写入责任矩阵和职责条目，作为后续追溯依据。
说明书发布后，什么情况下需要修订？
常见触发条件有三类：组织调整导致角色归属或汇报关系变化；关键业务流程变化，例如新增评审环节或交接对象变更；评审或执行中反复出现边界争议，说明原有描述已不适用。修订由维护人发起，按发布前的检查项复核后更新版本号和生效日期，并在修订说明中记录原因。日常单个任务的负责人调整不需要修订说明书，按任务分配流程处理即可。
职责条目写多细才算合适？
判断标准是换一个人能否据此判断该不该做、做到什么程度算完成。写到“审核需求变更单，确保影响评估完成后再进入排期”这个程度即可，不必展开具体操作步骤。如果一条职责写不出对应的交付物或完成标准，通常说明边界还不清楚，需要继续拆分或补充。反过来，如果条目细到只对应某一次具体任务，就超出了角色职责的范围，应移到任务管理中。
