团队职责说明书要写清楚五件事：角色、职责、交付物、协作接口和决策权限。本文给出一份虚构产品团队的完整填写示例，包含六个角色和一张可直接参照的表格，并逐项解释字段写法、迁移到其他团队的改写步骤，以及这份示例不覆盖的管理边界。
要点总览（TL;DR）
- 团队职责说明书的核心字段是角色、职责、交付物、协作接口和决策权限，本文给出一份六个角色的完整填写示例。
- 交付物要写成可验收的对象，协作接口要写清输入来源、输出去向和交接时点，决策权限区分建议权、审核权与决定权。
- 迁移到自己团队时按业务对象组织职责，用交付物串联交接，再按组织层级调整权限写法。
- 示例为虚构情景，只覆盖角色职责；逐任务指派归任务分配，人员技能配置归资源管理。
示例目标：这份职责说明书要解决什么问题
本文的示例设定为一个虚构的在线教育产品团队，共六个角色：产品负责人、产品经理、交互设计师、前端工程师、后端工程师、测试工程师。团队按两周一个迭代推进功能开发，角色之间存在固定的上下游交接关系：产品经理输出需求文档，交互设计师输出交互稿，前后端工程师分别交付可联调的功能模块，测试工程师完成验收测试，产品负责人对范围与优先级做最终决定。这个设定只用于演示填写方法，不代表任何真实组织。
这份说明书要解决三类常见问题。第一类是职责重叠：两个角色都认为自己负责某件事，或者都认为对方负责，结果出现重复劳动或空白地带。第二类是交接断点：上游以为已经交付，下游以为还没收到，工作卡在角色之间。第三类是决策无人拍板：讨论很久没有结论，或者结论出来后没人确认是否有效。职责说明书把这三类问题的答案提前写进表格，减少每次靠临时沟通确认的成本。
示例的适用范围是：团队角色相对稳定、协作关系可以提前约定的场景，例如产品研发团队、项目交付团队、运营小组。不适用范围包括：临时组建、角色每天变化的突击小组；以及需要逐任务指派负责人的场景，那属于任务分配，不在职责说明书的范围内。
示例背景卡
| 项目 | 示例设定 |
|---|---|
| 团队性质 | 虚构的在线教育产品研发团队 |
| 角色数量 | 6个：产品负责人、产品经理、交互设计师、前端工程师、后端工程师、测试工程师 |
| 协作节奏 | 两周一个迭代，迭代内完成需求评审、设计、开发、测试、发布 |
| 要解决的问题 | 职责重叠、交接断点、决策无人拍板 |
| 不覆盖的内容 | 单任务负责人指派、人员技能盘点与岗位匹配、绩效考核指标 |
完整示例：一份填好的团队职责说明书
下面这份表格是示例的核心交付物。每个角色占一行，字段包括角色定位、核心职责、关键交付物、交付对象、协作接口与交接时点、决策权限。填写时以“这个角色向谁交付什么、在什么时点交接、哪些事由他拍板”为主线，避免写成岗位描述的泛泛罗列。
| 角色 | 角色定位 | 核心职责 | 关键交付物 | 交付对象 | 协作接口与交接时点 | 决策权限 |
|---|---|---|---|---|---|---|
| 产品负责人 | 对产品方向和迭代范围负最终责任 | 确定迭代目标与优先级；审批需求范围变更；主持迭代评审 | 迭代目标说明、范围变更决定 | 产品经理、全体研发角色 | 迭代启动前给出目标；范围变更请求在24小时内答复 | 对范围与优先级有决定权；对技术方案有建议权 |
| 产品经理 | 把业务需求转化为可开发的需求说明 | 编写需求文档；组织需求评审；跟踪需求实现情况 | 需求文档（含验收标准）、需求评审记录 | 交互设计师、前后端工程师、测试工程师 | 迭代第1个工作日交付需求文档；评审通过后移交设计 | 对需求细节有决定权；范围变更需报产品负责人审核 |
| 交互设计师 | 把需求转化为可实现的界面与交互方案 | 输出交互稿；维护设计规范；配合开发澄清设计问题 | 交互稿（含状态说明）、设计规范更新记录 | 前端工程师、后端工程师 | 需求评审通过后2个工作日内交付交互稿；开发期间答疑 | 对交互方案有决定权；涉及需求理解的改动需产品经理确认 |
| 前端工程师 | 实现用户可见的界面与交互 | 按交互稿开发前端功能；联调接口；修复前端缺陷 | 可运行的前端功能模块、联调记录 | 测试工程师、后端工程师 | 交互稿确认后开始开发；提测前完成自测并提交联调记录 | 对前端技术实现有决定权；接口字段变更需与后端工程师共同确认 |
| 后端工程师 | 实现服务端逻辑与数据接口 | 设计并开发接口；维护数据模型；配合前端联调 | 接口文档、可联调的服务端模块 | 前端工程师、测试工程师 | 需求评审后输出接口草案；提测前冻结接口字段 | 对服务端技术方案有决定权；接口冻结后的变更需测试工程师知会 |
| 测试工程师 | 验证功能是否满足验收标准 | 编写测试用例；执行验收测试；输出测试报告 | 测试用例、测试报告（含缺陷清单） | 产品经理、产品负责人 | 提测后1个工作日内给出首轮测试结论；发布前输出测试报告 | 对是否达到发布标准有审核权；发布决定由产品负责人做出 |
这张表的关键在于每一行都能回答三个问题：这个角色产出什么、交给谁、在什么时点交。例如“交互稿在需求评审通过后2个工作日内交付给前端工程师”，把交付物、交付对象和交接时点写在同一格，交接断点就有了明确的判断依据。决策权限一列则区分了谁拍板、谁审核、谁只能提建议，避免讨论结束后无人确认。
逐项解释：每个字段为什么这样填
表格看起来简单，填写时的判断才是难点。下面按字段说明示例中的写法理由，并给出正例与需要避免的写法。
角色定位与职责条目的粒度控制
角色定位用一句话说明这个角色对什么结果负责，例如“对产品方向和迭代范围负最终责任”。它回答的是“为什么需要这个角色”，而不是“这个角色做哪些事”。核心职责则控制在三到五条，每条对应一类可重复发生的工作，例如“编写需求文档”“组织需求评审”“跟踪需求实现情况”。条目太少会漏掉关键工作，太多则退化成流水账，读者记不住也无法核对。
| 字段 | 正例 | 需要避免的写法 |
|---|---|---|
| 角色定位 | 把业务需求转化为可开发的需求说明 | 负责产品相关工作，积极配合团队 |
| 核心职责 | 组织需求评审，评审通过后移交设计 | 参与各种会议，完成领导交办的任务 |
交付物写成可验收对象而非动作描述
交付物要写成能被对方检查的东西，例如“需求文档（含验收标准）”“测试报告（含缺陷清单）”。动作描述如“做好需求沟通”“完成测试工作”无法判断是否交付完成，交接时容易各说各话。判断标准很简单：交付物能不能被打开、被评审、被签字确认。能，就是合格的交付物写法。
协作接口写清输入来源与输出去向
协作接口一列要同时写两件事：这个角色从谁那里接收输入，向谁输出结果，以及交接发生在什么时点。示例中“提测前完成自测并提交联调记录”就是一个完整的接口描述：时点是提测前，动作是提交联调记录，去向是测试工程师。只写“与测试配合”则缺少时点和对象，交接断点仍然存在。
决策权限区分建议权、审核权与决定权
权限字段建议至少区分三档：建议权表示可以提出意见但不影响最终结果；审核权表示可以否决或要求修改；决定权表示最终拍板。示例中产品负责人对范围有决定权，测试工程师对是否达到发布标准有审核权，发布决定仍由产品负责人做出。三档写清楚，升级路径自然出现：有分歧时找持有决定权的角色，而不是反复开会。
职责条目数量与颗粒度的取舍
职责条目的合适数量取决于团队规模和协作复杂度。六人左右的团队，每个角色三到五条足够覆盖主要工作；跨部门协作多的团队可以适当增加，但建议把同一类工作合并成一条，避免把操作步骤写进职责。颗粒度以“能被一个角色独立承担、能被他人观察和核对”为准。
可迁移规律：换一个团队怎么改这份示例
这份示例的价值不在具体内容，而在填写结构。迁移到自己团队时，按下面的步骤改写，通常比从空白表格开始更快。
- 列出团队的业务对象，例如需求、设计稿、代码模块、测试报告、运营活动、客户工单，按业务对象而不是部门名称组织职责。部门名称会随组织调整变化，业务对象的流转关系相对稳定。
- 为每个业务对象确定“谁产出、谁接收、何时交接”，把这三项填进交付物和协作接口两列。交接时点尽量写成可判断的条件，例如“评审通过后2个工作日内”，而不是“尽快”。
- 确定每个角色的权限档位。先标出哪些事必须有人拍板，再标出哪些事需要审核，其余默认为建议权。权限随组织层级调整：层级越多，决定权越需要上收或明确授权。
- 检查职责条目之间是否有重叠或空白。两个角色写同一条职责时，明确谁是主责、谁是配合；某类工作没有任何角色认领时，补一条职责或明确由谁兼管。
- 约定维护节奏。建议在组织调整、角色增减、协作流程变化时更新说明书，并至少每半年复核一次，避免文档与实际协作脱节。
职责说明书定稿后，需要在日常协作中持续被引用。ONES 可以承载角色、交付物与评审状态的管理：把每个角色的交付物对应为工作项或文档，交接时点对应为状态流转和评审节点，权限约定则体现在评审与审批环节。这样说明书不只是存放在某处的表格，而是与迭代过程同步更新的一份协作依据。具体承载方式可结合团队现有的工作项类型和文档结构设计。
适用边界：哪些情况不适合照搬这份示例
这份示例是虚构情景下的填写示范，不代表任何真实组织的职责安排，也不附带经过验证的管理成效。照搬前需要确认几件事。
单任务负责人指派属于任务分配范畴。某个具体需求由谁跟进、某个缺陷由谁修复，这类逐任务的指派在任务管理或项目管理中完成，不需要写进职责说明书。职责说明书回答的是“这类工作通常由哪个角色承担”，而不是“这件事现在由谁做”。
人员技能配置与匹配属于资源管理范畴。某个角色由谁担任、成员技能是否匹配岗位要求，涉及人员盘点与培养，不在职责说明书的字段范围内。说明书只描述角色，不描述具体的人。
团队规模和行业差异会影响字段取舍。人数很少的团队可以合并角色，一张表覆盖全部成员；跨部门协作多的团队可能需要增加“升级路径”或“争议处理”字段。行业监管要求不同，交付物的验收标准也会不同，填写时应以本团队的实际交付物为准。
| 文档 | 回答的问题 | 与职责说明书的分工 |
|---|---|---|
| 团队职责说明书 | 每个角色负责什么、交付什么、谁拍板 | 本文示例的范围 |
| 任务分配表 | 某件具体工作由谁负责、何时完成 | 逐任务指派，不在本文展开 |
| 人员技能矩阵 | 成员具备哪些技能、如何匹配岗位 | 资源管理范畴，不在本文展开 |
| 绩效考核方案 | 如何评价角色和个人的工作结果 | 指标设计范畴，不在本文展开 |
把职责说明书放在合适的位置，它就能成为团队协作的基础文档：向上衔接组织设计，向下支撑任务分配，横向与技能管理和绩效管理各司其职。示例提供的是填写结构，具体内容仍需结合本团队的业务对象和协作关系逐项确认。
常见问题
团队职责说明书和岗位说明书有什么区别？
岗位说明书通常面向人事管理，描述岗位的任职要求、汇报关系和能力条件；团队职责说明书面向协作，重点写清角色产出什么、交给谁、在什么时点交接、哪些事由谁拍板。两者可以并存：岗位说明书回答“这个岗位需要什么样的人”，职责说明书回答“这个角色在协作中承担什么”。如果团队规模小、角色由成员兼任，职责说明书往往比岗位说明书更实用。
团队只有三四个人，还需要写职责说明书吗？
需要，但可以简化。人数少的团队可以合并角色，一张表覆盖全部成员，字段保留角色定位、核心职责、交付物和决策权限四项即可。协作接口在人数少时可以写得粗一些，例如只标注交接发生在哪个阶段。关键是把容易产生分歧的地方提前写下来，例如谁对需求范围拍板、谁负责最终验收，避免每次靠口头确认。
职责说明书里写了决策权限，实际执行时还是没人拍板怎么办？
先检查权限字段是否写到了具体事项。只写“有决定权”不够，要写清对什么有决定权，例如“对迭代范围有决定权”。其次检查是否存在两个角色对同一件事都写了决定权，这种情况需要明确主责。最后确认升级路径：出现分歧时找持有决定权的角色，而不是继续开会讨论。如果权限约定与实际情况长期不符，说明说明书需要更新，而不是执行环节出了问题。
职责说明书多久更新一次比较合适？
建议在组织调整、角色增减、协作流程变化时及时更新，并至少每半年复核一次。复核时重点看三处：是否有新出现的工作没有角色认领，是否有两个角色写着重叠的职责，交接时点是否还符合当前节奏。日常发现某条职责与实际做法不一致时，先记录，集中到复核时统一修改，避免频繁改动导致文档失去权威性。
跨部门协作多的团队，字段需要增加什么？
可以在示例基础上增加两个字段：一是升级路径，写清跨部门分歧由谁协调、按什么顺序升级；二是争议处理，写清交付物验收不通过时的处理方式。跨部门场景下，交付物的验收标准建议写得更具体，例如附上检查项或模板，减少双方对“是否交付完成”的理解差异。字段增加后表格会变宽，可以拆成主表和附表分别维护。
