标准任务清单要长期可用，维护职责需要落到具体角色和动作上。可以把职责拆成四类：清单负责人对内容正确与版本负责，执行角色反馈偏差与例外，审核角色把关新增与变更，平台管理员负责清单在工具中的落地与权限。再配一条“提出—评审—发布—复盘”的变更流程，每步写明输入、动作、输出和完成标志，分工才不会停留在口头。清单在工具中的版本留存与权限配置，可借助 ONES 的文档与权限能力承载。
要点总览（TL;DR）
- 维护职责拆成四类角色：清单负责人管内容与版本，执行角色反馈偏差与例外，审核角色把关新增与变更，平台管理员负责工具落地与权限。
- 变更按“提出—评审—发布—复盘”四步走，每步写明输入、动作、输出和完成标志，变更才不会靠临时沟通推进。
- 清单条目分必做项与可选项，必做项写明执行角色、完成标准和可核验产出；周期任务采用模板加实例的方式复用，例外记录在实例上。
- 小团队可一人兼多角色，但提出与批准要分开，并在清单说明中写清谁在什么情况下行使哪项决策权。
- 用记录验收分工：变更评审痕迹、版本与实例对应、发布通知、失效条目清理，缺记录时先补记录再谈调整。
维护职责先按四类角色划分
维护职责划分的核心是让每类角色知道自己对什么负责、能决定什么、不承担什么。四类角色覆盖了清单从内容到落地的完整链条：清单负责人管内容，执行角色管反馈，审核角色管把关，平台管理员管承载。角色名称可以按团队习惯调整，职责边界建议保持清晰。
| 角色 | 主要职责 | 决策权 | 不承担的部分 |
|---|---|---|---|
| 清单负责人 | 维护清单条目内容、组织评审、发布新版本、记录变更原因 | 决定条目取舍与版本号，确认发布时点 | 不代替执行角色判断现场例外，不负责工具权限配置 |
| 执行角色 | 按清单执行周期任务，反馈条目偏差、遗漏和不适用的场景 | 在授权范围内判断本次执行是否适用某条目，并记录例外 | 不直接修改已发布清单，不决定条目增删 |
| 审核角色 | 评审新增条目、删除条目和重大修改，检查与现有流程的一致性 | 对变更是否通过拥有否决权 | 不承担日常条目文字维护，不负责发布通知 |
| 平台管理员 | 把清单配置到工具中，管理查看、编辑权限，维护模板与实例的对应关系 | 决定工具中的权限分配与配置方式 | 不判断业务条目是否正确，不替代清单负责人做内容决策 |
小团队不必凑齐四个人。常见合并方式是由团队负责人兼任清单负责人与审核角色，但发布前仍需保留一次独立检查，避免自己提出、自己批准；平台管理员可由熟悉工具的成员兼任；执行角色本身由全体执行成员共同承担。合并角色时，要在清单说明中写清“谁在什么情况下行使哪项决策权”，防止职责随人员变动而消失。
从提出到发布的清单变更流程
静态分工需要流程来驱动。建议把清单变更固定为四个阶段，每个阶段都有明确输入、动作、输出和完成标志，避免变更靠临时沟通推进。
| 阶段 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 提出 | 执行中的偏差记录、例外反馈、流程调整通知、复盘发现的问题 | 提出人填写变更说明：涉及条目、变更原因、影响范围、期望生效时间 | 一条待评审的变更申请 | 变更申请包含原因和影响范围，已提交给清单负责人 |
| 评审 | 变更申请、现行清单版本、相关流程文件 | 审核角色检查条目是否必要、表述是否可执行、是否与现有条目重复或冲突；清单负责人补充背景 | 评审结论：通过、修改后通过或驳回 | 评审结论有记录，驳回或修改意见写明理由 |
| 发布 | 评审通过的变更内容 | 清单负责人更新条目并升版本号，平台管理员同步工具中的清单或模板，通知执行角色 | 新版本清单与发布通知 | 执行角色收到通知，工具中的清单与发布版本一致 |
| 复盘 | 一段时间内的执行记录、例外反馈、变更申请 | 按固定周期检查条目使用情况，清理长期未触发或已失效的条目，评估变更频率是否过高 | 复盘记录与下一轮清理清单 | 失效条目已处理，复盘结论有负责人确认 |
触发条件要写清楚，否则变更会变成随时提、随时改。常见触发包括：同一例外在一个周期内出现多次、业务流程或系统发生调整、审核发现条目表述导致执行歧义、复盘确认某条目长期不适用。通知范围按影响面确定，涉及多个团队共用的清单时通知到各团队执行角色，仅影响单个团队的调整在团队内通知即可。
清单内容与复用方式的确定规则
职责要落地，还需要先回答清单里放什么、周期任务怎么复用。内容分级不清晰，清单负责人会不断被“这条要不要加”的问题消耗，执行角色也难以判断哪些条目可以跳过。
必做项与可选项的划分依据建议从三个角度判断：一是法规、合同或内部制度明确要求的动作，列为必做项；二是缺失后会导致返工、事故或下游阻塞的动作，列为必做项；三是提升质量的辅助检查、经验性核对，列为可选项。每条必做项应写明执行角色、完成标准和可核验的产出，可选项则注明适用条件，例如“仅在新版本上线周期执行”。
周期任务复用清单时，采用“模板加实例”的方式：清单本身作为模板维护，每个周期生成执行实例，实例继承当期的条目版本，执行中的例外和偏差记录在实例上，不回写模板。这样清单负责人维护的是模板，执行角色反馈的是实例，两者通过版本号对应，追溯时能看清某次执行用的是哪一版清单。
清单与项目模板、自动规则的边界要提前说明。项目模板解决的是项目如何立项、阶段如何划分、交付物如何组织，属于项目计划管理范畴；自动规则解决的是跨对象的状态流转与通知触发，属于研发流程自动化范畴。标准任务清单只负责“一项重复性工作包含哪些检查动作、由谁完成、达到什么标准”。清单可以引用项目模板中的阶段名称，也可以由自动规则在周期开始时创建执行实例，但清单条目的增删仍由清单负责人和审核角色决定，不交给规则配置顺带处理。
在工具承载上，ONES Wiki 提供页面模板库，可一键创建制式化文档模板，适合存放清单说明、条目定义和变更记录；其版本记录支持查看与回滚页面历史，权限控制支持为不同角色配置读写权限。清单模板与执行实例的对应关系，可借助文档关联项目任务的方式建立，具体配置范围以实际产品为准。
一个周期任务的职责分工示例
以月度运营检查清单为例，假设团队每月需要核对数据报表、渠道投放状态、库存预警和客户反馈处理情况。以下为演示情景，用于说明角色与流程如何配合。
角色分配：运营负责人担任清单负责人，负责条目内容和版本；运营专员为执行角色，按月执行并记录例外；运营负责人与质量接口人共同担任审核角色，新增或删除条目需两人中至少一人同意；熟悉工具的项目助理担任平台管理员，负责清单页面权限和每月实例创建。
一次条目变更的走查：执行角色在连续两个月的检查中发现“库存预警”条目只覆盖了线上渠道，线下门店缺货未被检查。执行角色提交变更申请，写明涉及条目、遗漏场景和影响范围。审核角色评审后认为应拆成“线上库存预警”和“线下门店缺货检查”两条，并补充完成标准。清单负责人更新条目、升版本号并记录变更原因，平台管理员同步更新工具中的清单页面，通知全体执行角色。下个月执行实例使用新版本，旧实例保留原版本记录。
例外情况的处理：某月因系统升级，数据报表无法按原定时间导出，执行角色在实例中记录“本期跳过，原因：系统升级，补做时间：次月第一周”，并通知清单负责人。清单负责人判断属于一次性例外，不修改清单；若同类例外再次出现，则按变更流程评估是否调整条目时间要求。例外记录保留在实例中，复盘时作为判断条目合理性的依据。
职责划分的完成检查
分工是否真正落地，可以用以下清单逐项核对。每项都应有可查证的记录，而不是仅凭印象确认。
- 四类角色均有明确负责人，姓名或岗位写入清单说明，人员变动时有交接记录。
- 每条变更申请都有提出人、评审结论和评审人记录，驳回意见写明理由。
- 清单版本号与执行实例对应，能查到某次周期任务使用的是哪一版清单。
- 发布后有通知记录，执行角色确认收到新版本。
- 复盘按固定周期进行，失效条目有清理记录和处理结论。
- 例外情况记录在实例中，重复出现的例外已进入变更流程评估。
- 平台管理员维护的权限配置与角色分工一致，执行角色具备查看和反馈权限，修改权限限于清单负责人。
- 清单与项目模板、自动规则的边界在团队内已说明，条目增删不通过规则配置绕过评审。
核对时若发现某项缺少记录，优先补记录而不是重新分工。记录本身会暴露职责空档：例如变更申请长期没有评审结论，说明审核角色未实际行使决策权；实例版本与清单版本对不上，说明平台管理员的同步动作没有完成标志。按这些信号调整，职责划分才能随清单一起持续运转。
常见问题
小团队人手有限，四类角色必须分开由不同人担任吗？
不必。常见做法是团队负责人兼任清单负责人与审核角色，平台管理员由熟悉工具的成员兼任，执行角色由全体执行成员共同承担。合并时守住一条底线：提出变更的人与批准变更的人分开，发布前保留一次独立检查。同时把“谁在什么情况下行使哪项决策权”写进清单说明，人员变动时做交接记录，职责才不会随人走失。
执行过程中发现清单条目不适用的场景，应该改清单还是记录例外？
先判断是一次性还是重复出现。一次性情况（如系统升级导致本期无法按原时间导出）记录在当期执行实例上，写明跳过原因和补做时间，通知清单负责人即可，不改清单。同类例外在一个周期内多次出现，或业务流程、系统发生调整，就转入变更流程评估条目是否要修改。例外记录保留在实例中，复盘时作为判断条目合理性的依据。
清单模板和项目模板、自动规则之间怎么划边界，避免职责重叠？
三者回答的问题不同：标准任务清单负责一项重复性工作包含哪些检查动作、由谁完成、达到什么标准；项目模板解决项目如何立项、阶段如何划分、交付物如何组织，属于项目计划管理；自动规则解决跨对象的状态流转与通知触发，属于研发流程自动化。清单可以引用项目模板中的阶段名称，也可以由规则在周期开始时创建执行实例，但条目增删仍由清单负责人和审核角色决定，不通过规则配置绕过评审。
清单在工具中落地时，版本和权限怎么保证可追溯？
思路是模板与实例分离：清单作为模板维护并升版本号，每个周期生成执行实例，实例继承当期条目版本，例外记录在实例上。ONES Wiki 提供页面模板库，可一键创建制式化文档模板，适合存放清单说明、条目定义和变更记录；页面版本记录支持查看与回滚，权限控制可为不同角色配置读写权限。清单模板与执行实例的对应关系可借助文档关联项目任务建立，具体配置范围以实际产品为准。
怎么判断维护职责划分已经到位，而不是停留在文档里？
看记录，不看印象。可核对：四类角色是否都有明确负责人并写入清单说明；每条变更是否有提出人、评审结论和评审人；清单版本号与执行实例是否对得上；发布后是否有通知记录；失效条目是否按周期清理；重复出现的例外是否已进入变更流程。发现某项缺记录时优先补记录，记录会暴露职责空档，例如变更长期没有评审结论，说明审核角色未实际行使决策权。
