任务边界要写成一份能直接开工、也能直接验收的短文档：输入写清来源、形态和就绪条件；输出写清交付物、格式和存放位置；前置依赖单列，标明依赖对象与解除条件；不包含事项用“本任务不处理……”逐条排除容易混淆的相邻工作；验收标准用可观察、可判定的条目描述完成状态，并注明验收人和证据。本文适用于可执行工作项层面的任务边界编写，不展开项目范围 WBS 与需求层级管理。
要点总览（TL;DR）
- 任务边界写成五项字段：输入、输出、前置依赖、不包含事项、验收标准，每项回答一个具体问题，缺一项就会在执行或验收时暴露。
- 编写顺序先定输出再回推输入：输出写清交付物名称、格式、存放位置和接收对象，输入写清来源、形态和就绪条件。
- 前置依赖从输入中单列，写明依赖对象、责任方和解除条件；不包含事项用“本任务不处理……”逐条排除最易混淆的相邻工作。
- 验收标准逐条对应输出，写成可观察、可判定的条目，并注明验收人和证据来源。
- 边界由任务负责人起草，上下游确认输入输出，验收人确认验收标准；全部检查项通过即可开工和验收。
一份可落地的任务边界包含哪五项内容
任务边界的作用是让执行者在动手前知道“拿什么、交什么、不碰什么、怎样算完成”。把这四类信息加上前置依赖，拆成五个字段，就能覆盖任务从启动到验收的主要判断点。五项内容各归其位、互相引用，边界才算清晰。
| 字段 | 回答的问题 | 填写要求 | 缺失后的典型后果 |
|---|---|---|---|
| 输入 | 开始这项工作需要哪些材料、数据和信息？从哪里来？ | 逐项写来源、形态（文档、数据表、接口、会议结论等）、就绪条件（如“已评审通过”“已提供最新版本”） | 执行者反复找人要材料，或拿到过期版本返工 |
| 输出 | 任务完成后交付什么？给谁？放在哪里？ | 写交付物名称、格式、存放位置和接收对象 | 交付物形态不一致，下游无法直接使用 |
| 前置依赖 | 哪些外部条件必须先满足？由谁负责？何时解除？ | 单列依赖对象、责任方、解除条件与时间点 | 任务卡在等待中，却没人知道在等谁 |
| 不包含事项 | 哪些相邻工作本任务明确不做？ | 用“本任务不处理……”逐条排除最易混淆的相邻工作 | 范围被逐步扩大，工期和资源失控 |
| 验收标准 | 怎样判断任务完成？谁来验收？看什么证据？ | 写成可观察、可判定的条目，注明验收人和证据来源 | “做完了”各说各话，验收反复拉扯 |
五个字段之间存在引用关系：验收标准要逐条对应输出，输出是什么，验收就看什么；输入要与前置依赖对齐，凡是需要外部先提供的材料，既在输入中说明形态，也在前置依赖中写明责任方和解除条件。编写时保持这种对应，可以避免“输入写了但没人提供”“验收标准找不到对应交付物”的断裂。
按顺序填写：从输入到验收标准的编写步骤
推荐先定输出，再回推输入。输出是任务的终点，先明确终点，输入和依赖才有筛选依据；反过来从手头材料出发写边界，容易把“有什么做什么”写成任务范围。
第一步：写输出
动作是列出交付物清单，每项写清名称、格式、存放位置和接收对象。完成标志是：任何一个交付物都能被下游直接找到并打开使用，不需要再追问“最终版在哪”。例如“接口说明文档，Markdown 格式，存放于项目文档库对应目录，接收方为前端开发负责人”。
第二步：回推输入
针对每个输出，倒推需要哪些材料才能产出。每项输入写来源、形态和就绪条件。完成标志是：执行者按清单能判断“现在能不能开工”，缺哪一项一目了然。就绪条件要具体，如“需求评审纪要已定稿并抄送本任务负责人”，避免只写“需求已明确”。
第三步：单列前置依赖
把需要外部角色先完成的事项从输入中抽出来单列，写明依赖对象、责任方、解除条件和期望时间。完成标志是：每条依赖都能对应到一个具体的人或团队，并且有可观察的解除标志，如“测试环境账号开通并完成登录验证”。依赖未解除时，任务状态应标记为等待，而不是默认已开工。
第四步：写不包含事项
先列出与本任务最容易混淆的相邻工作，再逐条用排除句式写明。完成标志是：上下游读完能确认“这件事不归这个任务”。排除要针对具体工作，如“本任务不处理历史数据迁移”“本任务不负责上线后的用户培训”，避免只写“不包含其他相关工作”这类无法执行的表述。
第五步：写验收标准
每条验收标准对应一项输出，写成可观察、可判定的状态，并注明验收人和证据。完成标志是：验收人只看标准就能判断通过与否，不需要额外解释。例如“文档中每个接口均包含请求参数、返回字段和错误码示例，由后端负责人对照接口清单逐项核对，核对记录作为证据”。
角色分工：谁写、谁确认、谁验收
任务边界由任务负责人起草，上下游和验收人分别确认与自己相关的部分，避免边界由单人拍定。起草者最了解任务意图，上下游最清楚接口是否可行，验收人决定完成标准是否成立，三方各看一段，边界才经得起执行检验。
| 角色 | 具体动作 | 交付物 |
|---|---|---|
| 任务负责人 | 按五字段起草边界，标注不确定项，组织确认 | 任务边界初稿 |
| 上游提供方 | 确认输入项来源、形态和就绪时间，确认前置依赖的解除条件 | 输入与依赖的确认意见 |
| 下游接收方 | 确认输出交付物名称、格式和存放位置满足使用需要 | 输出项的确认意见 |
| 验收人 | 确认验收标准可判定、证据可获取，确认验收方式 | 验收标准确认结果 |
边界变更时走同一条确认路径：任务负责人修改字段，涉及输入或依赖的变更找上游确认，涉及输出的变更找下游确认，涉及验收标准的变更必须经验收人重新确认。变更记录保留在边界文档中，注明变更内容、确认人和时间，避免口头调整后各方理解不一致。
在实际协作中，任务边界字段通常承载在任务管理工作项的描述与验收信息里，上下游在同一个工作项上确认，变更留痕随任务一起保存。ONES 可用于承载任务描述、协作确认与验收信息这类管理动作，具体字段配置以团队实际使用方式为准。
填写示例：一个任务边界从模糊到可执行
以下为演示情景，用于说明写法差异。初始描述是：“负责整理用户反馈，输出反馈报告。”这句话没有说明反馈从哪来、报告给谁、做到什么程度算完成，执行者只能凭经验猜测。
按五字段改写后：
- 输入：近一个月的客服工单导出表（CSV，由客服系统管理员在任务启动后两个工作日内提供最新全量数据）；应用商店评价截图汇总（由运营同学整理，已去重）。就绪条件：两份材料均标注导出日期，且覆盖同一时间区间。
- 输出：《用户反馈月度分析报告》，在线文档格式，存放于产品文档库“用户研究”目录，接收方为产品负责人和客服主管。
- 前置依赖：客服系统导出权限由客服系统管理员开通，解除条件为负责人能成功导出一次测试数据；应用商店评价汇总由运营同学提供，解除条件为文件上传至共享目录并通知任务负责人。
- 不包含事项：本任务不处理工单的分类规则调整；本任务不负责反馈问题的修复排期；本任务不做竞品评价对比；本任务不承担报告宣讲。
- 验收标准：报告覆盖两类来源且标注数据区间；问题按主题归类，每类给出数量与典型原话摘录；结论部分列出不少于三条可跟进建议；由产品负责人验收，以报告文档和工单导出记录为证据。
改写前后的差异集中在四处：输入从“用户反馈”变成有来源、有形态、有就绪条件的材料清单；输出从“反馈报告”变成有名称、格式、位置和接收方的交付物；不包含事项从无到逐条排除分类规则、修复排期、竞品对比和宣讲四类相邻工作；验收标准从“完成报告”变成可逐项核对的条目，并明确了验收人和证据。可迁移的规律是：每个字段都落到可指认的对象上，凡是需要别人配合的地方，都写出责任方和可观察的标志。
完成检查：任务边界是否可以直接开工和验收
边界文档写完后，用下面这份清单逐项核对。全部通过即可开工；任一项不通过，先补齐再启动，避免执行中途反复澄清。
| 检查项 | 通过标准 | 负责人 |
|---|---|---|
| 输入可获取 | 每项输入都有来源、形态和就绪条件，执行者能判断当前是否具备开工条件 | 任务负责人 |
| 输出可识别 | 每项交付物有名称、格式、存放位置和接收对象，下游能直接找到并使用 | 任务负责人与下游接收方 |
| 依赖有归属 | 每条前置依赖写明责任方和解除条件，未解除时有明确的等待状态 | 任务负责人与上游提供方 |
| 排除覆盖混淆点 | 不包含事项逐条对应最易混淆的相邻工作，上下游确认无歧义 | 任务负责人与上下游 |
| 验收可判定 | 每条验收标准对应一项输出，可观察、可核对，注明验收人和证据来源 | 验收人 |
| 变更路径明确 | 边界调整有确认人和记录位置，验收标准变更经验收人重新确认 | 任务负责人 |
出现以下情况视为阻断项，任务暂不开工：关键输入没有明确来源或就绪时间；前置依赖找不到责任方；验收标准无法对应到具体输出。执行中发现输出形态或验收口径需要调整，按变更路径重新确认后再继续，未确认的调整不计入完成。满足清单全部条目，这份任务边界就可以直接用于开工和验收。
常见问题
任务边界和项目范围、需求层级是什么关系，写的时候怎么划清？
任务边界针对的是可执行工作项，回答“这一项任务拿什么、交什么、不碰什么、怎样算完成”。项目交付范围的 WBS 解决的是整个项目拆成哪些交付物，需求分解与层级管理解决的是需求之间的从属和优先级关系。三者层级不同：WBS 和需求层级确定后，每个落到人身上的工作项再写任务边界。
实际操作中，如果发现某个工作项需要再拆成多个交付物，说明它更接近一个子项目或需求包，应先回到范围或需求层面拆分，再为拆出的工作项分别写边界，避免在一份任务边界里塞进多个交付目标。
前置依赖和输入有什么区别，为什么不能合并写？
输入描述的是“需要什么材料”，前置依赖描述的是“谁必须先完成什么动作”。一份材料可能已经存在，只是需要别人开通权限或导出最新版本，这时材料是输入，开通和导出动作是前置依赖。
分开写的好处是责任清晰：输入项让执行者判断能不能开工，前置依赖让等待有明确对象和解除标志。合并成一段，容易出现“材料写了但没人提供、任务卡住却不知道在等谁”的情况。依赖未解除时，任务状态应标记为等待，不默认已开工。
不包含事项写多少条合适，写少了会不会还是蔓延？
不包含事项的数量取决于相邻工作的混淆程度，判断标准是覆盖最容易被误认为属于本任务的工作，而不是凑条数。常见需要排除的有：相邻环节的规则调整、问题修复排期、对外宣讲、历史数据迁移、上线后培训等。
写法上逐条对应具体工作，用“本任务不处理……”的句式，避免“不包含其他相关工作”这类无法执行的表述。写完请上下游各读一遍，确认他们不会再把这些工作派给本任务。执行中如果出现新的相邻工作，按变更路径补充确认，而不是默认接下。
验收标准由谁定，任务负责人自己写可以吗？
任务负责人可以起草验收标准，但必须由验收人确认后才成立。起草者最了解任务意图，验收人决定完成标准是否可判定、证据是否可获取，两者视角不同。验收标准变更时，需要验收人重新确认，口头调整不计入完成。
写法上每条标准对应一项输出，描述可观察的状态，并注明验收人和证据来源。例如“文档中每个接口均包含请求参数、返回字段和错误码示例，由后端负责人对照接口清单逐项核对，核对记录作为证据”。
任务执行到一半发现边界写漏了，怎么处理？
按变更路径处理：任务负责人修改对应字段，涉及输入或依赖的变更找上游确认，涉及输出的变更找下游确认，涉及验收标准的变更必须经验收人重新确认。变更内容、确认人和时间记录在边界文档中，随任务一起保存。
如果遗漏的是关键输入来源、依赖责任方或验收口径，先暂停开工状态，补齐确认后再继续。未确认的调整不计入完成，避免执行完成后各方对“做没做完”理解不一致。
