任务命名规范要解决的是“标题写什么、其余信息放哪里、怎么保证团队照着写”。本文给出一条可执行的制定路径：先界定任务名承载的信息边界，再确定“动作+对象+结果”的句式规则，然后经过盘点、起草、试点、发布四步落地，最后用合规率抽样与可读性检查验证执行效果。
要点总览（TL;DR）
- 一条合格的任务名承载动作、对象、可判断的完成结果三类信息，负责人、截止时间、优先级、状态交给字段承载。
- 主结构采用“动词+对象+结果或范围”，动词与对象词从现有任务名中收敛成词表，长度控制在约30个汉字以内。
- 制定流程分四步：抽样现有任务名归类问题、起草规则与正反示例、选五到十人团队试点两周、发布并嵌入任务创建模板。
- 规范 owner 负责规则与词表维护，团队负责人在任务评审中检查命名，模板维护人同步更新创建模板与字段配置。
- 每月抽取五十到一百条新任务按检查表核对合规率，连续两个月低于约定水平时分析规则难用还是执行不到位，再决定修订或加强评审。
一条合格的任务名要回答什么
合格的任务名要让一个不熟悉背景的同事在列表里扫一眼，就能判断这件事做什么、做到什么程度算完成。它需要承载三类信息：动作（做什么）、对象（对什么做）、可判断的完成结果或范围（做到哪算结束）。例如“整理客户反馈并输出分类清单”，动作是整理，对象是客户反馈，结果是分类清单，三者齐备，执行人不需要追问就能开工。
负责人、截止时间、优先级、状态这些信息有专门的字段承载，写进标题会挤占可读空间，也会在人员或排期变化后让标题失真。标题里写“张三周五前完成登录页改版”，一旦负责人调整或日期顺延，标题就与事实不符，还得逐条修改。把这些交给字段，标题才能保持稳定。
任务名与WBS、需求层级是不同层面的对象。WBS节点描述交付范围的分解结构，需求条目描述要建设的能力及其验收标准，任务则是为完成某个交付物而执行的具体工作项。任务命名规范只约束可执行工作项这一层，不替代WBS编码规则，也不规定需求标题的写法。制定规范时先划清这条界线，可以避免把范围分解、需求评审的规则混进任务命名文档。
| 信息类型 | 放在标题 | 放在字段 |
|---|---|---|
| 动作 | 是，动词开头 | — |
| 对象 | 是，具体到模块、文档或数据 | — |
| 完成结果或范围 | 是，可判断的产出或边界 | — |
| 负责人 | 否 | 负责人字段 |
| 截止时间 | 否 | 截止日期字段 |
| 优先级 | 否 | 优先级字段 |
| 状态 | 否 | 状态字段 |
| 所属迭代或项目 | 视需要，可用编号前缀 | 迭代、项目字段 |
命名结构：动作加对象加结果怎么写
主结构采用“动词 + 对象 + 结果或范围”，动词开头，对象具体，结果可判断。写作时先确定动词，再补对象，最后说明产出或边界。三个成分不必凑满固定字数，但缺了结果成分时，要用范围词补足，例如“排查支付回调超时问题（覆盖三个渠道）”。
动词需要收敛。团队常见的问题是同一类动作出现“做、搞、处理、跟进、优化”等多种写法，检索时互相找不到。做法是从现有任务名中统计高频动词，保留十到二十个，形成动词表，并给每个动词配一句适用说明。例如“编写”用于产出文档或代码，“核对”用于比对两份材料的一致性，“修复”用于消除已确认的缺陷。表外的动词不是禁止使用，而是新出现的动词需要经过规范 owner 确认后补入。
对象词同样需要收敛。对象应写到团队内可识别的粒度，例如“登录页”“订单导出接口”“季度运营报告”，避免“系统”“相关功能”“一些数据”这类无法定位的表述。可以为常用对象建立词表，与项目中的模块、文档目录对应，减少同义写法。
| 规则项 | 建议写法 | 说明 |
|---|---|---|
| 开头 | 动词开头 | 避免“关于……”“……的处理”等名词化开头 |
| 长度 | 控制在约30个汉字以内 | 超出时把细节移入描述字段 |
| 标点 | 不使用句号，括号仅用于补充范围 | 减少列表展示时的视觉噪音 |
| 编号前缀 | 需要跨系统引用时加，如“T-102 修复……” | 团队内检索为主时可不加，避免前缀维护成本 |
| 中英文混用 | 专有名词保留英文，其余用中文 | 如“API”“SDK”可保留，动词与普通名词用中文 |
| 子任务命名 | 继承父任务对象，动词写具体步骤 | 如父任务“编写登录页改版方案”，子任务“编写登录页交互说明” |
子任务与父任务的衔接靠对象一致、动作细化。父任务描述一个可交付的整体结果，子任务拆成可独立执行的步骤，标题中保留同一对象词，读者从子任务名就能看出它属于哪项工作。若子任务与父任务对象不同，说明拆分粒度可能出了问题，应回到拆解环节调整，而不是在命名上勉强拼接。
从现有任务名到规范：四步制定流程
规范不是凭空写出来的，从团队现有任务名出发，经过四步形成可发布的文档，每一步都有明确的输入、动作和完成标志。
第一步：抽样现有任务名并归类问题
输入是近一个季度内创建的任务清单，抽取一百到两百条，覆盖不同团队和任务类型。动作是逐条标注问题类型：缺少动作、对象模糊、结果不可判断、混入人员或日期、同义动词重复、长度过长。输出是一份问题分布统计，完成标志是每类问题都有具体条目作为例证。这一步的价值在于让规范针对真实问题，而不是照搬通用模板。
第二步：起草结构规则与正反示例
输入是第一步的问题统计和团队常用的动词、对象词。动作是写出主结构、动词表、对象词表、长度与标点规则，并为每类问题配一组正反示例。输出是规范初稿，完成标志是初稿中的每条规则都能对应至少一个真实问题，且每条规则都有可对照的示例。
第三步：小范围试点并收集修改意见
输入是规范初稿。动作是选一个五到十人的团队，在两周内按新规则创建任务，规范 owner 每周抽查一次并记录执行中的歧义点。输出是试点问题清单和修订后的规范。完成标志是试点团队的任务名合规率达到约定水平，且歧义点已写入规则或示例库。
第四步：发布规范并嵌入任务创建模板
输入是修订后的规范。动作是正式发布文档，把命名要求写进任务创建模板的提示说明，并在任务评审环节增加命名检查。输出是发布通知、模板更新记录和示例库。完成标志是新创建任务默认按模板填写，评审中有明确的命名检查动作。在工具层面，任务创建模板和字段配置可以由ONES承载，把负责人、截止日期、优先级放进字段，标题只保留动作、对象与结果，规范就从文档变成了创建时的默认路径。
角色分工与交付物
规范能否执行，取决于每个角色是否清楚自己负责哪一段。建议设置一名规范 owner，通常由项目管理或研发效能角色担任，负责规则起草、动词表维护和争议裁定；评审角色由各团队负责人承担，在任务评审时检查命名；执行角色是全体成员，在创建和修改任务时按规则填写；维护角色由 owner 牵头，每季度根据新出现的问题更新示例库。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 规范 owner | 起草规则、维护动词表与对象词表、裁定歧义 | 规范文档、词表、修订记录 |
| 团队负责人 | 在任务评审中检查命名、反馈执行问题 | 评审记录、问题清单 |
| 团队成员 | 创建和修改任务时按规则填写，发现规则不适配时提出 | 合规的任务条目 |
| 模板维护人 | 更新任务创建模板与字段配置 | 模板版本记录 |
交付物需要指定存放位置和更新节奏。规范文档与示例库放在团队共同可访问的文档空间，模板随工具配置更新。owner 变更时，词表与示例库一并交接，避免规范随人员流动而失效。
示例：同一任务的不同命名写法
下面的示例展示规范前后的差异，场景为一次版本发布前的准备工作，可直接对照迁移到自己的项目。
| 场景 | 规范前 | 规范后 |
|---|---|---|
| 缺陷处理 | 登录问题处理一下 | 修复登录页验证码失效问题 |
| 文档产出 | 写个方案 | 编写订单导出接口改造方案 |
| 数据核对 | 对下数据（李四） | 核对六月订单金额与财务台账差异 |
| 测试准备 | 测试环境 | 搭建支付模块联调测试环境 |
子任务拆分后的命名示例如下：父任务“编写登录页改版方案”，可拆为“梳理登录页现有交互问题”“编写登录页新版交互说明”“组织登录页方案评审”。三个子任务对象一致、动作具体，读者从标题即可判断先后关系。
编号前缀适用于需要跨系统引用或对外交付的场景，例如“T-102 修复登录页验证码失效问题”，便于在缺陷单、发布说明中引用。团队内部以列表检索为主时，前缀会增加维护负担，可以不加，靠项目字段区分归属。
完成检查：规范是否真的被执行
规范发布后，用抽样检查判断执行效果。每月从新创建的任务中随机抽取五十到一百条，按检查表逐项核对，计算合规率。合规率连续两个月低于约定水平时，先分析是规则难用还是执行不到位，再决定修订规则还是加强评审。
| 检查项 | 判断标准 | 检查方式 |
|---|---|---|
| 动词开头 | 标题以动词表中的词开头 | 逐条核对 |
| 对象具体 | 对象可定位到模块、文档或数据 | 请非执行人复述对象 |
| 结果可判断 | 能说出完成时交付什么或达到什么边界 | 逐条核对 |
| 字段分工 | 标题中不含负责人、日期、优先级 | 关键词筛查 |
| 长度与标点 | 符合长度上限，无多余标点 | 批量统计 |
| 检索性 | 用对象词能搜到同类任务 | 抽样搜索验证 |
可读性检查可以请一位不参与该任务的同事只看标题，说出这件事做什么、做到什么程度算完成，说不清即视为不合格。检索性检查用常用对象词搜索，看同类任务是否集中出现，若同一对象出现多种写法，说明对象词表需要补充。
出现以下信号时启动规范修订：同类问题在抽查中反复出现、新业务带来词表未覆盖的对象、团队反映规则与工作方式冲突。修订节奏建议每季度一次小版本更新，更新词表与示例库，重大结构调整需重新试点后再发布。规范的生命力在于持续维护，而不是一次发布后长期不动。
常见问题
团队规模很小，也需要单独制定任务命名规范吗？
小团队同样会遇到任务名模糊导致重复沟通的问题，但规范的复杂度可以降低。保留主结构、动词表和长度规则即可，对象词表可以先用项目中的模块名称代替，不必单独维护。评审动作可以并入现有的任务分配环节，由负责人在派发任务时顺带检查标题。团队扩大到需要多人并行处理同类任务时，再补充对象词表和编号前缀规则。
规范发布后，老任务名要不要全部改一遍？
不建议一次性批量修改历史任务。历史任务名承载的是当时的上下文，批量改写会消耗大量时间，还可能破坏已有的引用关系。可行的做法是设定一个时间点，新创建和仍在进行中的任务按新规则命名，已完成任务保持原样。检索时如果旧任务名影响查找，可以在描述字段补充规范化的对象词，或在新任务中引用旧任务编号建立关联。
不同团队的任务类型差异很大，动词表要统一还是各建各的？
建议保留一份团队共用的基础动词表，覆盖编写、核对、修复、搭建、评审等跨团队高频动作，各团队在此基础上补充本领域的专用动词，补充项由规范 owner 确认后并入总表。这样既保证跨团队检索时用词一致，也允许测试、运营等团队保留自己的表达习惯。对象词表可以按团队分别维护，因为对象通常与具体模块和业务直接相关。
任务名里需要写编号前缀吗？
编号前缀适用于需要跨系统引用或对外交付的场景，例如在缺陷单、发布说明、客户沟通中引用任务时，前缀能提供稳定的定位标识。团队内部以任务列表检索为主时，前缀会增加维护成本，任务移动或合并后编号容易失效。判断标准是这条任务是否会被团队之外的人引用，会则加，不会则依靠项目字段区分归属。
规范执行一段时间后合规率下降，应该先改规则还是先加强检查？
先做归因再决定。抽取不合规的任务名，看问题集中在哪一类：如果多数是规则本身难用，例如长度上限过严导致关键信息放不下，就修订规则；如果规则清晰但执行松散，例如新成员不知道规范存在，就加强模板提示和评审检查。两种情况的处理方式不同，混在一起调整容易让规范反复变动，反而降低团队对规则的信任。
