旗舰方法论 · 七关系列 本文是系列第一篇，深挖"立项关"
做了近八年量产交付，我发现很多人对"立项"有个普遍的误会：以为立项就是产品经理写个需求文档，然后研发开始干活。立项这个动作，发生在这之前。它是项目从"老板脑子里的一个念头"变成"公司账上的一笔预算、一份合同、一个被所有人认可的目标"的过程。没有立项，后面的一切都名不正言不顺。本文要点
⭐立项 = 项目"出生证"：内部立项 → 评审锁范围 → 预算 → kickoff → 合同/协议，五步少一环都不行
⭐最大的坑是边界没钉死：需求宽，研发就慌；研发慌，排期就炸
⭐我的做法：先列"不做什么"，再谈"要做什么"
⭐立项关是地基：地基歪了，上面盖得再漂亮也要塌
立项到底在办什么手续？
拉通我跑过的真实项目，立项不是一道手续，而是一串动作。它要办的五件事，少一环都不行：- 内部立项，拿项目代号——别小看代号，它是这个项目往后一年里在无数会议、邮件、系统里被提起的"名字"；
- kickoff 会——把相关方叫到一个屋里，正式宣布"我们开始了"；
- 合同与技术协议确认——把甲乙双方（或内部需求方与交付方）的权责白纸黑字写下来，时候如有扯皮或者发生变更时，你会感谢它。
▲ 立项五步：内部立项拿代号 → 评审会锁范围 → 预算申请 → kickoff → 合同与技术协议这套流程走完，项目才算真正"出生"。缺任何一环，后面都会以某种方式找补回来——通常是以你最不想看到的方式。最大的坑：边界没钉死
踩过最痛的坑，往往出现在立项评审会上。
那次需求只有一句话："我们要增加xx设备来实现xx功能。"听起来很清晰，对吧？可真做起来，问题一个接一个：覆盖哪些场景？硬件用谁的？交付到什么程度算完？评审会上大家都说"先做着看"，没人愿意把"不做什么"写进文档。▲ 需求不清，范围就会像这团雾一样四处外溢结果呢？研发方向飘，排期一改再改，到最后连"做到哪算交付"都说不清。那一轮，排期前后改了四五版，光"到底交付啥"就拉扯了大半个月。需求宽，研发就慌；研发慌，排期就炸。
我现在怎么立项
吃一堑，现在我的立项第一个动作，不是列"要做什么"，而是拉着硬件、软件、测试三方，把"不做什么"先列出来。▲ 范围管理像天平：先砌住"不做什么"的墙，剩下的"要做什么"才稳范围管理，从来不是满足需求，是管住需求。把边界钉死，研发才有安全感，排期才压得住。这比一份漂亮的 PRD 值钱得多。写在最后
立项关是七关里最容易被轻视的一关——因为它看起来"没有技术含量"。但它是整个项目的地基。▲ 立项就是地基：地基歪了，上面盖得再漂亮也要塌地基歪了，上面盖得再漂亮也要塌。
下一关，我们聊方案设计：硬件架构、软件架构那些看起来很技术、实则埋雷最多的决定，是怎么在方案阶段悄悄定下的。▲ 七关地图：第一关"立项"已走完，下一站"方案设计"
- END -
做了近八年自动驾驶量产交付，这个号只写一件事：把"一个功能从立项扛到量产"的真问题，写成你能用的笔记。不追热点，只写真问题。如果这篇对你有点用，点个【关注】。后面我把近八年攒下的交付实战，一篇篇写给你看——咱们，慢慢聊。
