CORNELL · SYSEN 5930 · FALL 2023
一个配送构想，怎样成为项目计划？
Bon Appétit 课程项目提出新的食品与杂货配送方式。我参与团队项目管理计划，并负责成本管理章节：范围、预算与进展，必须放在一起看。
- 原作
- Team 8 · Bon Appétit
- 个人章节
- Part 5 · 成本管理计划
- 本页实验
- 2026 年新编 · 虚构数值
团队构想 / 配送与附近自提
把配送和附近自提，接成一条服务流程。
团队提案把食品与杂货送到社区附近的固定投递点，再由顾客短距离自提，希望借此改善配送路线，并减少交付过程中的丢失风险。无人机或无人车配送被列为可能的扩展方向。
这是一份课程中的服务与产品规划。团队的管理材料涉及人力费率、任务时间、分期预算和计划基线；这些部分也为我写成本管理章节提供了依据。
个人章节 / 从预算与范围的关系开始
先问预算够不够支撑这件事。
原作 Part 5 将成本管理计划列为我负责的章节。我先提出：如果方案同时包含软件优化、投递设施与潜在的无人配送，原设预算是否覆盖得了这些工作？随后，我明确引入一个假设的扩展预算，继续安排不同阶段的费用。
- 01
先看范围
固定投递点、社区自提与无人配送，分别需要哪些工作和资源？如果这些都进入项目，预算要覆盖到哪里？
- 02
再列假设
我在成本章节里指出原预算与规划范围不匹配，并明确采用一个假设的扩展预算，继续讨论设计、开发和原型阶段的费用。
- 03
把偏差带回讨论
计划完成多少、实际完成多少、已经支出多少，需要放在同一报告时点比较，再找出应该继续调查的工作。
当时的章节把成本偏差、进度偏差和挣值指标纳入监控，也提出双周报告与季度复核的节奏。数值、阈值与预算扩展都属于课程假设；现在回看，我更想保留的是先核对范围，再解释数字的习惯。
从原作到实验 / 先把三个数分清
少花钱，和按计划完成工作，是两回事。
挣值管理（EVM）把已经完成的工作，按原先确定的预算价值计量，再与同期计划和实际成本比较。这样，即使支出低于原计划，也能继续追问：是做得更省，还是该完成的工作还没做完？
下方保留这个比较方法，用新的虚构数值演示。计划值 PV、挣值 EV 与实际成本 AC，都对应同一个报告时点；图形展示的是一张快照。
动手比较 / 2026 年方法演示
花了多少，完成多少，原本该完成多少？
以下为新编的虚构情境：总预算统一为 100 点，比较同一报告时点的累计数值。EV 按事先确定的工作预算权重计量；它表示已完成工作的预算价值。
先看看：哪些工作落后于计划？
同期计划完成 60 点，实际完成 30 点预算价值的工作，支出 25 点。
预算价值需要有可靠的完成记录支撑；这些比值也不能直接换算成提前或落后多少天。
- 成本偏差 CV
- 5
- 进度偏差 SV
- -30
- 成本绩效指数 CPI
- 1.20
- 进度绩效指数 SPI
- 0.50
EV − AC完成这些工作，对照预算价值是节约还是超支。
EV − PV按预算价值比较完成量与计划量，单位不是天。
EV ÷ AC每花费 1 点，完成了多少点预算价值的工作。
EV ÷ PV完成工作的预算价值，占同期计划的比例。
CV、SV：正值为有利，负值为不利。CPI、SPI：大于 1 为有利，小于 1 为不利；分母为 0 时显示“—”，表示无法计算。
演示只比较当前快照；实际成本允许超过总预算。它不预测完工日期或最终成本。 公式与术语：NSF EVM Gold Card（英文，新标签页） ↗
DECISION THEATRE / 02 · 交付前的顺序
快了两天，真的能早两天交付吗？
把一个服务构想拆成七项工作，再看看它们怎样相互等待。先改自提点或界面的工期，观察哪条链开始决定最后的交付时间。
2026 年独立编写的虚构练习；不是 Bon Appétit 原作的排期。时间从第 0 天起算，只考虑完成后才能开始的依赖关系，暂不限制人员与设备。
准备服务界面
产品与实施 · 先完成：确认范围与验收条件
最早第 2 天开始，第 7 天完成。总时差为 0 天。
总时差是这项工作在不推迟当前项目完成时点的前提下，可向后移动的余地。相连工作的余量不能简单相加。
自己修改七项工期
| 工作 | 前置工作 | 工期 | 最早开始 | 最早完成 | 最迟开始 | 最迟完成 | 总时差 |
|---|---|---|---|---|---|---|---|
| 确认范围与验收条件scope | — | 2 | 0 | 2 | 0 | 2 | 0 |
| 准备服务界面interface | scope | 5 | 2 | 7 | 2 | 7 | 0 |
| 准备自提点site | scope | 3 | 2 | 5 | 4 | 7 | 2 |
| 编写操作说明brief | scope | 4 | 2 | 6 | 5 | 9 | 3 |
| 联合验收测试test | interface / site | 2 | 7 | 9 | 7 | 9 | 0 |
| 演练交接流程rehearse | test / brief | 2 | 9 | 11 | 9 | 11 | 0 |
| 确认交付release | rehearse | 1 | 11 | 12 | 11 | 12 | 0 |
计算方法与交接前的三个问题
关键路径法（CPM）：先顺推最早开始与完成，再从项目结束时点倒推最迟开始与完成；总时差 = 最迟开始 − 最早开始。
- 缩短的是决定交付时间的工作，还是原本就有余量的工作？
- 两项工作虽然没有依赖，是否仍要争用同一位同事或设备？
- 验收过了之后，接手的人是否知道失败时由谁处理？
KEEP THE CALL / 给判断留一个版本
把当时的设置和理由，一起留下。
保存上方已经应用的七项工期。人数与排入顺序，可在下方资源排班实验中另存一版；输入框里尚未应用的改动不包含在内。
从本机恢复同类设置（0）
载入会替换本页当前设置与未应用输入，原日志仍保留。
还没有这类记录。
RESOURCE LAB / 同一份计划，加上人手限制
工作可以并行，做事的人呢？
沿用上方已应用的七项工期，每项工作需要一个小组全程投入。小组可以互换，工作开始后不中断。先看看人手是否改变交付时间，再试着调整排入顺序。
当前安排比依赖关系给出的下界晚 0 天。只调整排入顺序，本模型还能缩短 0 天。
先为哪项工作预留时段？
用上移、下移调整；前置工作必须保留在前。这里决定的是排入计划的顺序，不是要求所有工作依次开工。
- 01确认范围与验收条件
- 02准备服务界面
- 03准备自提点
- 04编写操作说明
- 05联合验收测试
- 06演练交接流程
- 07确认交付
时段占用与等待
实线是工作时段，虚线是前置工作完成后、仍需等待人手的时间。每行都可以对照下方完整数据。
自第 0 天起，每格一天，格内数字为在用小组数，上限 2。
| 工作 | 工期 | 前置完成 | 实际开始 | 实际完成 | 等待人手 |
|---|---|---|---|---|---|
| 确认范围与验收条件 | 2 | 0 | 0 | 2 | 0 |
| 准备服务界面 | 5 | 2 | 2 | 7 | 0 |
| 准备自提点 | 3 | 2 | 2 | 5 | 0 |
| 编写操作说明 | 4 | 2 | 5 | 9 | 3 |
| 联合验收测试 | 2 | 7 | 7 | 9 | 0 |
| 演练交接流程 | 2 | 9 | 9 | 11 | 0 |
| 确认交付 | 1 | 11 | 11 | 12 | 0 |
怎样找到这份最短安排？
程序遍历 8 种满足前置关系的排入顺序。每次按顺序，为工作找到前置完成后、人数允许的最早连续时段，再比较全部安排的交付时点。最短工期有 4 种排入顺序达到；它们不一定是不同的排班表。
这是七项工作的小规模穷举：工期确定、按整天计、无停工与休假，每项工作只需要一个技能相同的小组。真实项目中的技能差异、交接成本和不确定性，需要另行建模。
方法阅读：排期生成方法研究（英文，新标签页） ↗KEEP THE CALL / 给判断留一个版本
把当时的设置和理由，一起留下。
只在你点击保存时记下一版已应用的设置。输入框里尚未应用的改动不包含在内，后续可从本机日志恢复或对照。
从本机恢复同类设置（0）
载入会替换本页当前设置与未应用输入，原日志仍保留。
还没有这类记录。
2026 年复盘 / 把数字接回具体工作
发现偏差之后，再问谁来处理。
现在读这份计划，我会把指标与工作分解放在一起：哪部分交付落后，原因是什么，谁需要补充信息，什么时候再检查？这些问题也出现在 CUSD 的跨团队协调，以及我后来对需求与验收的整理中。
读完之后 / 接着聊
你会怎样看？
欢迎补充经历、提出问题，或指出需要勘误的地方。中英文页面共用这一篇的讨论。
评论服务尚未开放。可以先写下想法，暂存在本机，或通过联系页发给我。
写一份本机草稿
点击“暂存本机”才会保存。共用设备上请在离开前清除；草稿不会自动发布。
0 / 1600