项目启动会开得好不好，半年后就看得出来：范围清楚的团队在稳步推进，没讲清的团队在反复讨论"这个到底在不在范围内"。
一、目标：用一个可判定的说法
"提升效率""优化体验"都不是目标，因为无法判定是否达成。目标应该写成可观测的状态，例如"订单处理从人工录入改为系统同步，单笔处理时间由 10 分钟降到 2 分钟以内"。
二、范围：明确写出"不做什么"
- 本期做哪些模块、覆盖哪些角色
- 本期明确不做哪些——这条比上一条更重要
- 与现有系统的边界：谁改、谁不改
排除项要签字确认
把本期不做的事项逐条列出并双方确认。后期出现"顺手加一个"时，这份清单就是最好的沟通依据。
三、角色与决策机制
| 角色 | 职责 | 关键约定 |
|---|---|---|
| 项目负责人 | 整体推进与决策 | 需求争议的最终裁定人 |
| 业务负责人 | 需求确认与验收 | 确认时限（如 2 个工作日内） |
| 技术负责人 | 方案与实施 | 技术方案的评估与说明 |
| 对接人 | 日常沟通与资料提供 | 双方各指定一人，避免多头指挥 |
四、里程碑与验收标准
- 把项目拆成 3–6 个里程碑，每个有明确交付物与时间
- 每个里程碑配套验收标准：做什么、怎么测、谁确认
- 明确验收不通过时的处理机制（整改后复验）
五、沟通机制
约定例会频率、沟通渠道、问题升级路径、文档存放位置。这些看起来琐碎，但它们决定了项目进行到一半时，双方是"随时能对齐"还是"每次都对不齐"。启动会多花两小时，能省下后期几十小时的对齐成本。
#项目启动#范围界定#验收标准#软件事业部
