项目范围示例：一份可填写的范围说明与分解样例

项目范围说明写不完整，常见原因是缺少可对照的样例：目标写得像愿望，交付物列了名称却没有验收口径，排除项没有写，后续讨论范围时各人有各人的理解。本文提供一份假设的“企业官网改版”项目范围示例，包含可直接替换填写的范围说明与交付物分解表，并逐项解释字段写法、可迁移规律和适用边界。示例中的范围条目在协作工具中形成基线与评审记录的做法，会结合ONES的相关能力说明。

要点总览（TL;DR）

• 项目范围示例包含两部分：一页范围说明（目标、交付物、验收标准、假设与约束、排除项）和一张交付物分解表（交付物、子项、验收标准、责任人、交付时点）。
• 目标要写成可判断完成的结果，交付物拆到能单独判断完成或未完成的层级，验收标准与子项同行并列，责任人写到角色。
• 可迁移的规律是先定边界再分解、先写排除项再写包含项、分解控制在两到三层、范围说明作为基线版本管理。
• 示例适用于交付物能事先界定的项目；探索型项目改为滚动式范围，范围调整转入变更管理，执行任务拆解另属其他主题。
• 范围条目可在ONES中按项目计划分解、设置基线并对比偏差，评审时对照基线逐条判断交付物是否达到验收标准。

这份项目范围示例要解决什么问题

这份示例面向需要起草项目范围说明的项目经理、产品负责人和交付负责人，示范两个填写动作：一是把项目目标、交付物、验收标准、假设约束和排除项写进一页范围说明；二是把交付物拆成可逐条验收的范围条目。读者可以保留结构，替换项目名称、交付物名称、验收口径和责任人角色，形成自己项目的初稿。

示例情景设定为一家企业委托团队改版官方网站，属于假设情景，用于演示填写结构，不代表真实客户案例，也不附带实测效果。选择这个情景，是因为官网改版同时包含设计、开发、内容迁移和上线准备等不同类型的交付物，能够展示范围说明与分解表如何配合使用。

示例覆盖范围说明书与范围分解两部分。执行阶段的任务排期、人员工时分配，以及范围变更的审批单设计，属于其他主题，本文只在必要处说明衔接关系。

完整示例：官网改版项目的范围说明与分解表

以下内容为示例数据，项目背景、角色名称和时间点均为演示设定。填写时可直接沿用字段结构，把具体内容替换为实际项目信息。

范围说明（示例）

字段	示例填写内容
项目目标	在约定上线日前，完成企业官网改版并上线，使网站在桌面端与移动端均可正常访问，核心页面（首页、产品介绍、解决方案、关于我们、联系我们）内容完整，表单提交可正常到达指定邮箱。
交付物清单	①网站信息架构与页面清单；②视觉设计稿（核心页面）；③前端页面与后台内容管理配置；④内容迁移结果（既有公开内容迁入新站）；⑤上线检查记录与操作说明。
验收标准	每个交付物在分解表中单独列出验收口径；整体验收以核心页面可访问、表单可提交、内容迁移无遗漏清单项为准。
假设与约束	假设：客户在约定节点前提供品牌素材与既有内容清单；约束：沿用现有域名与备案主体，上线时间受客户内部审批节奏影响。
不在范围内	不包含上线后的内容运营与持续更新；不包含搜索引擎推广与广告投放；不包含多语言版本；不包含客户自有系统的对接改造。

交付物分解表（示例）

交付物	子项	验收标准	责任人（角色）	交付时点
信息架构与页面清单	站点地图、页面清单、导航结构	核心页面全部列入清单，导航层级经客户确认	产品负责人	第2周
视觉设计稿	首页设计稿、内页模板设计稿	覆盖核心页面类型，客户书面确认一版	设计负责人	第4周
前端页面与后台配置	核心页面开发、内容管理后台配置	核心页面在桌面端与移动端可正常访问，后台可发布与修改页面内容	开发负责人	第7周
内容迁移结果	既有公开内容迁入、迁移核对清单	清单内条目全部迁入，抽查页面内容与原文一致	内容负责人	第8周
上线检查记录与操作说明	上线检查表、后台操作说明	检查表逐项完成并记录结果，操作说明覆盖发布与修改流程	交付负责人	第9周

这张分解表把每个交付物拆到可以单独判断“完成还是未完成”的层级，验收标准与子项同行并列，责任人和交付时点也落在同一行，评审时不需要再到其他文档里找对应关系。

逐项解释：每个字段为什么这样填

目标字段写成可判断完成的结果。示例中的目标包含上线时间、访问范围、核心页面范围和表单可用性，评审时可以逐条核对；如果写成“提升官网形象与用户体验”，就无法判断项目何时算完成。目标不必长，但要包含能被验证的对象。

交付物按可验收的颗粒度分解。示例把“网站”拆成信息架构、设计稿、前端与后台、内容迁移、上线检查五类，每一类都有独立的完成标志。子项与验收标准一一对应：子项回答“交付什么”，验收标准回答“凭什么算交付完成”。两者分列在不同列，是为了避免验收标准被写成一句笼统的“符合要求”。

不在范围内事项的作用是提前处理边界争议。示例明确排除内容运营、推广投放、多语言版本和系统对接改造，这些内容在官网项目中经常被默认包含，写清楚之后，后续讨论新增需求时可以直接对照排除项判断是否需要走变更。排除项宜写具体事项，避免只写“其他相关工作”。

责任人写到角色而非泛称。“开发负责人”“内容负责人”能够对应到具体承担者，写“相关同事”则在评审时无人认领。交付时点与里程碑对齐，示例中的周次对应项目计划里的关键节点，便于在进度评审时同时检查范围条目和时点。

假设与约束单独成段，是因为它们会影响验收判断。例如客户未按时提供品牌素材，设计稿的确认时点就需要相应调整；把这类前提写在范围说明里，后续出现偏差时有据可查。

从这份示例可以迁移的写法规律

这份示例的价值在于结构，换一个项目仍然适用。以下规律可以直接带到其他项目的范围编写中。

• 先定边界再分解。先写清项目要达成什么、明确排除什么，再把交付物逐层拆开。边界未定时直接分解，容易出现分解结果超出实际授权范围的情况。
• 先写排除项再写包含项。排除项往往比包含项更容易达成一致，先列出不做什么，可以减少后续对“这个算不算范围内”的反复讨论。
• 验收标准与交付物同表并列。把验收口径放在交付物旁边，评审时一次看全；分离到另一份文档，容易出现交付物已更新而验收标准未同步的情况。
• 分解层级控制在两到三层。示例为“交付物—子项”两层，复杂项目可增加一层分类。继续往下拆就进入任务拆解，属于执行计划的范围，混在范围说明里会让文档难以维护。
• 范围说明作为基线版本管理。范围说明确认后形成基线，后续调整通过变更流程处理，并保留版本记录，便于对比变更前后的差异。

这些规律适用于交付物能够事先界定的项目。规律本身不依赖特定工具，用文档表格也能完成；工具的作用在于让条目、责任人和基线版本保持同步。

适用范围与需要调整的地方

这份示例适用于交付物可以在项目初期界定的项目，例如网站建设、系统实施、活动物料制作等。对于需求尚不明确、需要边探索边确定交付物的项目，一次性写死范围说明并不合适，可以改为滚动式范围：先写清本轮迭代的目标、交付物和排除项，每轮结束时更新下一轮范围，基线按轮次管理。

范围分解止于交付物层级。示例中的“前端页面开发”不再往下拆到具体页面任务和人员排期，那属于任务拆解与进度计划的内容。把两者混在一起，范围说明会随执行进度频繁变动，失去作为验收依据的作用。

范围调整应转入变更管理。示例中的排除项和验收标准一旦确认，新增或修改范围条目需要走变更流程，评估对时点和资源的影响后再更新基线。变更审批的具体流程设计不在本文展开。

示例中的验收标准需要按实际业务替换。“核心页面可正常访问”在真实项目中应补充浏览器范围、访问速度要求或内容准确性口径；责任人也应替换为实际角色名称。直接照抄示例文字而不调整验收口径，评审时仍会出现判断分歧。

把范围示例落到协作工具里的做法

范围说明确认后，需要一种方式让条目、责任人和验收标准在执行过程中保持可查。可以把分解表中的每个子项作为工作项录入项目，把验收标准写进工作项描述或验收字段，责任人对应到具体成员，交付时点对应到计划节点。ONES 支持用「项目计划」创建工作分解结构，按目标、交付物或项目阶段等维度分解计划和工作，并提供从项目到任务的多层级管理，适合承载这类范围条目。

范围条目录入完成后，设置项目计划和里程碑基线，形成范围基线版本。执行过程中实时对比计划与执行的偏差，评审时对照基线逐条判断交付物是否达到验收标准；出现范围调整时，通过对比版本细节追溯变更内容，保留调整前后的记录。ONES 的基线能力支持这一对比与追溯动作。

评审环节可以按交付物组织：责任人提交交付物，评审人对照该条目的验收标准给出结论，结论随工作项留存。这样范围说明、分解表和实际交付记录在同一处对应，后续复盘时能够看到每条范围条目的处理过程。范围变更的审批配置属于变更管理主题，可按团队现有流程在工具中衔接。

常见问题

范围说明里的排除项要写多细，写少了会有什么问题？

排除项写到能让人直接判断“这件事算不算范围内”的程度。示例中写“不包含上线后的内容运营与持续更新”“不包含多语言版本”，读者一看就能对照；如果只写“其他相关工作”，遇到新增需求时仍然要重新讨论。排除项不必穷举所有可能，优先列出本类项目中最容易被默认包含的事项，例如运营、推广、多语言和外部系统对接。

交付物分解到什么层级就该停？再往下拆会怎样？

拆到每个条目能单独判断完成或未完成即可，示例为“交付物—子项”两层。继续往下拆就进入任务拆解，涉及具体页面、人员排期和工时，属于执行计划的内容。范围说明混入任务级条目后，会随执行进度频繁变动，验收时难以作为稳定依据。复杂项目可以增加一层分类，层级仍控制在两到三层。

项目进行中客户提出新增需求，是直接加进范围说明还是走变更？

范围说明确认后形成基线，新增或修改条目应走变更流程，先评估对交付时点和资源的影响，再决定是否更新基线并保留版本记录。直接改范围说明会让基线失去对照作用，后续评审时无法判断哪些内容是原定范围、哪些是后加的。变更审批的具体流程设计属于变更管理主题，可按团队现有流程执行。

探索型项目需求还不明确，这份示例还能用吗？

可以借用字段结构，但填写方式要调整。一次性写死整份范围说明不适合需求边探索边确定的项目，可改为滚动式范围：先写清本轮迭代的目标、交付物和排除项，每轮结束时更新下一轮范围，基线按轮次管理。这样既保留了范围说明的字段，也避免在信息不足时做出无法兑现的承诺。

范围条目录入协作工具后，评审时怎么对照基线判断？

把分解表中的每个子项作为工作项录入，验收标准写进工作项描述或验收字段，责任人对应到成员，交付时点对应计划节点。ONES 支持用「项目计划」按目标、交付物或项目阶段等维度分解计划和工作，并可设置项目计划和里程碑基线，实时对比计划与执行的偏差。评审时对照基线逐条核对交付物是否达到验收标准，出现调整时通过对比版本细节追溯变更内容。