4、项目启动与计划：项目立项流程、项目计划制定（V模型）、资源估算与时间表、风险管理计划

4.1 项目立项：不是拍脑袋，是拍桌子

项目立项，说白了就是决定「干不干」和「怎么干」。很多团队一上来就写代码，结果做到一半发现需求没对齐，资源不够用，最后延期背锅。我见过最惨的一个项目，立项时连客户到底要A-SPICE几级都没搞清楚，做到一半被审计直接叫停。

我个人习惯，立项阶段必须完成三件事：

• 明确项目目标：是过A-SPICE二级？还是三级？客户有没有强制要求？
• 确认范围边界：哪些功能做，哪些不做。别什么都往里塞。
• 识别关键干系人：客户、项目经理、系统工程师、测试负责人，一个都不能少。

4.2 项目计划制定：V模型不是画着玩的

V模型是ASPICE的骨架。你想想看，从需求到代码，再从代码回到验证，每一步都要有对应关系。我刚开始做ASPICE时，觉得V模型就是个形式，后来被审计老师问住：「你的系统需求对应的测试用例在哪？」——嗯，从那以后我再也不敢轻视V模型了。

一个标准的V模型计划，至少包含以下阶段：

4.3 资源估算与时间表：别太乐观，也别太悲观

资源估算，说白了就是算清楚「需要多少人、多少时间、多少钱」。我见过最离谱的估算，项目经理拍脑袋说「这个功能两周搞定」，结果开发干了两个月。为什么会这样？因为没考虑需求变更、技术难点、人员请假这些隐性成本。

我个人习惯用三种方法做估算：

• 类比估算：参考历史项目的数据。比如之前一个类似模块用了4周，这次也差不多。
• 参数估算：按代码行数或功能点数算。比如每1000行代码需要2人周。
• 三点估算：最乐观、最可能、最悲观，取加权平均。公式是 (乐观 + 4×可能 + 悲观) / 6。

时间表方面，我建议用甘特图来展示。每个阶段要有明确的里程碑，比如「需求评审通过」「架构设计冻结」「代码提测」。里程碑之间要有依赖关系，别让一个环节卡住整个项目。

4.4 风险管理计划：不是写文档，是保命

风险管理，很多人觉得就是写个文档应付审计。其实不然。你想想看，项目最大的风险是什么？不是技术难题，而是「没人知道风险在哪」。我做过一个项目，直到集成测试才发现某个芯片的驱动不兼容，结果整个架构要重改。如果早期做了风险识别，完全可以避免。

一个实用的风险管理计划，包含以下步骤：

1. 风险识别：列出所有可能的风险。比如人员离职、需求变更、技术选型失误、供应商延期。
2. 风险评估：给每个风险打分。概率×影响，分数高的优先处理。
3. 风险应对：制定应对措施。比如「核心模块安排两个人交叉备份」「关键芯片备选两个供应商」。
4. 风险监控：定期检查风险状态。我习惯每周例会花5分钟过一遍风险清单。

举个例子，一个典型的风险条目长这样：

最后说一句，风险管理不是一次性的。项目启动时做一次，每个里程碑再回顾一次。我见过很多团队，启动时写了厚厚一本风险计划，后面再也没看过。那还不如不写。

嗯，项目启动与计划这部分，说白了就是打好地基。地基不稳，后面盖的楼再漂亮也是危房。下一章我们聊聊需求工程，那才是真正开始「盖楼」的地方。