团队职责说明书回答的是“谁对什么负责、做到什么程度、与谁交接”这三个问题。它面向团队整体和团队内的各个角色，把团队目标、职责分工、权限边界与协作接口写清楚。一份完整的职责说明书通常包含团队使命与目标、范围与边界、角色清单、职责事项、权限与决策范围、协作接口与交接、产出物与完成标准、汇报与升级路径、维护规则九类要素。下面按层次逐项说明，并划清它与岗位说明书的分工。
要点总览（TL;DR）
- 团队职责说明书围绕团队整体与团队内角色，回答“谁对什么负责、做到什么程度、与谁交接”，核心要素可按团队层、角色层、协作层三个层次组织。
- 团队层要素包括团队使命与目标、范围与边界；角色层要素包括角色清单与定位、职责事项、权限与决策范围、产出物与完成标准；协作层要素包括协作接口与交接、汇报与升级路径、职责变更与维护规则。
- 与岗位说明书的分界在三个维度：对象上团队与角色对单个任职者岗位，粒度上职责分工与协作接口对任职资格与个人考核，用途上团队运行与跨角色协同对选聘、薪酬与绩效。
- 常见误解是把职责说明书写成任务清单、个人岗位描述或部门职能摘抄，纠正方向是补充权限范围、产出标准和交接对象，让每条职责可被检验。
- 职责说明书需要维护规则配套，约定修订触发条件、维护责任人和复核周期，并与工作项配置同步更新，避免纸面分工与实际流转脱节。
团队职责说明书的核心要素有哪些
核心要素可以按“团队层—角色层—协作层”三个层次组织。团队层说明这个团队为什么存在、管到哪；角色层说明每个角色承担什么、能决定什么；协作层说明角色之间如何交接、出问题找谁、文档如何随变化更新。三层缺一层，文档就会停留在口号或清单的层面，难以指导日常运行。
| 层次 | 要素 | 回答的问题 |
|---|---|---|
| 团队层 | 团队使命与目标 | 这个团队为什么存在，承接哪些业务目标，成功用什么结果衡量 |
| 团队层 | 范围与边界 | 团队负责哪些对象和环节，哪些事项由其他团队负责 |
| 角色层 | 角色清单与角色定位 | 团队内设哪些角色，每个角色在团队中处于什么位置 |
| 角色层 | 职责事项 | 每个角色对哪些工作内容和业务对象负责 |
| 角色层 | 权限与决策范围 | 哪些事可以自行决定，哪些需要审批或会签 |
| 角色层 | 产出物与完成标准 | 角色交付什么，交付到什么程度算完成 |
| 协作层 | 协作接口与交接关系 | 与谁对接，交接的输入输出是什么，在什么节点交接 |
| 协作层 | 汇报与升级路径 | 向谁汇报，出现分歧或阻塞时按什么路径升级 |
| 协作层 | 职责变更与维护规则 | 谁负责更新，什么情况下触发修订，多久复核一次 |
这九项要素中，团队使命与目标是推导起点，角色清单和职责事项是主体内容，权限、产出标准、协作接口、升级路径共同构成角色之间的运行规则，维护规则则保证文档在团队调整后仍然有效。写作时不必追求篇幅，关键是每一项都能对应到具体的人、事和判断标准。
团队职责说明书的定义与适用边界
团队职责说明书是面向团队整体与团队内角色，说明职责分工、权限边界与协作关系的管理文档。它的覆盖范围包括三块：团队目标如何承接组织目标，各角色承担哪些职责事项，角色之间在哪些节点交接、按什么路径升级。判断一份文档是否属于职责说明书，可以看它是否同时交代了“团队管什么”和“角色之间怎么配合”。
它不覆盖的内容需要明确区分。单个任务的负责人指派、任务拆解与责任追踪，属于任务分配与责任管理的范畴，由任务清单、项目计划等载体承担；人员的技能盘点、能力评估与人员配置，属于资源技能与匹配管理，由技能矩阵、资源计划等文档承担。把这些内容塞进职责说明书，会让文档变得臃肿，也难以维护。
与相邻文档相比，区别在于回答的问题不同。项目章程回答“这个项目为什么做、目标与授权是什么”，聚焦一次性的项目投入；组织架构图回答“谁向谁汇报、部门如何设置”，聚焦汇报关系；团队职责说明书回答“团队内每个角色对什么负责、与谁交接”，聚焦日常运行中的分工与协作。三者可以互相引用，但各自承担不同的管理任务。
各要素如何组成一份可运行的职责说明
要素之间靠一条推导链连接起来：团队使命与目标决定团队需要完成哪些关键工作，关键工作按业务对象和环节归并成职责模块，职责模块再分配到具体角色，形成职责事项。每个职责事项后面紧跟权限说明和产出标准，说明这个角色能决定到什么程度、交付物达到什么状态算完成。这样写出来的条目可以直接用于日常判断，而不是停留在“负责相关工作”这类表述上。
协作接口的表达需要落到具体节点。常见写法是：某角色在某个阶段向另一角色提交什么输入，对方在什么时限内反馈什么结果，出现分歧时由谁裁定。交接关系写清楚输入、输出和时限，跨角色协作中的推诿和遗漏就会明显减少。汇报与升级路径则补充例外情况：常规事项按职责自行处理，超出权限或跨团队冲突时按既定路径升级。
维护规则决定文档的寿命。可以约定触发修订的情形，例如团队目标调整、角色增减、关键流程变更；明确维护责任人，通常是团队负责人或指定的文档 owner；设定复核周期，例如每季度或每半年复核一次。职责说明书写完就锁进文件夹，团队调整后无人更新，是这类文档失效最常见的原因。
在实际运行中，职责说明书往往需要与工作项和文档协同维护。以 ONES 为例，团队可以把职责说明书作为团队文档沉淀，把角色承担的职责事项对应到工作项类型和负责人字段，交接节点通过工作流状态体现。团队调整时同步更新文档与工作项配置，能让纸面分工和系统里的实际流转保持一致。这一衔接适用于已经在使用项目协作工具的团队，尚未工具化的团队用文档加定期评审同样可行。
团队职责说明书与岗位说明书的边界划分
两者容易混淆，是因为都涉及“职责”二字。区分的关键在对象、粒度和用途三个维度：职责说明书以团队和角色为对象，岗位说明书以单个任职者岗位为对象；前者写到职责分工与协作接口，后者写到任职资格、个人考核指标；前者服务于团队运行与跨角色协同，后者服务于人力资源的选聘、薪酬与绩效管理。
| 维度 | 团队职责说明书 | 岗位说明书 |
|---|---|---|
| 对象 | 团队整体与团队内各角色 | 单个任职者岗位 |
| 粒度 | 职责事项、权限边界、协作接口与交接关系 | 任职资格、能力要求、个人考核指标 |
| 用途 | 团队运行、跨角色协同、交接与升级 | 人员选聘、薪酬定级、个人绩效评估 |
| 维护主体 | 团队负责人或指定文档 owner | 人力资源部门与岗位所属管理者 |
两者是配合关系。岗位说明书确定某个岗位需要什么样的人、如何评价个人表现；职责说明书确定团队内角色之间如何分工与交接。同一个人可能在一个团队中承担多个角色，也可能跨团队承担角色，这时以职责说明书描述其在具体团队中的分工，以岗位说明书描述其岗位本身的要求，两份文档各司其职。用岗位说明书替代职责说明书，会缺少协作接口和交接规则；用职责说明书替代岗位说明书，则无法支撑选聘与个人考核。
具体例子与常见误解
下面是一个角色条目的填写示例，演示要素如何落到一条可执行的描述中（示例为演示情景，非真实团队案例）：
- 角色名称：需求接口人
- 角色定位：连接业务方与研发团队，负责需求进入团队前的澄清与排序
- 职责事项：收集业务方需求，组织需求澄清，维护需求优先级列表
- 权限与决策范围：可决定需求澄清是否通过；优先级调整需与团队负责人共同确认
- 产出物与完成标准：需求说明文档，包含背景、目标、验收要点，经业务方确认后视为完成
- 协作接口：向研发角色提交已澄清需求；接收研发角色的可行性反馈，两个工作日内回复业务方
- 升级路径：需求冲突无法在团队内解决时，提交团队负责人裁定
常见误解有三类。第一类是把职责说明书写成任务清单，逐条罗列日常待办，结果文档随任务变化频繁失效；纠正方向是回到职责模块，按业务对象归并，任务清单另行管理。第二类是把角色条目写成个人岗位描述，写入任职年限、学历要求和个人考核指标，偏离了团队分工的用途；纠正方向是把个人要求移到岗位说明书，职责说明书只保留角色层面的分工与接口。第三类是把部门职能摘抄过来，写成“负责某某管理工作”的笼统表述，无法判断边界；纠正方向是补充权限范围、产出标准和交接对象，让每条职责都能被检验。
这三类误解的共同后果是文档看起来完整、用起来无从下手。检验方法很简单：拿一条职责描述去问团队内两位成员，如果他们对“这件事谁决定、交付什么、找谁交接”的回答不一致，这条描述就需要补充权限、产出标准或协作接口。
常见问题
团队职责说明书和岗位说明书可以合并成一份文档吗？
可以放在同一份文档体系里，但建议保留两个独立部分。岗位说明书面向单个任职者岗位，承载任职资格、能力要求和个人考核指标，主要服务于选聘、薪酬与绩效；团队职责说明书面向团队与角色，承载职责分工、权限边界和协作接口，主要服务于团队运行与跨角色协同。合并时按用途分节，各自维护主体不同，更新节奏也不同，混写容易让两部分都失去可执行性。
团队规模很小，还需要写职责说明书吗？
小团队同样会遇到“这件事谁决定、交付什么、找谁交接”的问题，只是文档可以更轻。要素不必九项齐全，团队使命与目标、角色清单与职责事项、协作接口与升级路径通常优先保留，权限和产出标准可以写得简短。判断标准是团队内两位成员对同一条职责的理解是否一致，如果不一致，就值得把这条写清楚。
一个人承担多个角色时，职责说明书怎么写？
按角色分别列条目，再注明由同一人承担。职责说明书描述的是角色层面的分工与接口，同一个人承担多个角色时，每个角色的职责事项、权限和交接对象分别写清楚，避免把多个角色的权限混在一起。个人层面的任职资格与考核仍放在岗位说明书中，两份文档各司其职。
职责说明书多久更新一次比较合适？
常见做法是设定固定复核周期，例如每季度或每半年复核一次，同时约定触发修订的情形，如团队目标调整、角色增减、关键流程变更。维护责任人通常是团队负责人或指定的文档 owner。固定周期加事件触发两种机制并用，能避免文档长期不更新，也能在团队调整时及时同步。
职责说明书和项目章程、组织架构图是什么关系？
三者回答的问题不同。项目章程说明一次项目为什么做、目标与授权是什么；组织架构图说明部门设置与汇报关系；团队职责说明书说明团队内每个角色对什么负责、与谁交接。它们可以互相引用，但各自承担不同的管理任务，不能用其中一份替代另一份。
