任务命名规范要解决的是“在任务列表里一眼看出做什么、对什么做、做到什么范围”。制定时先确定名称需要承载的对象、动作和范围，再给出可套用的结构模板、动词表和禁用写法，用真实任务试填校准，最后把规则放进任务创建入口并定期抽查。本文只讨论可执行工作项的命名，项目交付范围的WBS编制和需求层级分解不在范围内。若团队用ONES承载任务，规范可以结合工作项创建与筛选场景落地。
要点总览（TL;DR）
- 任务名称要让人不打开详情就能判断对象、动作和范围，推荐结构为“模块-动作-对象-限定条件”，对象和动作必填，限定条件按需补充。
- 制定规范分五步：抽样归类问题、确定模板与动词表、真实任务试填、写入创建入口、定期抽查迭代，每步都有明确输出。
- 规范制定者、评审者、任务创建人和团队负责人分工明确，交付物可交接，不额外增加审批链。
- 落地检查看四项：文档完整性、创建入口可见性、抽样合规率和新成员上手情况，不达标时按问题类型采取具体动作。
- 规范只约束可执行工作项，WBS编制和需求层级分解各有规则，不套用本文模板。
一条任务名称要写清哪几件事
任务名称的第一读者是列表里的执行人和协作者。名称需要让人在不打开详情的情况下判断三件事：这条任务作用于哪个对象，要完成什么动作，范围或限定条件是什么。对象可以是页面、接口、模块、文档、客户数据；动作是具体操作，如修改、补充、验证、迁移；范围包括环境、版本、批次、区域或时间窗口。名称写清这三类信息，列表浏览和搜索才有稳定依据。
推荐的结构模板是“模块-动作-对象-限定条件”，字段顺序固定，字段之间用短横线或竖线分隔。模板不要求每条任务四个字段全部出现，但对象和动作必须出现，限定条件在存在歧义时补充。例如“订单模块-修改-退款审核接口-支持部分退款”比“退款优化”更容易判断工作内容。团队可以根据业务复杂度调整字段名，例如把“模块”换成“系统”或“业务域”，但同一团队内应保持字段顺序一致。
| 信息类别 | 放在名称中 | 放在描述或字段中 | 判断依据 |
|---|---|---|---|
| 对象 | 模块、页面、接口、文档等核心对象 | 对象的具体路径、链接、背景说明 | 名称用于识别，详情用于定位 |
| 动作 | 一个主要动词，如修改、补充、验证 | 动作步骤、验收标准、依赖关系 | 名称只表达做什么，不展开怎么做 |
| 范围 | 环境、版本、批次、区域等限定词 | 完整范围说明、例外情况、数据口径 | 名称保留区分同类任务所需的最小限定 |
| 负责人与时间 | 通常不写入名称 | 负责人字段、截止日期字段 | 这些信息会变化，放入字段便于筛选和统计 |
| 优先级与状态 | 不写入名称 | 优先级、状态字段 | 状态流转频繁，名称应保持稳定 |
名称与描述的分工要明确：名称承担识别和区分，描述承担背景、步骤、验收标准和依赖。把验收标准塞进名称会让列表难以扫读，把对象和动作都省略则会让名称失去识别作用。规范可以规定名称长度上限，例如不超过30个汉字或60个字符，超过时优先压缩限定条件，把细节移入描述。
边界需要说清楚：本文的命名规范只约束可执行工作项，例如开发任务、测试任务、文档编写任务、数据核对任务。项目交付范围的WBS编制关注交付物分解和范围控制，需求分解与需求层级管理关注需求归属和父子关系，这两类工作有各自的分解规则，不套用本文的任务命名模板。团队如果同时管理需求和任务，可以分别制定命名约定，避免把需求标题的写法直接套到执行任务上。
制定规范的五个步骤
制定规范的过程本身要产出可用的文档和模板，而不是停留在讨论。下面五步按顺序执行，每一步都给出输入、动作、输出和完成标志，团队可以按自身节奏合并或拆分。
第一步：收集现有任务名称样本并归类问题
输入是近一个月或近一个迭代的任务列表导出，样本量建议不少于100条，覆盖不同项目和不同创建人。动作是逐条阅读名称，把问题归入几类：只有对象没有动作、只有动作没有对象、范围缺失导致同名任务无法区分、名称包含状态或负责人等易变信息、名称过长或过短、使用内部简称导致新成员无法理解。输出是一份问题分类清单，每类附3到5条真实例子。完成标志是团队能指着清单说出“我们的主要问题是哪两类”，而不是笼统地说名称不规范。
第二步：确定模板、动词表与禁用写法
输入是第一步的问题分类清单和团队的任务类型分布。动作是确定字段顺序和分隔符，整理常用动词表，列出禁用写法。动词表按任务类型分组，例如开发类包括实现、修改、重构、修复、迁移；测试类包括验证、回归、补充用例、复现；文档类包括编写、修订、评审、归档。禁用写法包括“优化一下”“处理问题”“跟进”“其他”“临时任务”这类无法判断对象的表达，也包括把优先级、负责人、日期写进名称的做法。输出是规范文档初稿，包含模板、动词表、禁用清单和正反示例。完成标志是初稿能让一个未参与讨论的同事看懂并试着填写。
第三步：用真实任务试填并修订
输入是规范初稿和一批真实待创建或近期创建的任务。动作是让不同角色的成员按模板试填，收集两类反馈：模板是否够用，哪些任务套不进去；动词表是否覆盖实际动作，哪些词反复出现但未收录。试填后逐条比对原名称和试填名称，判断新名称是否更容易区分。输出是修订后的规范版本和试填记录。完成标志是试填样本中八成以上能套用模板，剩余任务有明确的例外处理方式，例如允许在名称后加括号补充说明。
第四步：写入任务创建入口与模板
输入是定稿的规范文档和团队使用的任务管理工具。动作是把规范放到任务创建时能看到的位置：在项目模板中预置名称示例，在任务创建说明或字段提示中写明模板，在新项目初始化时附带命名约定。若工具支持工作项模板或字段配置，可以把常用字段与名称规则一起固化；若工具不支持名称格式校验，则通过创建页提示和示例降低误写。输出是创建入口中的规范提示和示例。完成标志是新成员创建第一条任务时能直接看到模板，不需要额外询问。
第五步：定期抽查与迭代
输入是抽查周期内的任务名称样本和规范文档。动作是按固定口径抽样，统计合规率，记录高频误写，判断是规范问题还是执行问题。若某类任务反复套不进模板，修订模板或补充动词；若合规率低但规范本身合理，加强创建时的提示和新人培训。输出是抽查记录和下一版规范修订项。完成标志是每次抽查都有结论和明确动作，规范版本可追溯。
角色分工与各自交付物
命名规范要落地，需要区分制定、执行和检查三类角色。角色可以由现有岗位兼任，但职责和交付物要写清楚，避免规范停留在文档里。
| 角色 | 主要职责 | 交付物 | 参与频率 |
|---|---|---|---|
| 规范制定者 | 收集样本、起草模板与动词表、组织试填和修订 | 规范文档、模板、动词表、禁用清单、试填记录 | 制定期集中投入，后续按版本修订 |
| 评审者 | 从执行视角检查模板是否可用，确认例外处理方式 | 评审意见、定稿确认 | 规范定稿前参与一次 |
| 任务创建人 | 按模板填写名称，把背景和验收标准放入描述 | 合规的任务名称和完整描述 | 每次创建任务时 |
| 团队负责人或项目管理员 | 组织抽查、统计合规率、推动修订和培训 | 抽查记录、合规率统计、培训材料、修订项 | 按固定周期，例如每迭代或每月 |
规范制定者通常由熟悉团队任务类型的人担任，例如项目管理员、技术负责人或敏捷教练。制定者需要拿到真实样本，不能只凭印象设计模板。评审者应包含一线执行人，因为名称是否好用最终由创建人和执行人判断。任务创建人的责任是套用模板并把细节放入描述，遇到套不进去的任务时记录问题而不是随意另写。团队负责人或项目管理员负责抽查和统计，把合规率作为过程指标观察，不把单条名称问题直接变成个人考核。
各角色的交付物要能交接：制定者交付的规范文档应包含模板、示例和例外规则；评审者交付的评审意见应明确“通过”或“需修订”；创建人交付的是可被列表识别的任务名称；负责人交付的是抽查记录和下一轮动作。角色之间不需要额外审批链，避免创建任务变成多一道流程。
示例：从模糊名称改到规范名称
下面的示例均为演示情景，用于说明规则如何套用，不代表真实项目数据。每条先给改前名称，再给改后名称，并说明套用了哪条规则。
| 改前名称 | 改后名称 | 套用规则 | 判断依据 |
|---|---|---|---|
| 优化一下 | 订单模块-修改-退款审核接口-支持部分退款 | 补对象、动作和限定条件 | 原名称没有对象和范围，无法判断做什么 |
| 登录问题处理 | 账号模块-修复-短信登录验证码-超时重发 | 动作具体化，补对象和场景 | “处理”过于笼统，修复对象和触发场景需要写明 |
| 张三负责报表 | 报表模块-补充-月度销售报表-华东区域 | 移除负责人，补动作和范围 | 负责人应放字段，名称表达工作内容 |
| 测试 | 支付模块-验证-退款流程-沙箱环境 | 补对象、动作和环境限定 | 单独“测试”无法区分测试对象和环境 |
| 紧急！明天上线 | 商品模块-迁移-库存字段-生产环境 | 移除优先级和时间，补对象与动作 | 紧急程度和时间放优先级与截止日期字段 |
| 接口联调 | 订单模块-联调-物流查询接口-与仓储系统 | 补对象和对接方 | 联调对象和对接系统是区分同类任务的关键 |
逐条看规则：第一条原名称只有模糊动作，改后按“模块-动作-对象-限定条件”补齐，限定条件“支持部分退款”是区分同类退款任务的关键。第二条把“处理”换成“修复”，并补上触发场景“超时重发”，让执行人知道问题边界。第三条把负责人从名称移到字段，名称只保留工作内容，避免人员变动后名称失真。第四条补环境限定，因为同一验证任务在沙箱和生产环境下的做法不同。第五条把优先级和时间移出名称，名称保持稳定，紧急程度通过优先级字段表达。第六条补对接方，因为“接口联调”本身无法区分联调哪个接口、和谁联调。
常见误写还有两类：一是用内部简称代替对象，例如“老系统改造”，新成员无法判断“老系统”指哪个系统；二是把多个动作塞进一条名称，例如“修改并验证支付回调”，这种情况应拆成两条任务，或在名称中保留主要动作，把后续动作写入描述或子任务。规范可以规定一条名称只表达一个主要动作，需要多个动作时拆分任务。
完成检查：规范是否真的落地
判断规范是否落地，不能只看文档是否写完，要看创建入口是否有提示、抽样名称是否合规、新成员是否能独立套用。下面给出可逐项核对的检查清单和通过标准，团队可按自身规模调整抽样量和周期。
| 检查项 | 检查方法 | 通过标准 | 不达标时的动作 |
|---|---|---|---|
| 规范文档完整性 | 对照模板、动词表、禁用清单、正反示例四项逐一检查 | 四项齐全，新成员阅读后能独立填写 | 补齐缺失项，补充示例 |
| 创建入口可见性 | 让未参与制定的成员创建一条任务，观察是否能找到模板 | 创建时能直接看到模板或示例，无需询问 | 在项目模板、创建说明或字段提示中补充 |
| 抽样合规率 | 按固定周期抽取不少于30条任务名称，按“对象、动作、范围”三项判断 | 合规率达到团队设定目标，例如八成以上；未达标名称有明确问题分类 | 分析高频误写，判断是规范问题还是执行问题 |
| 新成员上手 | 新成员入职后首次创建任务时观察是否套用模板 | 首次创建即可套用，或在少量提示后套用 | 补充新人培训材料，安排一次示例讲解 |
| 规范迭代记录 | 检查规范版本和修订记录 | 每次抽查后有结论，修订项可追溯 | 建立简单修订记录，指定负责人 |
抽样合规率的判断口径要统一：一条名称同时具备可识别的对象和明确动作，视为基本合规；范围缺失但同类任务不产生混淆，可视为合规；名称包含负责人、优先级、日期等易变信息，或使用禁用写法，视为不合规。统计时按条计数，不按人计数，避免把过程指标变成个人评价。抽查发现的问题按类型汇总，例如“范围缺失”占比高，说明模板中的限定条件需要更明确的填写提示；“动作笼统”占比高，说明动词表需要补充或培训需要加强。
不达标时的处理动作要具体：文档缺失就补文档，入口不可见就改创建页提示，合规率低就分析样本并安排短培训，新成员上手困难就增加示例。规范运行一段时间后，如果某类任务反复套不进模板，应修订模板而不是强行套用。规范的目标是让任务列表可读、可筛选、可交接，检查项围绕这个目标设置，不追求名称形式上的整齐。
当团队在ONES Project中管理任务时，可以把命名约定与工作项创建流程结合：在项目模板和任务创建说明中放置名称示例，利用任务筛选器按模块、负责人等条件定位任务，结合多层级权限让项目管理员承担抽查职责。ONES Project支持任务管理场景，团队可围绕项目计划、工作项和迭代安排协同工作，及时了解任务状态和待处理事项；其任务筛选器支持全局筛选与项目内筛选，便于按条件抽取样本。名称格式校验能否在创建入口强制生效，取决于实际配置，团队可以用创建提示、示例和抽查组合实现规范落地。
常见问题
团队任务类型差异很大，一套命名模板够用吗？
可以共用一套字段顺序，但动词表和限定条件需要按任务类型分组。开发、测试、文档、数据核对的任务对象和动作差异明显，模板只规定“对象-动作-范围”的骨架，具体动词由各类型补充。如果某类任务长期套不进模板，优先检查是字段顺序不适合，还是该类任务本身需要单独的命名约定。规范允许存在例外，但例外要有明确记录，不能变成随意填写。
任务名称里要不要写负责人和截止日期？
通常不写。负责人和截止日期会随人员调整和排期变化，写进名称后名称容易失真，也不利于按字段筛选和统计。这些信息放在任务字段中，名称只保留相对稳定的工作内容。如果团队习惯在名称里标注时间窗口，例如“Q4迁移”，应确认这是区分同类任务所必需的限定条件，而不是把截止日期换个说法写进名称。
规范制定后合规率一直上不去，应该先改规范还是先加强培训？
先看抽样中的问题分布。如果高频问题是“动作笼统”，说明动词表覆盖不足或创建人不知道有哪些可选动词，补充动词表和示例更有效；如果高频问题是“范围缺失”，说明模板中的限定条件提示不够明确，需要修改创建页提示。如果规范本身合理、问题集中在少数新成员，安排一次短培训和示例讲解即可。判断依据是问题类型，而不是合规率数字本身。
在ONES Project中能把命名规则强制生效吗？
名称格式校验能否在创建入口强制生效，取决于实际配置，现有资料未明确说明支持名称级校验。团队可以用组合方式落地：在项目模板和任务创建说明中放置名称示例，利用任务筛选器按模块、负责人等条件抽取样本做抽查，由项目管理员承担检查职责。ONES Project支持任务管理场景，可围绕项目计划、工作项和迭代安排协同工作，也提供任务筛选器支持全局筛选与项目内筛选。
一条任务包含多个动作时，是拆任务还是写进一个名称？
规范建议一条名称只表达一个主要动作。多个动作如果对应不同的完成标准和验收人，应拆成多条任务；如果后续动作只是主要动作的收尾步骤，可以在名称中保留主要动作，把后续步骤写入描述或子任务。拆分的判断标准是：两个动作能否分别验收、分别指派。能分开验收的，拆开更利于跟踪进度。
