编写团队职责说明书，先搭好字段框架，再盘点角色、逐条填写，最后经跨角色评审定稿。成稿要让成员日常能查：谁负责什么、做到什么算完成、和谁交接。本文给出字段清单、五步编写流程、编写与维护分工、条目范例和定稿检查清单，可按序套用。
要点总览（TL;DR）
- 先搭字段框架：角色名称与所属团队、一句话使命、核心职责条目、决策权限、协作接口、关键交付物六项必填，任职要求按需取舍。
- 按五步推进：盘点角色去重、收集现有职责来源、逐角色填写、梳理接口与重叠、评审定稿发布，每步都有输入、输出和完成标志。
- 编写由文档负责人统稿、角色本人填本角色、团队负责人裁定边界与权限争议，避免单人闭门完成导致文档与实际分工脱节。
- 职责条目用可判断完成的动词加明确对象和交付物，把“协助、参与”改成“负责、组织、输出”，并写明权限归属。
- 定稿前逐项核对角色覆盖、条目可验收、权限与审批流程一致、接口双向对应、交付物有接收方、版本与维护方式已写明。
先定结构：一份职责说明书要写哪些字段
动笔前先把表格骨架搭好，后续填写才有统一口径。字段不必多，但要覆盖”这个角色存在为什么、管什么、能定什么、和谁交接、交出什么”五个问题。建议按下表设置字段，其中前六项为必填，任职要求按团队实际取舍。
| 字段名 | 填写要求 | 是否必填 |
|---|---|---|
| 角色名称与所属团队 | 使用团队内通用称呼，注明归属团队或职能线；同一角色跨团队时分别列出 | 必填 |
| 角色使命 | 一句话说明该角色为团队创造的核心价值，控制在30字左右，不罗列具体任务 | 必填 |
| 核心职责条目 | 逐条列出，每条包含动词、对象和结果；一般5–8条，按重要性排序 | 必填 |
| 决策权限与审批范围 | 写明该角色可自主决定的事项、需上报或会签的事项，与现有审批流程保持一致 | 必填 |
| 协作接口与上下游 | 列出主要上游输入方和下游接收方，说明交接内容与交接时机 | 必填 |
| 关键交付物与完成标志 | 每项交付物写明名称、接收方和”做到什么算完成”的判断标准 | 必填 |
| 任职要求或能力要求 | 写与职责直接相关的能力项；团队已有岗位说明书的可引用，不重复展开 | 选填 |
字段确定后先做成空白模板，统一发给填写人。模板中可加一列”条目编号”，便于评审时逐条引用和后续修订留痕。任职要求这一项容易写成通用素质清单，取舍标准是：只保留直接影响职责履行的能力项，其余交给岗位说明书或培训体系承载。
编写步骤：从角色盘点走到定稿
整个编写过程分五步，每步都有明确输入、动作、输出和完成标志，按顺序推进可以避免边写边改、反复返工。
第一步：盘点角色并去重
输入是团队现有成员名单和实际工作分工。动作是按”承担的职责集合”归并角色，把名称不同但职责相同的合并，把一人多角色的情况拆开标注。输出是一份角色清单，每个角色注明当前在岗人员。完成标志是清单经团队负责人确认，没有遗漏角色，也没有两个角色职责高度重合。
第二步：收集现有职责来源
输入是岗位说明书、流程文档、项目分工记录和日常实际分工。动作是逐角色比对三类来源：制度上写的、流程要求的、实际在做的，把差异点单独标记。输出是每个角色的素材包和一份差异清单。完成标志是每个角色至少有一份可引用的来源，差异点已记录待评审时确认。
第三步：逐角色填写字段
输入是空白模板和第二步的素材包。动作是由角色本人或直属负责人按字段要求填写，重点把职责条目写成可判断完成的形式。输出是各角色的初稿。完成标志是必填字段无空缺，每条职责都能回答”做什么、对什么对象、产出什么”。
第四步：梳理角色间接口与重叠
输入是全部角色初稿。动作是逐个核对接口：A角色写明的下游，要在B角色的上游描述中出现；两条职责指向同一事项时，明确主责与配合。输出是接口对照结果和修订后的稿件。完成标志是所有接口双向对应，重叠条目已指定唯一主责角色。
第五步：评审定稿与发布
输入是修订稿和差异清单。动作是组织跨角色评审，逐条确认边界、权限和交付物，处理遗留分歧后定稿。输出是发布版职责说明书和版本记录。完成标志是评审参与方确认无异议，文档注明版本号、生效日期和维护人，并在团队内可查。
角色与分工：谁写、谁审、谁维护
职责说明书涉及每个角色的边界，由单人闭门完成容易失真。建议按下表分配编写、评审和维护责任，其中”A”为最终负责，”R”为具体执行，”C”为需征询，”I”为需知会。
| 参与方 | 编写阶段 | 评审阶段 | 发布后维护 |
|---|---|---|---|
| 文档负责人（主编） | A/R：搭模板、控进度、统稿 | R：组织评审、记录结论 | R：汇总变更、更新版本 |
| 各角色本人或直属负责人 | R：填写本角色字段 | C：确认本角色条目 | C：提出职责变更 |
| 团队负责人 | C：确认角色清单 | A：裁定边界与权限争议 | A：批准重大调整 |
| 上下游接口方 | I：提供交接要求 | C：核对接口是否双向对应 | I：知会接口变化 |
文档负责人负责结构和进度，不代替角色本人写职责；角色本人最清楚实际在做什么，由其填写能减少制度文本与实际分工的偏差。团队负责人在评审阶段对边界重叠和权限争议做最终裁定，避免讨论停在”大家都做一点”的状态。评审参与方至少包括全部角色代表和主要上下游接口方，评审要点集中在三处：职责是否重叠、权限是否与审批流程一致、接口是否双向承接。
发布后的维护责任归文档负责人，更新触发条件建议写明：角色新增或撤销、职责范围发生实质变化、审批权限调整、组织架构变动。触发后由相关角色提出变更，文档负责人汇总，团队负责人确认后更新版本号并知会全体成员。
示例：一个角色的职责条目怎么写
下面以一个”需求分析师”角色为例，演示从模糊描述改成可执行条目的过程。示例为演示情景，可按团队实际调整。
| 改写前（模糊） | 改写后（可执行） |
|---|---|
| 协助产品经理整理需求 | 负责收集业务方需求，输出需求清单，每条需求注明提出方、场景和优先级，提交产品经理确认 |
| 参与需求评审 | 负责组织需求评审会，会前2个工作日发出评审材料，会后1个工作日内输出评审结论和待办清单 |
| 跟进需求变更 | 负责受理需求变更申请，评估对已确认需求的影响范围，报产品经理审批后更新需求清单 |
改写规律有三条。第一，把”协助、参与、跟进”换成”负责、组织、受理、输出”这类能判断完成的动词，并明确动作对象。第二，每条职责落到一个具体交付物，如需求清单、评审结论、变更影响评估，交付物本身就是完成标志。第三，涉及决定权的动作写明权限归属，例如”报产品经理审批后”，权限与审批流程就自然对齐了。
接口描述同样要具体。该角色的上游写”接收业务方提出的需求”，下游写”向产品经理提交需求清单、向开发负责人移交已确认需求”，对应的产品经理和开发负责人角色中，上游一栏应出现”接收需求分析师提交的需求清单”，两边对得上，接口才算成立。
完成检查：定稿前逐项核对
发布前按下表逐项核对，全部通过再定稿。检查可由文档负责人自查，评审会上再由参与方抽查确认。
| 检查项 | 通过标准 |
|---|---|
| 角色覆盖完整且无重复 | 团队实际承担的工作都能对应到某个角色；不存在两个角色对同一事项都写”负责” |
| 职责条目可判断完成 | 每条都有明确动词、对象和产出，不出现”协助””参与”等无法验收的表述 |
| 权限描述与审批流程一致 | 文中写明的自主决定和上报事项，与现行审批流程逐条对得上 |
| 接口双向对应 | 每个角色的下游接收方，在其上游描述中都能找到对应条目 |
| 交付物有明确接收方 | 每项关键交付物都写明交给谁、何时交、什么状态算完成 |
| 版本与维护方式已写明 | 文档含版本号、生效日期、维护人和更新触发条件 |
检查中最常见的问题是接口单向声明：上游角色写了”向某角色移交材料”，对方文档里却没有接收条目，交接就容易落空。核对时以角色为轴逐条对照，比通读全文更容易发现问题。
定稿后的职责说明书需要在日常协作中真正被引用，否则容易停留在文档里。把角色与职责条目对应到协作工具中的工作项归属，可以让”谁负责、交给谁、什么算完成”在任务流转时直接可见。ONES 支持在工作项中设置负责人和状态流转，并可将角色职责说明作为团队文档沉淀，供成员在分配和交接任务时对照查阅；具体字段配置可按团队现有流程设置。
常见问题
团队规模很小，还需要为每个角色单独写一份职责说明吗？
小团队可以合并处理，但不宜省略职责边界。常见做法是一人承担多个角色时，在同一份文档里按角色分别列出条目，并注明当前由谁兼任，而不是把几条职责混成一段。这样人员调整时，只需改兼任关系，职责条目本身可以继续沿用。角色数量少时，字段也可以精简，例如把任职要求整列去掉，但使命、职责、权限、接口、交付物五项建议保留。
职责说明书和岗位说明书有什么区别，能不能直接复用？
两者可以互相引用，但侧重点不同。岗位说明书通常面向人事管理，偏重任职资格、汇报关系和职级；职责说明书面向日常协作，重点是这个角色在团队流程中承担什么、能决定什么、和谁交接、交出什么。已有岗位说明书时，任职要求一栏可以直接引用，不必重复展开；职责条目、决策权限和协作接口仍需按团队实际流程单独写清，因为同一岗位在不同团队中的分工往往不同。
评审时各方对某条职责归属争执不下，怎么处理？
先把争议收敛到具体事项上，请争执双方各自说明该事项的输入来源、处理动作和交付对象，通常能看出实际由谁在承接。若确实由两方共同参与，就拆成主责与配合两条：主责方对结果负责，配合方写明提供什么、何时提供。仍无法达成一致时，由团队负责人在评审会上裁定，并把裁定结论和理由记入评审记录，避免同一问题在下次修订时重新讨论。
职责说明书发布后，多久需要更新一次？
建议按触发条件更新，而不是固定周期。常见触发条件包括：新增或撤销角色、职责范围发生实质变化、审批权限调整、组织架构变动。日常可以由文档负责人每季度做一次轻量核对，确认在岗人员与角色对应关系是否仍然准确。每次更新都要改版本号、注明生效日期，并知会全部角色和主要接口方，否则容易出现部分成员仍按旧版执行的情况。
职责说明书定稿后，怎么让成员在日常工作中真正用起来？
关键在于让文档里的角色和条目与实际任务流转对应起来。一种做法是把角色与职责条目对应到协作工具中的工作项归属，让“谁负责、交给谁、什么算完成”在分配和交接任务时直接可见。ONES 支持在工作项中设置负责人和状态流转，也可将职责说明作为团队文档沉淀，供成员对照查阅；具体字段配置按团队现有流程设置。此外，新成员入职和角色调整时，把职责说明书作为必读材料，能提高它被引用的频率。
