05-项目立项与整体规划：范围、工期、资源、风险、里程碑制定
05-项目立项与整体规划：范围、工期、资源、风险、里程碑制定
系列上一篇我们聊了研发流程的整体框架，这篇进入实战第一弹——项目立项与整体规划。
立项这一步如果做得糙，后面全是在还债。本文带你把范围、工期、资源、风险、里程碑一次性理清楚。
一、项目立项：别上来就写代码
很多小微企业的问题不是技术不行，是没立项就开干。客户说"做个智慧农业大棚监控平台"，老板说"行，下周出"，开发说"行，开写"——三个月后发现做出来的东西跟客户想的完全不是一回事。
立项的核心目的就三个：
- 搞清楚到底要做什么（范围）
- 搞清楚值不值得做（可行性）
- 搞清楚能不能按时按量做完（资源与工期）
1.1 立项文档三件套
CMMI3要求立项至少产出以下文档，小微企业的做法是精简但不省略：
| 文档 | 核心内容 | 篇幅建议 |
|---|---|---|
| 立项申请表 | 项目名称、背景、目标、预估预算、预估周期、项目经理 | 1-2页 |
| 可行性分析报告 | 技术可行性、市场可行性、经济可行性、风险初判 | 3-5页 |
| 立项评审记录 | 评审人、评审意见、结论（通过/不通过/整改后通过） | 1页 |
小技巧：立项申请表可以用一个标准模板，每个项目填空式完成，10分钟搞定。可行性分析才是重点。
1.2 可行性分析怎么做
以"无人售货柜AI视觉识别系统"为例，可行性分析至少覆盖以下维度：
- 技术可行性：YOLOv8模型在RK3588工控板上的推理速度能否达到200ms以内？重力传感器数据采集精度够不够？——这些得有预研结论或POC验证。
- 经济可行性：硬件成本（工控板+摄像头+锁控板）控制在800元/柜以内，软件分摊成本按1000台规模化后可低至50元/台。
- 市场可行性：目标客户是谁？竞品有哪些？我们的差异化在哪？
- 风险初判：AI识别准确率不达标怎么办？供应链断货怎么办？
1.3 立项评审
评审不是走过场。小微企业建议组成3人评审小组（技术负责人+产品负责人+项目经理），重点审查：
- 项目目标是否SMART（具体、可衡量、可达成、相关、有时限）
- 资源是否到位
- 风险是否有应对预案
评审通过后，项目经理正式获得"尚方宝剑"，可以启动规划工作。
二、范围管理：画好圈再干活
2.1 范围说明书
范围说明书是项目的"宪法"，核心包含：
- 项目范围：项目要交付的产品/服务和要完成的工作
- 验收标准：怎样才算"做完了"
- 除外条款：明确什么不做（这条很重要，防止范围蔓延）
- 约束条件：预算上限、工期上限、技术栈限制等
- 假设条件：假设客户会在某日期前提供测试环境等
举个例子，无人售货柜项目的除外条款可以写明：
本期不包含：支付系统开发（复用第三方）、后台运营管理系统（二期）、柜体硬件设计（甲方提供）。
这一行字能帮你挡掉无数个"顺便帮我加个XX功能"的需求。
2.2 WBS前置工作
在正式做WBS之前，先做范围分解的前置工作：
- 把范围说明书中的可交付成果列出来
- 对每个可交付成果，初步划分到子系统/模块级别
- 这一步产出的不是最终WBS，而是WBS的"骨架"
详细WBS拆解我们放在第6篇专门讲，这里先不展开。
2.3 范围基线
范围基线 = 范围说明书 + WBS + WBS字典。基线一旦建立，任何变更都必须走变更控制流程（第8篇详述）。
通俗理解：基线就是"拍照存档"，以后每次改需求都得跟这张照片对比，变了什么、为什么变、影响多大，都得说清楚。
三、工期估算：别拍脑袋
3.1 三种常用估算方法
| 方法 | 原理 | 适用场景 | 精度 |
|---|---|---|---|
| 类比估算 | 参考历史类似项目的实际工期 | 有类似项目经验时 | 低，±30% |
| 参数估算 | 用历史数据算单位工作量×数量 | 有成熟参数模型时 | 中，±20% |
| 三点估算 | 乐观(O)+悲观§+最可能(M)加权 | 任务不确定性高时 | 较高，±15% |
三点估算的公式（PERT法）：
预期工期 = (O + 4×M + P) / 6举个例子：开发一个"商品识别API"接口，乐观估计2天，最可能4天，悲观估计10天：
预期工期 = (2 + 4×4 + 10) / 6 = 28/6 ≈ 4.67天3.2 估算的常见坑
- 只估开发不算测试：测试至少占开发工时的30%-50%
- 不算联调时间：微服务间的联调往往比开发本身还耗时
- 不算部署调试：工控板上的部署调试，在嵌入式项目中能吃掉15%工期
- 不留缓冲：整体工期建议加10%-15%的管理缓冲
四、资源规划：人、机、云全都要算
4.1 人力资源
按角色列出所需人力及投入比例：
| 角色 | 人数 | 投入比例 | 备注 |
|---|---|---|---|
| 项目经理 | 1 | 30% | 兼管其他项目 |
| 后端开发 | 2 | 80% | Java微服务 |
| 前端/小程序 | 1 | 100% | |
| 安卓工控 | 1 | 80% | RK3588开发 |
| AI算法 | 1 | 50% | YOLO模型训练+部署 |
| 测试 | 1 | 60% | 后期投入加大 |
4.2 硬件资源
- 工控板：RK3588开发板×3台（开发1台、测试1台、备件1台）
- 摄像头：RGB双目摄像头×5个
- 测试柜体：2台（含锁控板、重力传感器）
- STM32调试器：ST-Link×2
4.3 云资源
- 开发环境：4核8G×2台（微服务各一个）
- 测试环境：8核16G×1台 + MySQL/Redis/Nacos
- AI训练：按需租用GPU云服务器（T4/A10），训练完即释放
- 对象存储：OSS/MinIO，用于商品图片库和模型文件
4.4 测试设备
- 网络测试：弱网模拟工具
- 硬件测试：万用表、示波器（嵌入式调试必备）
- 自动化测试：Postman/JMeter做接口测试
五、风险初筛与识别
5.1 风险识别方法
最实用的是检查表法+头脑风暴法组合：
- 拿历史项目的风险检查表过一遍
- 团队头脑风暴补充项目特有风险
5.2 风险登记册模板
| 编号 | 风险描述 | 类别 | 概率 | 影响 | 风险值 | 应对策略 | 责任人 |
|---|---|---|---|---|---|---|---|
| R01 | YOLO模型在弱光下识别率低于90% | 技术 | 中 | 高 | 高 | 预研弱光数据增强方案 | 算法工程师 |
| R02 | RK3588供货周期延长 | 供应链 | 中 | 高 | 高 | 备选RK3566方案 | 硬件采购 |
| R03 | 客户需求频繁变更 | 需求 | 高 | 中 | 高 | 严格变更控制流程 | 项目经理 |
| R04 | 微服务联调工期超预期 | 进度 | 中 | 中 | 中 | 预留15%缓冲 | 项目经理 |
风险值 = 概率 × 影响。高、中、低分别对应3、2、1分，风险值≥6的需要重点跟踪。
5.3 风险应对四种策略
- 规避：改变计划消除风险（如换掉不稳定的供应商）
- 转移：外包给第三方承担（如把AI训练外包给专业团队）
- 减轻：降低概率或影响（如增加测试覆盖度）
- 接受：已知风险但选择不行动（如小额成本风险可直接接受）
六、里程碑计划表
里程碑是项目进度中的关键检查点，不是每个任务都是里程碑。好里程碑的特征：可验证、有交付物、有明确日期。
示例：无人售货柜项目里程碑
| 里程碑 | 目标日期 | 交付物 | 验收标准 |
|---|---|---|---|
| M1-需求基线 | 第2周末 | 需求规格说明书 | 评审通过，客户签字 |
| M2-设计基线 | 第4周末 | 架构设计+详细设计 | 评审通过 |
| M3-Alpha版本 | 第8周末 | 核心功能可演示 | 主流程跑通 |
| M4-Beta版本 | 第11周末 | 全功能+测试报告 | 缺陷率<5个/千行 |
| M5-试产部署 | 第13周末 | 10台试点部署 | 现场运行7天无P0级故障 |
| M6-验收交付 | 第14周末 | 全套文档+源码+部署 | 客户验收签字 |
里程碑的三个作用
- 进度锚点：让团队和客户知道"现在到哪了"
- 决策关口：每个里程碑都是Go/No-Go决策点
- 风险检查点：里程碑偏差超过10%必须重新规划
小结
立项与整体规划是项目的地基。小微企业资源有限，更要把这一步做扎实——不是写一堆文档走形式，而是真正把范围、工期、资源、风险想清楚。
核心要点回顾：
- 立项三件套：申请表+可行性分析+评审记录，精简但不省略
- 范围管理：范围说明书要写清楚"不做什么"
- 工期估算：三点估算法比拍脑袋靠谱，记得算测试和联调
- 资源规划：人、硬件、云、测试设备四类资源全都要列
- 风险管理：建风险登记册，高值风险重点跟踪
- 里程碑：少而精，每个都有可验证的交付物