团队待办工具上线时，规范要覆盖待办从创建到关闭的完整过程：创建段明确什么该进工具、标题与字段怎么写、谁有权建；分派段明确负责人唯一、协作者与截止时间怎么填、跨人交接怎么处理；状态更新段定义状态集合、每个状态的进入条件、更新时点与超期处理；关闭段定义完成标准、验收人、关闭权限与未完成待办的回收方式。规范落地时配一张字段与状态对照表、一份角色职责清单和一次试运行检查，把规则写进工具配置，避免只停留在文档里。
要点总览（TL;DR）
- 规范骨架以“字段与状态对照表”为主载体，四段规则分别对应创建、分派、状态更新、关闭，每条规则要能落到工具里的字段、状态或权限设置。
- 创建段用三个问题判断准入：是否属于工作产出、是否需要他人知晓或协作、是否有明确可交付结果；标题写“动作加对象”，必填字段控制在四项左右。
- 分派段坚持负责人唯一，被分派人在约定时限内确认或提出异议；状态更新绑定开始做、遇阻塞、完成阶段工作三个节点，关闭需补充结果说明并区分验收权限。
- 推广分试运行、全员启用、复盘调整三步，试运行选一个小组运行一到两周，用实际条目校准规则后再固化到工具配置。
- 上线首周每天抽查字段完整率和负责人空缺，首月每周检查超期未更新数与关闭补充信息比例，连续两个周期不达标就回到规则或工具配置找原因。
上线前先定规范骨架：四段规则与一张对照表
规范骨架的作用是让团队知道要写哪几块、每块写到什么颗粒度。颗粒度的判断标准很简单：一条规则能否直接对应到工具里的某个字段、状态或权限设置。能对应上的，就是可执行规则；只能写成“及时更新”“认真填写”的，需要继续拆。
四段规则各自承担一个生命周期阶段的任务，每段都要写清适用对象、必填字段、责任人和判断标准这四项要素。缺任何一项，规则在执行时都会留下解释空间。
| 规范段落 | 适用对象 | 核心必填字段 | 责任人 | 判断标准 |
|---|---|---|---|---|
| 创建 | 全体成员 | 标题、负责人、截止时间、所属清单 | 创建人 | 是否属于工作待办、字段是否齐全 |
| 分派 | 创建人与被分派人 | 负责人、协作者、截止时间 | 创建人 | 负责人是否唯一、是否确认接受 |
| 状态更新 | 负责人 | 状态、阻塞说明 | 负责人 | 状态是否符合进入条件 |
| 关闭 | 负责人与验收人 | 结果说明、关联文档 | 验收人 | 是否达到完成标准 |
这张对照表是规范的主载体。规范文档可以写得详细，但团队日常查阅和检查时以对照表为准。上线前把表里的字段逐项对照工具配置，确认每个必填项在工具中确实设置为必填，每个状态在工具中确实存在，规范才算真正落地。
创建规范：什么进工具、标题字段怎么写、谁来建
创建规范解决的是入口质量问题。上线初期最常见的现象是待办数量快速膨胀、大量条目无人跟进，根源往往在创建环节缺少准入判断。
准入边界
用三个问题判断一条事项是否进入团队待办工具：是否属于工作产出、是否需要他人知晓或协作、是否有明确的可交付结果。三者至少满足其一再创建。生活习惯类打卡、纯个人备忘不进入团队工具；有明确起止时间、多阶段交付的整体项目归项目管理工具管理，待办工具只承载可独立完成的工作项。这条边界要写进规范，并在试运行阶段用实际条目校准。
标题与字段
标题采用“动作加对象”的短句写法，例如“整理三季度客户反馈清单”，避免只写“客户反馈”这类名词短语。名词标题在分派后容易产生理解偏差，执行人需要反复确认要做什么。
必填字段建议控制在四项：负责人、截止时间、所属清单或项目、优先级。字段过多会拖慢创建速度，导致成员绕过工具用聊天消息派活。优先级建议只设三档，档位含义在规范中写清，例如高优先级表示当天需要响应。
创建权限与代建
规范要写明谁可以给别人建待办。常见做法是团队负责人和项目对接人可以直接代建，普通成员代建时需在创建后当面或通过工具确认，被代建人在约定时限内接受或提出异议。代建规则不写清，容易出现“待办挂在我名下但我不知情”的情况。
查重与合并
创建前先按关键词搜索现有待办，同一事项已在跟踪的，补充说明或调整优先级，不重复创建。周期性重复出现的事项，建成固定模板或周期待办，避免每周手动重建。查重动作依赖工具搜索能力，规范中写明搜索关键词的取法，例如取标题中的对象名词。
分派规范：负责人唯一、协作者与截止时间怎么定
分派规范的核心是责任归属清晰。一条待办只有一个负责人，协作者承担知会与配合职责，不承担完成责任。多头负责是待办长期悬空的主要原因，规范中要把这条写成硬性规则。
确认动作与时限
被分派人需要在约定时限内确认接受，或在工具中提出异议并说明原因。时限建议按团队响应节奏设定，例如一个工作日内。超时未确认的待办，由创建人跟进提醒；连续两次未确认的，升级到团队负责人协调。确认动作让分派从“单方面指派”变成“双方确认”，减少执行阶段的推诿。
截止时间的设定口径
规范要统一截止时间的含义。两种口径可选：按承诺时间设定，即负责人承诺完成的时间；按最晚可接受时间设定，即业务上不能再晚的时间。两种口径混用会让优先级判断失真。建议团队统一采用承诺时间，并在需要对外交付的待办上额外标注最晚可接受时间。
跨人跨团队交接
转派时由原负责人修改负责人字段，并在待办中写明转派原因和已完成部分，知会原创建人。跨团队交接需要双方团队负责人知晓，避免出现两边都以为对方在跟进的情况。转派记录保留在待办动态中，作为后续追溯依据。
创建人的跟踪责任
分派完成后，创建人仍对事项结果负责，跟踪方式是定期查看自己创建的待办列表，对临近截止时间仍未启动的条目主动询问。这条规则防止创建人把待办一分派就当作任务完成。
状态更新规范：状态集合、进入条件与更新时点
成员不愿更新状态，通常是因为状态太多、含义不清、更新动作没有明确触发点。规范的做法是从最小状态集开始，给每个状态写清进入条件，并把更新动作绑定到具体工作节点上。
最小状态集合
建议从五个状态起步：待处理、进行中、阻塞、待验收、已完成。每个状态写明进入条件和退出条件，例如“进行中”的进入条件是负责人已开始实际工作，退出条件是产出交付物或转入阻塞。状态含义在团队内统一后，看板上的分布才有参考价值。
| 状态 | 进入条件 | 退出条件 | 更新时点 |
|---|---|---|---|
| 待处理 | 待办已创建并确认分派 | 负责人开始工作 | 创建或接受分派时 |
| 进行中 | 负责人已开始实际工作 | 产出交付物或遇到阻塞 | 开始工作时 |
| 阻塞 | 存在无法自行解决的外部依赖 | 依赖解除或转派 | 遇到阻塞当天 |
| 待验收 | 交付物已完成，等待验收 | 验收通过或退回 | 完成阶段工作时 |
| 已完成 | 验收通过并补充结果说明 | — | 验收通过时 |
更新时点
规范把更新动作绑定到三个节点：开始做时改为进行中，遇到阻塞当天改为阻塞并填写阻塞说明，完成阶段工作改为待验收。这三个节点是工作节奏中自然出现的时刻，比“每天更新一次”更容易执行。日常无需频繁改动状态，避免为了更新而更新。
阻塞说明与升级路径
阻塞状态必须填写阻塞说明，写清卡在谁、卡在什么事、需要什么支持。阻塞超过约定时长未解除的，由负责人升级到团队负责人协调。升级路径写进规范，让成员知道遇到卡点找谁，而不是把待办挂着不动。
超期未更新处理
截止时间已过且状态未变化的待办，进入超期清单，由团队负责人在周会上逐条过问，处理方式包括重新设定截止时间、转派或取消。超期清单每周生成一次，处理结果记录在待办中。工具若支持到期提醒，可在配置中开启，提醒规则与规范中的处理节奏保持一致。
状态流转要真正约束执行，需要工具侧配合。ONES Project 支持自定义需求状态与多种属性，需求和相关任务可规划至迭代并分配负责人，团队可以把上述状态集合和负责人字段直接配置到工作项中；看板视图能按状态呈现待办分布，便于在周会上核对超期条目。具体状态流转规则与提醒能力的配置范围，建议在试用环境中确认后再固化到规范里。
关闭规范：完成标准、验收人与未完成待办的处理
关闭环节的问题有两类：提前关闭，交付物还没达到要求就被标记完成；长期挂起，待办既没完成也没取消，一直占用列表。规范要同时给出完成判定和清理规则。
完成标准与验收人
每条待办在创建时就应能说清完成标准，例如“清单整理完毕并发送给对接人确认”。涉及对外交付或跨团队依赖的待办，指定验收人，由验收人确认后关闭。普通内部待办可由负责人自行关闭，但需补充结果说明。关闭权限按待办类型区分，规范中列明哪些类型必须验收人关闭。
关闭时补充的信息
关闭时填写结果说明，写清实际交付了什么、与预期的差异；有关联文档或链接的，一并附上。结果说明是后续复盘和知识沉淀的素材，也是判断关闭是否规范的依据。规范可要求结果说明不少于一句话，描述具体产出而非“已完成”三个字。
未完成待办的回收
截止时间已过且确认不再执行的待办，按三种方式处理：业务上不再需要的直接取消并注明原因；仍需执行但排期后移的转下期并重设截止时间；负责人暂时无法推进的退回待处理并重新分派。三种处理方式的选择规则写进规范，避免成员用“一直挂着”代替决策。
周期性清理
指定清理责任人，建议由团队负责人或工具管理员承担，每月清理一次长期未更新的待办。清理时逐条确认处理方式，处理结果在团队内同步。清理机制让待办列表保持可信，成员查看列表时能据此判断优先级。
关闭环节的信息补充和权限控制，可以借助工具承载。ONES Project 提供产品、项目、任务多层级权限，可按组织架构、用户组、项目角色分配，团队可据此区分验收人与普通成员的关闭权限；ONES Wiki 支持文档关联任务，关闭时把交付文档与工作项关联，结果说明和产出物保存在同一处，便于后续查阅。权限粒度和关联方式的具体配置需在实施时确认。
角色与交付物：谁写规范、谁执行、谁检查
规范能否执行，取决于责任是否落到具体角色。上线阶段涉及四类角色，各自承担不同的交付物。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 规范制定者（通常为团队负责人） | 起草四段规则，组织讨论定稿 | 待办使用规范文档、字段与状态对照表 |
| 工具管理员 | 把规范配置到工具中，维护字段、状态与权限 | 工具配置记录、字段与状态设置说明 |
| 团队负责人 | 推动执行，处理超期与阻塞升级，组织清理 | 超期清单处理记录、月度清理记录 |
| 团队成员 | 按规范创建、更新、关闭待办 | 符合规范的待办条目 |
推广节奏分三步。试运行阶段选一个小组或一条业务线，运行一到两周，重点收集字段填写和状态流转中的摩擦点，据此修订规范；全员启用阶段完成工具配置、培训材料和规范告知，培训以对照表为教材，用真实待办演示一遍创建到关闭的完整流程；复盘调整阶段在启用一个月后组织一次复盘，根据检查数据调整规则，调整后的版本统一发布，避免多版本并存。
新成员入职时，规范告知纳入入职流程：发放规范文档和对照表，由工具管理员开通账号并演示一次完整操作，第一周内由团队负责人抽查其创建的待办是否符合规范。告知方式写进规范，保证人员流动时规则不丢失。
示例：一个五人小组的待办规范落地样例
以下为演示情景，用于说明四段规范如何写成可执行条目，不代表真实团队案例。
场景设定：一个五人协作小组，负责日常运营支持和临时请求处理，两类事项混合进入待办工具。小组使用统一的待办清单，按“日常运营”和“临时请求”两个清单分类。
创建与分派条目示例
- 创建：临时请求由对接人统一创建，标题写“动作加对象”，例如“整理本周客户投诉分类”；必填负责人、截止时间、所属清单、优先级四项；创建前搜索关键词确认无重复条目。
- 分派：每条待办只设一名负责人，需要配合的成员加入协作者；被分派人在一个工作日内确认或提出异议；跨清单转派时写明原因并知会对接人。
状态更新与关闭条目示例
- 状态更新：开始处理时改为进行中；因外部资料未到位无法推进的，当天改为阻塞并写明卡点；完成整理后改为待验收，由对接人验收。
- 关闭：验收通过后由对接人关闭，结果说明写清交付内容和发送对象，附上整理后的文档链接；本周未处理的临时请求，业务上不再需要的取消并注明原因，仍需处理的转下期并重设截止时间。
这组条目体现了规范的基本结构：输入是待办事项和字段信息，动作是创建、确认、改状态、验收关闭，输出是字段齐全的待办条目、状态记录和带结果说明的关闭记录。小组可按此格式把四段规则逐条写成自己的版本。
完成检查：上线后如何验证规范被执行
规范执行情况用数据核对，比凭感觉判断可靠。上线后按以下检查项逐项核对，每项给出通过标准和不通过时的调整动作。
| 检查项 | 计算方式 | 通过标准（建议） | 不通过时的调整 |
|---|---|---|---|
| 字段完整率 | 必填字段齐全的待办数 ÷ 待办总数 | 不低于 90% | 检查工具必填设置是否生效，补充培训 |
| 负责人空缺数 | 未设负责人或负责人已离职未转派的待办数 | 为 0 | 由团队负责人逐条补派或取消 |
| 超期未更新数 | 截止时间已过且状态未变化的待办数 | 周环比下降 | 纳入周会过问，分析卡点类型 |
| 关闭补充信息比例 | 关闭时填写结果说明的待办数 ÷ 已关闭待办数 | 不低于 80% | 明确关闭必填要求，验收人把关 |
检查时点分三个节点：上线首周每天抽查一次，重点看字段完整率和负责人空缺，及时纠正填写习惯；上线首月每周检查一次，增加超期未更新数和关闭补充信息比例；此后按季度复盘，结合检查数据判断是否需要修订规范。通过标准的具体数值由团队根据业务节奏设定，上表数值仅作参考。
检查结果由团队负责人汇总，记录在固定的检查记录中，包含检查日期、各项数值、发现的问题和调整动作。连续两个检查周期不达标的检查项，回到规范本身找原因：是规则写得不清楚，还是工具配置没跟上，或是培训没覆盖到。调整动作完成后在下一个周期复核效果，形成规范制定、执行、检查、修订的闭环。
常见问题
团队规模很小，四段规范能不能简化？
可以简化条目数量，但四段结构建议保留。小团队可把字段压缩到负责人和截止时间两项，状态集合保留待处理、进行中、已完成三个，关闭时用一句话写结果说明。简化的是字段和状态数量，创建准入、负责人唯一、关闭需说明结果这三条判断规则仍然保留，否则待办列表很快会失去可信度。
成员反映更新状态太麻烦，规范怎么调整？
先检查状态集合是否过多、更新时点是否绑定在自然工作节点上。把状态压到最小集，只在开始做、遇到阻塞、完成阶段工作三个时刻要求更新，日常不强制频繁改动。如果工具支持到期提醒，可开启提醒并与周会处理节奏对齐。调整后观察一个检查周期，看超期未更新数是否下降，再决定是否进一步简化。
被分派人一直不确认接受，规范里怎么处理？
规范应写明确认时限，例如一个工作日内。超时未确认的由创建人跟进提醒，连续两次未确认的升级到团队负责人协调。同时检查分派方式：如果待办是通过聊天消息口头指派的，被分派人可能并不知情，需要回到工具中完成正式分派并确认。确认动作本身也是责任交接的凭据。
关闭权限应该只给验收人吗？
按待办类型区分更实际。涉及对外交付或跨团队依赖的待办，由验收人确认后关闭；普通内部待办可由负责人自行关闭，但需补充结果说明。规范中列明哪些类型必须验收人关闭，并在工具中按角色配置对应权限。ONES Project 提供产品、项目、任务多层级权限，可按组织架构、用户组、项目角色分配，具体权限粒度需在实施时确认。
规范上线后多久复盘一次比较合适？
建议三个节点：上线首周每天抽查，重点纠正字段填写习惯；上线首月每周检查一次，增加超期未更新数和关闭补充信息比例；此后按季度复盘。复盘时结合检查数据判断是规则写得不清楚、工具配置没跟上，还是培训没覆盖到。调整后的规范统一发布，避免多版本并存。
