企业项目为什么不能一上来就写代码？先说清 ROI 和 MVP
第一天下午，我把学生从工具界面拉回了一个更现实的问题：如果你要说服水果摊老板出钱做系统，她最先关心的是按钮放在哪里，还是这套系统能不能减少错单、库存损失和对账时间？
答案显然是后者。企业项目的起点不是功能，而是价值。
立项要回答的四个问题
一个最小的立项判断，需要讲清楚：
- 现在发生了什么问题：最好有事实和基线，而不是“体验不好”。
- 问题造成什么损失：时间、成本、收入、风险或客户满意度。
- 准备投入什么：人力、时间、采购和持续维护成本。
- 预期获得什么变化：可以观察、可以比较，也能在上线后复盘。
这就是 ROI 思维的基本形状。它不一定要求一开始算出精确财务模型，但必须让决策者看到投入与收益之间的关系。
水果商城案例里的价值链
课程案例中，水果摊已经经营多年，有多个微信群和稳定客户。当前流程依靠群接龙、人工记账和手动核销，暴露出超卖、库存不准、对账混乱等问题。
如果只说“做一个水果电商平台”，立项几乎没有信息。更有效的表达是：
- 订单从群消息进入人工表格，容易漏记和重复。
- 库存更新滞后，接单后才发现缺货。
- 收款、订单和核销记录分散，对账耗时。
- 经营规模扩大后，人工流程的错误率和工作量同步上升。
系统第一阶段的价值，不是拥有完整电商能力，而是让订单、库存和核销进入同一条可追踪链路。
学员立项文档最常见的两个问题
第一个是信息错位。很多小组在立项阶段就开始讲首页布局、会员积分和推荐算法。它们属于后续产品或技术方案，不能回答老板“为什么值得投入”。
第二个是缺乏基线。文档写“把订单准确率提升到 99%”，却没有说明现在是多少、如何统计、由谁记录。没有基线，就无法判断提升是否真实，也无法在项目结束后评价收益。
立项文档应该把功能细节暂时压下去，集中说明问题、价值、范围、投入和风险。
为什么还需要 MVP
即使项目值得做，也不代表应该一次做完所有想法。
MVP 的作用是选择最小但完整的价值闭环，用较低成本验证系统是否真的解决问题。对于水果商城，第一版可以优先跑通：商品与库存展示、用户下单、订单查询、后台处理和核销。优惠券、推荐、复杂会员等级可以等主流程验证后再决定。
好的 MVP 不是“每个功能都做一点”，而是围绕一个核心目标，把必要链路做完整。只有首页没有下单，不是 MVP；拥有几十个入口但订单无法闭环，也不是 MVP。
AI 为什么更需要范围控制
没有 AI 时，开发成本本身会迫使团队谨慎。AI 让生成速度变快后，团队更容易产生“顺手再加一个”的冲动。
但每新增一个功能，都会带来需求、页面、接口、数据、测试和维护成本。AI 可以快速生成代码，却不能消除系统复杂度。范围膨胀后，上下文更长、依赖更多、回归测试更重，最终仍然会拖慢交付。
所以我会在每个功能开始前写两栏：本次包含什么，本次明确不包含什么。边界必须进入需求和验收，而不是只存在于项目负责人脑中。
一页立项说明的结构
可以直接使用这套结构：
- 项目背景：当前业务怎么运行。
- 核心问题：用事实说明瓶颈和损失。
- 目标用户：谁会使用，谁会受益。
- 预期价值：希望改善哪些指标或风险。
- MVP 范围：第一阶段跑通哪条闭环。
- 暂不包含：主动排除哪些诱人的扩展需求。
- 投入预估：人员、周期和外部依赖。
- 验证方式：上线后怎样判断值得继续。
讲师判断：MVP 不是缩水版本，而是最小验证闭环
不少同学把 MVP 理解为“少做几个页面”。真正的 MVP 必须保留从用户动作到价值结果的闭环。水果商城如果只能浏览商品，却不能完成下单和后台履约，就没有验证交易是否成立；校园预约如果只有申请表，却没有名额校验和结果通知，也没有验证管理成本是否下降。
因此砍范围时要按价值链判断，而不是按开发难度随机删功能。第一版可以界面朴素、自动化程度低，甚至保留少量人工处理，但必须让目标用户真实走完流程，并产生可以比较的数据。只有这样，下一轮投入才有事实依据，而不是继续凭想象加功能。
课后练习
选一个你想做的校园产品，用一页纸完成立项。删掉所有页面和技术栈描述，只保留问题、基线、投入、价值和 MVP。然后让一位不了解项目的人阅读，看他能否仅凭这页内容决定“做不做”。