企业官网建设流程全解析

高项 第九/十/十一章项目范围/进度/成本的理解

一、范围管理

需求管理计划：

需求管理计划（完整现实例子，子计划，写流程规则，不写具体功能） 本计划用来规定：本项目全部需求如何收集、记录、跟踪、变更、验证。 收集需求的方法 对接产品、商户、普通用户做访谈；开展需求研讨会；输出交互原型；所有需求必须由干系人正式提出，开发不接收微信口头提需求。 需求如何编写成【需求文件】 每一条需求分配唯一编号 R 开头；区分业务需求、用户需求、非功能需求；每条需求必须写可验证的验收标准，模糊的描述不能进需求文件。 需求跟踪矩阵管理规则 项目启动就建立跟踪矩阵。 跟踪链条：业务需求 → 用户需求 → WBS 工作包 → 可交付成果 → 测试用例。 只要需求变更经过 CCB 批准之后，立刻更新跟踪矩阵，保证双向追溯。没有批准，不许改动矩阵。 需求优先级规则 使用 MoSCoW：必须做、应该做、可以做、暂时不做。迭代优先开发 “必须做” 需求。 需求变更流程 任何新增、修改需求，口头无效，必须提交变更请求，走实施整体变更控制。 CCB 批准后，项目经理更新需求文件、更新需求跟踪矩阵；拒绝私自改需求、私自开发，防止范围蔓延。 需求验证 模块开发完成，产品对照需求文件做确认；所有测试用例必须能够在跟踪矩阵找到对应的需求，不允许出现无来源的测试用例。

需求文件：

业务需求：人事部门希望系统实现员工打卡考勤统计，减少手工统计。 用户需求： R‑001：员工可以在小程序打卡（定位打卡）。 R‑002：人事管理员可以导出月度考勤Excel报表。 R‑003：系统要支持请假申请、审批流程。 非功能需求： 1. 小程序页面响应时间≤2秒。 2. 数据每天自动备份。 验收标准：导出报表可以直接导入Excel，日期、打卡记录无错乱。

需求跟踪矩阵：

问：为什么要做需求优先级排序？

举现实流程 需求管理计划提前写死规则： 使用 MoSCoW 做优先级排序； 由产品经理 + 业务代表共同确定优先级； 每次新增 / 变更需求批准后，必须重新评估优先级； 优先级结果记录在需求文件中。 项目会收集一大堆需求： 用户要优惠券、 商户要对账、 用户要夜间模式、 要分享红包、 要会员体系。 但是工期、钱、人力有限，不可能一次性全部做完。 区分先后，解决资源不够的矛盾 通过优先级，分出：哪些第一期必须做，哪些二期再做。 MoSCoW 例子： ✅必须做 (M)：浏览商家、购物车、微信支付（一期一定要上线） ⭕应该做 (S)：优惠券（一期尽量做，时间不够就挪二期） 🟡可以做 (C)：夜间模式（有空余资源再做） ❌暂不做 (W)：会员体系，本版本放弃，以后再说 迭代 / 版本规划的依据 敏捷、增量项目尤其重要。一期只做高优先级需求，保证核心功能先上线。 出现变更的时候：重新评估优先级 客户新增需求 “拼单功能”。 按照需求管理计划提前定好的规则： 新增需求来了，由产品 + 业务干系人重新评估优先级，再放进迭代。 不是开发想做哪个就做哪个，也不是客户说啥就先做啥。 应对范围蔓延 客户不断加需求，资源不变。 靠优先级做取舍：新增一个高优先级需求，就要把现有某个低优先级需求移出本期版本。（范围平衡）

问：为啥定义范围的输入有风险登记册？

写范围说明书的时候，要把风险考虑进范围边界、假设、约束里面。风险登记册记录已经识别出来的风险，用来辅助定范围。

举例子：开发外卖小程序

风险登记册里面记录几条已识别风险：

1. 风险 R1：第三方支付接口不稳定，对接失败风险。
2. 风险 R2：工期紧张，如果做会员模块，大概率延期。
3. 风险 R3：商户对账功能开发复杂度高，人力不足。

执行【定义范围】，编写项目范围说明书：

1. 看到风险 R2：做会员模块容易延期 →范围说明书就把会员模块排除在本版本范围之外（本版本不做会员），规避该风险。
2. 看到风险 R3：对账复杂度高 → 范围说明书写明：商户对账只做简易版本，完整对账放到二期，降低风险。
3. 看到风险 R1：支付接口存在不稳定风险 → 在范围说明书的假设条件写上：假设第三方支付接口能正常提供服务；一旦接口变更，需要走变更流程。

也就是说：已识别的风险，会影响我们怎么划定项目范围，哪些功能放进范围，哪些排除出去，设置哪些假设约束。所以定义范围要读风险登记册。

范围基准：

范围基准 =项目范围说明书 + WBS + WBS 词典，三者打包在一起，经过批准，只有走变更流程才能修改。

①项目范围说明书：

口诀：产、可、验、除、制、假 产品范围描述：细化产品 / 服务具备什么功能、特性 可交付成果：要交出的全部成果，含产品、文档、报告等辅助成果 验收标准：可交付成果要满足哪些条件才算验收通过 项目的除外责任：明确哪些不做，防止范围蔓延 制约因素：限制项目的条件，如预算、工期、技术约束 假设条件：规划时假定成立的前提（不一定真实）

产品范围描述

开发外卖点餐小程序 V1.0，实现用户浏览商家、购物车、下单支付、订单查询功能。

项目可交付成果

1. 用户端小程序（前端）
2. 后端业务服务接口
3. 部署文档、操作手册

项目除外责任（做什么 / 不做什么）

包含：商家列表、购物车、微信支付、订单查询。

不包含：会员体系、拼单、商户完整对账、夜间模式（放到二期实现）。

假设条件

1. 微信开放平台提供正常支付接口；
2. 业务人员可以按时提供需求确认。

制约因素

总工期 3 个月，预算 28 万。

② WBS（工作分解结构，范围基准第二部分）

分解到可管理的工作包，WBS 分解的是可交付成果，不是活动

1.0 外卖点餐小程序V1.0 1.1 用户端小程序 1.1.1 商家浏览模块 1.1.2 购物车模块 1.1.3 下单&订单查询模块 1.2 后端服务 1.2.1 商家数据接口 1.2.2 订单支付接口 1.3 文档交付物 1.3.1 部署文档 1.3.2 用户操作手册

③ WBS 词典（范围基准第三部分，对每个 WBS 条目详细解释）

WBS 词典写清楚每个工作包内容、负责人、成本时间，避免大家理解不一样。

上面三步骤的过程：

先记住两个核心过程：

定义范围 → 产出范围说明书、WBS、WBS 词典（范围基准）

这个阶段只拆工作包，只定义 “要产出什么东西”，此时还没有精确工期、精确预算。

我上例写的工期、预算，是为举例方便直接填上的，现实中这里只是预留位置，数值来自后面过程。

估算活动持续时间， 估算成本才算工期、算钱。

下面是具体流程顺序：

1）定义范围：拆出 WBS 工作包（只写清楚：这个工作包是做【商家浏览模块】，此时不知道要花多少钱、做几天）

→WBS 词典先占位：写名称、描述、责任人，预算、工期这里是空的。

2）创建 WBS 之后，进入：

​ 定义活动：把每个工作包，再拆成一个个要干的活动。

​ 拆成：页面原型、前端开发、接口联调、单元测试。

3）估算活动持续时间：估算每个活动要几天。

4）估算成本：估算每个活动要花多少钱。

5）制定进度计划 → 得到项目总工期

6）制定预算 → 得到项目总预算 28 万

然后，再回填到 WBS 词典里面：把汇总后的每个工作包的工期、预算填进去。

WBS 词典里面每个工作包的预算、工期，来源是估算成本、估算活动持续时间，不是拍脑袋写的。

7）项目总工期、总预算，写进项目范围说明书的【制约因素】。

范围说明书里的 “总工期 3 个月，预算 28 万”，是制约条件：我们这个项目受限于最多 3 个月、最多花 28 万，是上层给的约束。

二、进度管理

进度管理计划：

项目背景：企业 OA 系统升级项目，总工期 6 个月，2026‑09‑01～2027‑02‑28，总预算 120 万。下面是《进度管理计划》主要章节 + 实例内容。

1. 进度管理方法

1. 采用敏捷 + 瀑布混合模式；需求分析、设计阶段用瀑布；开发迭代采用 2 周一个 Sprint。
2. 工具：Project 编制甘特图，Jira 跟踪任务，每周输出进度报告。
3. 进度网络技术：关键路径法 CPM，识别关键路径，重点管控关键活动。
4. 计量单位：工作日，每日 8 小时，周末节假日不计入。

2. 进度准确度与精度

• 进度估算精度：±10%；
• 汇报精度：周级别，每周五输出进度状态；里程碑到天。

3. 工期估算方法

• 主要使用三点估算，部分成熟模块采用类比估算。

示例：OA 登录模块开发，乐观 8 天，悲观 16 天，最可能 10 天 (t_e=(8+4×10+16)/6 = 10.67)工作日。

4. 进度里程碑（例子）

表格

5. 活动持续时间、资源日历

• 开发人员 5 人，测试 2 人；工作日上班，法定节假日不排班。
• 关键活动不安排节假日加班，确需加班走变更流程。

6. 进度基准

• 将批准后的 WBS 活动、工期、逻辑关系、里程碑、甘特图作为进度基准。
• 只有通过整体变更控制流程审批后，才能修改进度基准；不能直接改计划。

7. 控制临界值（偏差阈值）

用来判断要不要采取纠偏措施

1. 工期偏差：>10%，必须提交进度偏差分析报告；
2. 里程碑滞后：单个里程碑滞后超过 3 个工作日，启动风险处置；
3. 关键路径活动一旦延期，立刻触发干预，不等待阈值。

8. 绩效测量规则

• 使用挣值管理 EVM测量进度绩效：SPI=EV/PV
• SPI＜0.9：进度落后，分析原因，提交纠偏方案；
• SPI＞1.1：评估是否可以适度调整资源，避免后期返工风险。

9. 报告格式

1. 每周进度报告包含：当前 PV/EV/SPI；任务完成情况；滞后任务；风险；下周计划。
2. 里程碑节点输出里程碑专项报告。

10. 进度更新、变更流程

1. 实际进度每周录入 Project；对比进度基准识别偏差。
2. 出现进度偏差：先分析原因（资源不足 / 需求变更 / 技术难点），选择赶工、快速跟进、增加资源等纠偏。
3. 如果纠偏无法挽回工期，提交变更请求，CCB 审批，审批通过更新进度基准

活动清单举例：

收集业务部门需求，编制需求规格说明书，组织需求评审，修改需求文档，编写系统概要设计，概要设计评审，登录模块编码开发，审批流模块编码开发，单元测试，集成测试，系统测试，用户验收测试，系统部署上线

活动属性：

进度基准过程梳理：

定义活动 → 排列活动顺序 → 估算活动持续时间 →制定进度计划

1. 排列活动顺序输出：项目进度网络图只有：活动 + 逻辑关系（FS/FF/SS/SF），没有工期、没有日期，只是一张逻辑图，不能当计划用。
2. 估算活动持续时间输出：持续时间估算只有每个活动大概要干几天，没有开始结束日期，没有资源，没有整体时间表，只是一堆孤立的工期数字。

网络图知道谁先谁后；持续时间知道每个活干多久；但是：不知道几号开始、几号结束、总工期多久。

制定进度计划：把前面所有输入揉在一起算时间

输入包括： 活动清单、活动属性、项目进度网络图、持续时间估算、资源日历、风险登记册、假设条件等等。

用工具：关键路径、资源平衡、假设情景分析、赶工、快速跟进。 经过反复演算、调整、优化，出来两个东西：

① 项目进度计划（进度模型）

包含：各活动开始 / 结束日期、甘特图、里程碑、关键路径、总工期。

这是草稿版本、可修改的工作版本，还没审批。

② 进度基准

项目进度计划，经过 CCB 审批批准之后，就成为进度基准。

• 基准：用来做对比测量的标尺，正常情况不能随便改，变更必须走整体变更控制。
• 实际执行时：拿「实际进度」和「进度基准」对比，算 SPI、判断偏差。

进度基准举例：
**

基准里的里程碑（内嵌在进度基准）M1 需求规格说明书评审确认：2026‑09‑19 M2 概要设计评审完成：2026‑10‑14 M3 开发工作全部完成：2026‑11‑04 M4 系统测试完成：2026‑12‑12 M5 系统上线验收交付：2026‑12‑31

三、成本管理

规划成本管理输出：成本管理计划：

### 1. 计量单位 - 货币单位：人民币万元；人力按人天统计。 ### 2. 精确度、准确度 - 估算精确度：保留 2 位小数； - 估算准确度：±10%，项目早期允许 ±15%。 ### 3. 控制临界值（偏差阈值） - 成本偏差 CV，成本绩效指数 CPI 作为监控指标； - **CPI＜0.9**，或成本偏差超过总预算 10%，必须提交成本偏差分析报告； - 单个里程碑成本超支＞8%，启动审查。 ### 4. 绩效测量规则（挣值 EVM 规则） 1. 采用挣值管理 EVM 开展成本绩效测量； 2. PV、EV、AC 按周统计； 3. EV 测量规则：活动 100% 完成计全部 EV；部分完成按完成百分比计算 EV； 4. 管理储备：**8 万元**，用于应对未知未知风险，不经审批不得动用； 5. 应急储备：**10 万元**，应对已知未知风险，项目经理可在授权范围内使用。 > > 总预算 = 项目成本基准 + 管理储备 > 成本基准 = 各活动估算 + 应急储备 = 112 万；总预算 = 112+8=120 万 ### 5. 估算方法 - 主要采用**参数估算、三点估算**；历史模块使用类比估算。 ### 6. 报告格式 - 每周项目报告包含 AC、PV、EV、CPI、CV，成本超支 / 节约原因分析； - 每个里程碑输出专项成本报告。 ### 7. 成本更新与变更流程 1. 定期更新项目成本计划，对比成本基准识别偏差； 2. 出现成本偏差，优先分析原因，采取控制措施（削减范围、优化资源、替换方案等）； 3. 若需要修改**成本基准**，必须提交变更请求，CCB 审批通过后更新成本基准； 4. 管理储备动用：提交申请，高层审批，批准后才纳入成本基准。 ### 8. 资金筹措 资金按阶段拨付：需求阶段拨付 25%，开发阶段拨付 45%，测试上线拨付 30%。 ### 9. 审批权限 - 单次支出≤5 万：项目经理审批； - 单次支出＞5 万：上报公司财务 + 项目发起人审批。

估算成本输出：成本估算、估算依据

成本估算：

成本估算：收集业务部门需求 4.20 万，编制需求规格说明书 2.80 万，组织需求评审 1.50 万，修改需求文档 2.10 万，编写系统概要设计 5.00 万，概要设计评审 1.80 万，登录模块编码开发 8.60 万，审批流模块编码开发 10.20 万，单元测试 4.50 万，集成测试 5.80 万，系统测试 6.30 万，用户验收测试 3.20 万，系统部署上线 4.00 万，成本合计：60 万，应急储备 10.00 万，项目总估算 70.00 万元。

估算依据：

含义：成本估算的支持细节，说明这个数是怎么算出来的，文档化，用来追溯。

估算依据包含内容（实例）

1. 估算使用的方法：部分活动类比估算；开发模块采用三点估算；人力成本采用参数估算（人天 × 人力单价）。
2. 估算的假设条件：团队人员稳定；外部服务器租赁价格不变；没有重大需求变更；工作日按 8 小时计。
3. 估算的约束条件：项目不能超公司内部人力单价标准；部分工作不允许外包；预算上限约束。
4. 估算的资源依据：人员数量、人天、物料、服务器、外包费用；人力单价：开发 1200 元 / 人天，测试 900 元 / 人天。
5. 估算的置信区间 / 误差范围：本项目成本估算准确度 ±10%。
6. 应急储备计算说明：基于风险登记册识别的已知‑未知风险，按活动总成本约 16.7% 计提应急储备 10 万元。
7. 哪些部分做了估算，哪些没有估算：本估算不含管理储备，管理储备在预算阶段单独设置。

成本预算输出：成本基准、项目资金需求

成本基准：

项目资金需求：

检查点 2026‑09 月底： 成本基准计划到 9 月底预算 PV=12 万；实际 AC=13.5 万；EV=10 万。 CPI=EV/AC=10/13.5≈0.74，成本超支。

1. 拿实际 AC 和成本基准做对比，分析偏差；
2. 可以调整方案、优化资源，但不能直接修改成本基准；
3. 如果确实需要上调成本基准，提交变更请求，CCB 审批通过后更新成本基准。
4. 如果遇到特大未知未知风险，需要动用 8 万管理储备：提交高层审批，批准后，把对应金额划入成本基准，同时更新项目资金需求。