软件项目开发全流程 · 第 2 课 · 立项：为什么做、值不值得做
1、立项不是"走流程"，是"先花小钱省大钱"
上一课说，项目最贵的失败是"做了没人要的东西"。立项阶段的唯一使命，就是在花大钱之前，先用小钱判断这件事该不该做。
打个比方：立项就像造房子前的看地和勘探。勘察花几万块，能避免你把楼盖在滑坡上、白扔几千万。软件开发里，立项花的是几天到几周，能避免的是几个月到几年的浪费。
所以立项的核心不是"写一份好看的 PPT"，而是回答四个问题：
- 为什么要做？（问题/机会是什么）
- 做成什么样算成功？（目标与衡量标准）
- 做得到吗？（可行性）
- 值不值得？（收益 vs 成本/风险）
注意顺序：先问"为什么"，再问"怎么做"。 颠倒过来，团队就会一头扎进技术方案，忘了出发的目的。
2、先分清三类"要做"
不是所有"老板说要"都该直接开工。接到需求，先给它归个类：
| 类型 | 本质 | 判断重点 |
|---|---|---|
| 问题驱动 | 现在有痛苦，要消除 | 痛点有多痛？不解决的损失多大？ |
| 机会驱动 | 看到了能赚钱/省钱的窗口 | 窗口期多长？投入产出比多少？ |
| 合规/被迫驱动 | 法规、安全、依赖逼你必须做 | 截止时间？不做有什么后果？ |
三类都要做，但评估方式不同：问题驱动看"止痛效果"，机会驱动看"ROI"，被迫驱动看"合规底线"。
最常见的坑是把机会驱动当成问题驱动——"隔壁做了我们也要做"，结果做了个没人用的功能。立项时一定要追问：这是我们真需要，还是别人有所以我们焦虑？
3、商业论证：值不值得做的算盘
商业论证（Business Case）就是一页纸的"值不值"说明书。它至少要写清：
- 现状与痛点：现在的问题是什么，影响谁，影响多大（最好有数字）。
- 目标与收益：做完之后，能带来什么可衡量的改变。
- 成本估算：人力、时间、软硬件、机会成本。
- 风险与假设：可能翻车的地方，以及你依赖的前提。
- 不做会怎样：这是最容易被忽略、却最能帮决策的一栏。
收益要尽量量化。比较两句话：
- ❌ "能提升用户体验。" —— 无法衡量，也无法验证。
- ✅ "把下单流程从 7 步减到 3 步，预计把支付转化率从 62% 提到 70%，按日均 1 万单算，每月多约 X 万元营收。" —— 可衡量、可验证。
量化的好处不是显得专业，而是做完之后你能诚实地说"我到底有没有做对"。
4、ROI 与机会成本：别只算花出去的钱
ROI（投资回报率） 的直觉公式：
ROI = （收益 − 成本） / 成本但软件项目的收益和成本都很难算准，所以更重要的是养成"对比思维"：同一个团队、同一段时间，做 A 就不能做 B。 这就是机会成本。
举例：你的团队这个季度只能做一件事，候选是：
- A：加一个"导出 PDF"功能，预计带来 2 万元收入。
- B：优化注册流程，预计带来 8 万元收入。
- C：还技术债，不直接赚钱，但能让后面每个季度提速 20%。
如果只看 A，它 ROI 是正的，好像能做。但排在一起看，A 的机会成本就是"放弃了 8 万元"。立项的作用，就是逼你把所有候选放到同一张桌子上比。
小技巧：给每个候选写一句"如果我们不做这个，世界会怎样？" 答不上来的，优先级就该往下压。
5、可行性分析：四个维度，任何一票否决都要慎重
就算值得做，也未必做得到。可行性通常从四个维度查：
| 维度 | 要问的问题 | 翻车信号 |
|---|---|---|
| 技术可行性 | 现有技术/团队能力能否实现？要突破的核心难点是什么？ | 关键难点没有原型验证，只是"应该能行" |
| 经济可行性 | 成本能否承担？收益模型站得住吗？ | 只有乐观估算，没有悲观情形 |
| 进度可行性 | 截止时间现实吗？有没有硬性外部期限？ | "三个月上线"却没算联调、测试、合规时间 |
| 法律/合规可行性 | 数据、隐私、许可证、行业监管允许吗？ | 用了 GPL 代码却打算闭源商用 |
四个维度里任何一个"明显不成立"，都应该先停下来，而不是"先做起来再说"。因为深入之后的返工成本是指数级的。
技术可行性里最值得投入的一件事：做一个最小原型（Spike）去验证那个最不确定的难点。 花两天写个 demo，比在会上争论两周有用得多。
6、一页纸立项提案模板
别写长篇大论。真实场景里，能被认真读完的立项材料往往就一页。推荐结构：
# 立项提案：<项目名>
## 一句话说明
<用一句话说清：给谁、解决什么问题、带来什么价值>
## 为什么要做（问题/机会）
- 现状痛点：
- 影响范围（人数/金额/频次）：
- 不做会怎样：
## 目标与成功标准
- 目标：
- 可衡量指标（如：转化率 62% → 70%）：
## 方案概要
- 做什么：
- 不做什么（明确边界）：
## 成本与资源
- 人力/时间/预算：
- 关键依赖：
## 风险与假设
- 主要风险：
- 关键假设（不成立就要重新评估）：
## 结论与请求
- 建议：做 / 不做 / 先做原型验证
- 需要决策层拍板的事：这份模板会在第 3 课升级成正式的项目章程。现在先记住：一页纸能说清的事，不要写成十页。
7、MVP 思维：用最小成本验证最大假设
立项阶段最怕"一口吃成胖子"。MVP（Minimum Viable Product，最小可行产品） 的思路是：
先做一个最小的、能验证核心假设的版本，快速投给真实用户，用反馈决定下一步。
关键在"验证假设"，不是"功能少"。比如你要做打车 App，核心假设是"有人愿意用手机叫车"。那 MVP 可能是：
- ❌ 不是"做半个 App，只有注册没有叫车"
- ✅ 而是"做一个能叫到一两辆车的极简流程，其他全手工"
功能砍到能验证假设为止，验证完再决定加码还是转向。
8、动手实验 🎯
任务：给你最近想做的（或已经在做的）一个项目，写一份一页纸立项提案。
- 复制上面的模板，填满。
重点逼自己写三栏：
- "不做会怎样" —— 答不上来，说明价值可能不真。
- "可衡量指标" —— 写不出数字，回去重想目标。
- "关键假设" —— 列出 1~2 个"如果不成立就白做"的前提。
- 再列两个"被你放弃的候选方案"，写出放弃理由。
- 最后给自己一个结论：做 / 不做 / 先做原型验证，并写一句话说明。
写完之后放一天再看，你往往会发现当初的"必须做"变成了"其实可以不急"。
9、今天你带走的三句话
- 立项是先花小钱省大钱：在花大钱之前，用小成本判断该不该做。
- 先问"为什么"，再问"怎么做"；收益要能量化，不做的后果要能说清。
- MVP 的目的不是"少做功能"，而是"用最小成本验证最大的假设"。
下一课，我们把立项的结论落成正式文档，并且找出所有会影响你成败的人——项目章程与干系人地图。