团队职责说明书用一张表把角色、职责边界、决策权、协作接口和替补安排写清楚，适合在团队组建、跨部门协作或岗位调整时统一口径。本文提供一份可直接复制的空白主表、逐字段填写说明、必填与选填的取舍建议，并用一个演示团队完整填写一遍，最后说明职责变化后如何调整和发布。
要点总览（TL;DR）
- 团队职责说明书用一张主表写清角色名称、角色目标、主要职责、不负责事项、关键交付物、决策权限和协作接口，适合在团队组建、跨部门协作或岗位调整时统一口径。
- 角色名称、角色目标、主要职责、关键交付物为必填；不负责事项、决策权限、下游交接对象建议必填；验收口径、升级路径、上游输入、协作角色、替补角色、生效范围按场景补填。
- 每条职责对应一个可观察的交付物，并成对写验收口径；边界写“不做什么”，接口写“交什么、何时交、达到什么标准”，两者配合才能减少推诿。
- 职责变化按小版本发布处理：有人发起、有人评审、有生效日期、有版本记录；人员变动、同类交接争议反复出现或新增跨部门项目时立即复核。
- 说明书定稿后需要在日常协作中被持续引用，可把角色、职责和交接标准对应到协作工具中的成员分组、工作项类型和交接状态。
可复制空白模板：团队职责说明书主表
下面这张表是职责说明书的主体。建议每个角色占一行，先填完所有角色，再回头补接口和替补。表格可以直接复制到文档或表格工具中使用，列名保持不变，便于不同团队之间对照。
主表：角色职责明细
| 角色名称 | 角色目标 | 主要职责 | 不负责事项 | 关键交付物 | 验收口径 | 决策权限 | 升级路径 | 上游输入 | 下游交接对象 | 协作角色 | 替补角色 | 生效范围 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
角色清单汇总区
主表填完后，用一张简表核对角色是否齐全、是否有人承担多个角色。这一区域帮助团队负责人快速看出角色覆盖情况。
| 序号 | 角色名称 | 当前承担人 | 是否兼任其他角色 | 备注 |
|---|---|---|---|---|
| 1 | ||||
| 2 | ||||
| 3 |
角色接口与交接区
接口区记录两个角色之间的输入输出关系，适合放在主表之后单独维护。当协作出现争议时，先查这张表确认交接内容和时点。
| 接口编号 | 上游角色 | 交接内容 | 交接时点 | 下游角色 | 接收标准 | 争议处理方式 |
|---|---|---|---|---|---|---|
| I-01 | ||||||
| I-02 |
版本与维护记录区
| 版本号 | 修订日期 | 修订内容摘要 | 发起人 | 评审人 | 生效日期 |
|---|---|---|---|---|---|
| V1.0 | |||||
字段说明：每个列该填什么
同一列在不同团队里容易被填成不同含义，下面逐项说明填写口径。填写时以“读者能否据此判断某件事该找谁”为标准，写不清楚就说明口径还没统一。
角色名称与角色目标
角色名称写团队内部通用的称呼，例如“产品负责人”“交付协调人”，避免使用只有个别人理解的缩写。角色目标用一句话说明这个角色为什么存在，指向团队目标中的某一部分，例如“确保需求在进入开发前完成优先级确认”。角色目标不写具体任务，任务放到主要职责里。
主要职责与不负责事项
主要职责逐条写，每条以动词开头，描述一个持续承担的工作，例如“维护需求优先级列表并每周更新”。一条职责对应一个可观察的结果，避免把“配合”“支持”单独作为一条职责。不负责事项用来划清边界，写那些容易被误认为属于该角色、实际由他人承担的工作，例如“不负责开发排期，由技术负责人确认”。
关键交付物与验收口径
关键交付物是职责完成后留下的具体产物，例如需求清单、评审记录、上线检查表。验收口径说明交付物达到什么状态算完成，例如“需求清单包含优先级、负责人和预计上线时间三项信息”。交付物与验收口径成对填写，只写交付物不写口径，交接时仍会产生争议。
决策权限与升级路径
决策权限写该角色可以独立决定的事项，以及需要他人确认的事项，例如“可独立调整两周内的需求顺序，涉及范围变更需团队负责人确认”。升级路径写当权限不足或出现分歧时找谁，写清角色而非只写人名，人员变动时不必改表。
上游输入、下游交接与协作角色
上游输入写该角色开始工作前需要拿到什么、从谁那里拿。下游交接对象写该角色的产出交给谁、以什么形式交。协作角色写需要频繁配合但不构成直接交接的角色。这三列共同构成角色在团队中的位置，填写时尽量使用角色名称，保持与主表一致。
替补角色与生效范围
替补角色写主责人缺席时由谁临时承担，并注明替补的权限范围，例如“可代为接收需求，不代为调整优先级”。生效范围说明该职责说明适用于哪个团队、哪个项目或哪个时间段，跨团队共用一份表时尤其需要写清楚。
必填与选填：哪些字段不能空
字段齐全的版本适合跨部门协作较多的团队，小团队可以先填最低可用版本。判断标准是：缺少该字段后，是否会出现“不知道找谁”或“交接后返工”的情况，会则必填。
| 字段 | 建议 | 空缺后果 | 适用场景 |
|---|---|---|---|
| 角色名称 | 必填 | 无法定位责任人 | 所有团队 |
| 角色目标 | 必填 | 职责容易越写越多，边界失控 | 所有团队 |
| 主要职责 | 必填 | 工作无人认领或重复承担 | 所有团队 |
| 关键交付物 | 必填 | 职责停留在口头，无法检查 | 所有团队 |
| 不负责事项 | 建议必填 | 边界模糊，争议反复出现 | 角色交叉多的团队 |
| 验收口径 | 选填 | 交接标准靠默契 | 交付物需要多方确认时补填 |
| 决策权限 | 建议必填 | 小事层层请示或越权决定 | 有审批或排期决策的团队 |
| 升级路径 | 选填 | 分歧时找不到裁决人 | 跨部门协作场景补填 |
| 上游输入 | 选填 | 等待输入时无人推动 | 存在前后道工序时补填 |
| 下游交接对象 | 建议必填 | 产出无人接收或交接遗漏 | 有明确交付链条的团队 |
| 协作角色 | 选填 | 配合关系靠个人记忆 | 角色数量超过五个时补填 |
| 替补角色 | 选填 | 人员请假时工作停摆 | 关键角色或单人角色补填 |
| 生效范围 | 选填 | 多团队共用时口径混淆 | 跨团队或跨项目使用时补填 |
小团队精简版
五人以内的团队可以只保留角色名称、角色目标、主要职责、关键交付物、不负责事项五列，接口区合并为一张交接清单。精简版仍要保证每条职责对应一个交付物，否则表格会退化成岗位描述。
跨部门协作场景的补充字段
当职责说明书需要给其他部门看时，补上决策权限、升级路径、上游输入和下游交接对象。跨部门读者最关心的是“什么事找你、你什么时候给我、卡住了找谁”，这四列直接回答这些问题。
填写示例：一个产品团队的职责说明书
以下为演示情景，用于说明字段如何落地，不代表真实客户案例。假设一个八人产品团队，包含产品负责人、需求分析师、技术负责人、开发工程师、测试工程师和交付协调人六个角色，团队负责一条内部业务系统的持续迭代。
示例：产品负责人一行
| 字段 | 填写内容 |
|---|---|
| 角色名称 | 产品负责人 |
| 角色目标 | 确保团队每个迭代处理的需求与业务目标一致，并让范围变更可控 |
| 主要职责 | 1. 维护需求优先级列表，每两周更新一次；2. 组织需求评审，确认进入开发的需求范围；3. 对范围变更做出决定并记录原因 |
| 不负责事项 | 不负责开发排期与人力分配，由技术负责人确认；不负责测试用例设计 |
| 关键交付物 | 需求优先级列表、需求评审记录、范围变更记录 |
| 验收口径 | 需求优先级列表包含优先级、负责人、预计上线时间三项信息；评审记录包含结论和待办 |
| 决策权限 | 可独立调整两周内的需求顺序；涉及上线时间变化需与交付协调人确认 |
| 升级路径 | 范围争议提交团队负责人裁决 |
| 上游输入 | 业务方需求说明、上一迭代复盘结论 |
| 下游交接对象 | 需求分析师、技术负责人 |
| 协作角色 | 交付协调人、测试工程师 |
| 替补角色 | 需求分析师（可代为接收需求，不代为调整优先级） |
| 生效范围 | 本产品团队，2024 年度迭代 |
示例：接口区两行
| 接口编号 | 上游角色 | 交接内容 | 交接时点 | 下游角色 | 接收标准 | 争议处理方式 |
|---|---|---|---|---|---|---|
| I-01 | 产品负责人 | 已确认优先级的需求条目 | 每迭代开始前两个工作日 | 需求分析师 | 每条需求有优先级、背景和验收要点 | 信息不全退回补充，优先级争议提交团队负责人 |
| I-02 | 开发工程师 | 可测试的构建版本与变更说明 | 提测当日 | 测试工程师 | 变更说明列明影响范围，构建版本可部署 | 影响范围不清时由技术负责人确认后再提测 |
职责边界与接口的写法示范
上例中，“不负责开发排期”与接口 I-01 相互配合：前者说明产品负责人不决定排期，后者说明需求以什么标准交给需求分析师。边界写“不做什么”，接口写“交什么、何时交、达到什么标准”，两者合起来才能减少推诿。常见错误是把“配合技术负责人排期”写成一条主要职责，这会让责任重新变得模糊，正确做法是写清产品负责人提供优先级、技术负责人据此排期。
常见填写错误对照
| 错误写法 | 问题 | 修改方向 |
|---|---|---|
| 职责写“负责需求相关工作” | 范围过大，无法判断是否完成 | 拆成具体动作并对应交付物 |
| 只写交付物，不写验收口径 | 交接时对完成标准理解不一 | 补充交付物需包含的信息项 |
| 决策权限写“重要事项上报” | “重要”没有判断标准 | 写明可独立决定的事项和需确认的事项 |
| 替补角色只写人名 | 人员变动后表格失效 | 写角色名称，并注明替补权限范围 |
调整与维护方法：让说明书随团队变化更新
职责说明书在团队稳定时容易写好，难的是变化之后仍保持准确。维护的关键是把变更当作一次小版本发布：有人发起、有人评审、有生效日期、有记录可查。
新增或合并角色时的调整步骤
- 确认变化来源：新业务线、人员减少或职责重叠，写清触发原因。
- 在角色清单汇总区新增或合并角色，先调整角色目标，再改主要职责。
- 检查受影响角色的不负责事项和接口区，删除已失效的交接，补充新的交接内容和时点。
- 由团队负责人和相关角色共同评审，确认没有职责空档或重复承担。
- 更新版本号与生效日期，通知所有协作方。
职责变更的发起、评审与发布
任何角色都可以发起变更，发起时在维护记录区写明改哪一行、为什么改。评审范围以受影响角色为限，涉及跨部门接口时邀请对方确认。发布时保留旧版本，新版本标注生效日期，避免同一时间出现两个口径。
版本记录与生效日期
版本号建议按“主版本.次版本”记录：角色增删或职责范围大幅调整记主版本，措辞修正和接口微调记次版本。生效日期写具体日期，不写“即日起”，便于回溯某段时间内实际执行的是哪一版。
定期复核的触发条件
除固定周期复核外，出现以下情况应立即复核：团队人员变动超过一定比例、连续出现两次以上同类交接争议、新增跨部门协作项目、季度目标调整。复核时重点检查不负责事项和接口区，这两处最容易滞后于实际工作。
职责说明书定稿后，需要在日常协作中持续被引用才有价值。团队可以把角色名称、主要职责和交接标准对应到协作工具中的成员分组、工作项类型和交接状态，让每次任务流转都能看到上游输入和下游接收人。ONES 可用于承载团队与工作项管理，具体以角色、工作项和交接状态的配置方式，建议结合实际版本在试用中核验。无论使用哪种工具，维护节奏与版本记录保持一致，说明书才能跟上团队变化。
常见问题
团队人数很少，还需要单独维护接口区和替补角色吗？
五人以内的团队可以先用精简版：保留角色名称、角色目标、主要职责、关键交付物、不负责事项五列，接口区合并成一张交接清单。替补角色在关键角色只有一人承担时补填，写明替补人可以代做什么、不能代做什么。团队人数增加或出现跨部门协作后，再把决策权限、升级路径和完整接口区补上。
职责说明书写好后，和日常任务分派是什么关系？
职责说明书回答“这类工作长期由谁负责”，任务分派回答“这一件事这次由谁做”。两者可以并存：说明书为任务分派提供角色依据，具体任务的负责人、截止时间和状态仍在任务或工作项中记录。若某个任务反复落到说明书之外的人身上，说明职责边界需要复核，而不是继续靠临时指派维持。
跨部门共用一份职责说明书时，最容易出问题的地方在哪里？
常见问题集中在三处：生效范围没写清，不同团队按各自理解执行；升级路径只写人名，人员变动后无人裁决；接口区只写交接内容，没写交接时点和接收标准。跨部门使用时建议补上决策权限、升级路径、上游输入和下游交接对象，并在接口区写明争议处理方式，让对接方知道卡住时找谁。
职责变更由谁发起，评审要拉哪些人？
任何角色都可以发起变更，发起时在维护记录区写明改哪一行、为什么改。评审范围以受影响角色为限：只涉及团队内部时由团队负责人和相关角色确认；涉及跨部门接口时邀请对方一起确认交接内容和时点。发布时保留旧版本并标注生效日期，避免同一时间存在两个口径。
把职责说明书放进协作工具时，需要先确认什么？
先确认工具能否承载三类信息：角色与成员的分组关系、职责对应的工作项类型、交接环节的状态流转。不同产品与版本的配置方式差异较大，建议在试用中按本团队的一张主表和一条接口实际配置一遍，确认字段、权限和通知能满足日常引用，再决定是否全面推行。ONES 可用于承载团队与工作项管理，具体配置方式以实际版本为准。
