饿了么么日均订单突破三万后，投资人找上门了："你们应该做个智能推荐系统，再搞个供应链管理平台，还能做个骑手调度引擎！"老王听得热血沸腾，恨不得明天就全上。小明拦住他："等一下，这些项目每个都要烧钱烧人，我们得先想清楚——为什么要做？值不值得做？怎么做？"
这就是系统规划要回答的问题：从项目提出、选择到确立的全过程。
💡 7.1.1 项目为什么立项？四种动机
组织搞信息化，动机五花八门。归结起来就四种：
| 动机 | 谁干的 | 目的 | 类比 |
|---|---|---|---|
| 基础研究获取技术 | 大学/研究院/企业战略部门 | 技术积累 | 中科院搞AI基础理论 |
| 应用研发获得产品 | 企业立项开发 | 卖产品赚钱 | 做Office、杀毒软件卖 |
| 提供技术服务 | 服务导向公司 | 咨询/集成/定制/运维 | IBM做系统集成 |
| 信息技术产品的使用者 | 最终客户 | 购买使用获得价值 | 企业买ERP系统 |
🎯 7.1.2 项目选择四原则与Kano模型
选项目的四个原则：
- 选有核心价值的产品/项目——Michael Porter的"价值链"：产品设计→生产→营销→应用。核心业务=价值链中增值最大的部分。对生产制造业，生产计划/库存控制/面向订单生产是核心；对金融保险，保单管理/风险评估是核心；对教育，教研/教学/考试是核心。
- 评估项目风险、收益和代价——用总持有成本(TOC)评估，不只买产品/服务的钱，还包括维护、培训、流程变更等隐性开销。
- 评估项目的多种实施方式——不一定自己组团队开发，还可以转包、OEM、购买关键技术集成、外包编码等。
- 平衡地选择适合的方案——不存在完美方案，只存在对当前目标相对适合的方案。"适合"而非尽可能"好"——超出目标的"好"通常意味着更多成本。
Kano顾客质量模型（三种质量）：
- ✅ 要求质量：客户认为产品应该有的功能。实现越多越满意，不实现就不满意。
- 🤔 假想质量：客户想当然认为应该有，但说不清楚的需求。需要沟通确认。
- 🎉 兴奋质量：要求范围外的功能，开发者很乐意加的技术特性。实现了客户更高兴，不实现也不影响购买决策。
📝 7.1.3 项目提出和选择的结果：建议书
项目提出和选择的最终产出=产品/项目建议书。比GB 8567-1988的"可行性分析报告"内容更全面。典型场景：① 投标时乙方提交甲方的竞标方案；② 企业内部立项向上级提交的决策报告。
建议书可能包含：用户单位/背景/需求来源、内外环境/组织机构/现有IT设施、业务模型和规划、技术系统在业务中的位置、信息化后的业务模型、产品需求定义（功能/性能/约束）、技术框架、项目要点/难点/障碍、可行性研究结果、实施方式/组织方式/沟通协调机制、资源范围和预算、成本/收益分析等。
🔬 7.2.1 可行性研究：五个维度
可行性研究的意义：用较小的代价在项目定义阶段识别出错误构思的系统，避免后期大量资源投入的损失。不是详细计划，但能设立一个"底线"。
| 维度 | 评估什么 | 饿了么么的例子 |
|---|---|---|
| 经济可行性 | 开发成本 vs 收益 | 推荐系统开发200万，预期提升10%转化率 |
| 技术可行性 | 技术能力够不够+资源够不够+目标障碍 | 团队有AI经验吗？算力够吗？ |
| 法律可行性 | 侵权/违法/合同/政策限制 | 用户数据用没被认可的加密算法？ |
| 执行可行性 | 真实环境中能被应用的程度 | 商家数据采集质量够不够？员工IT技能够不够？ |
| 方案的选择 | 比较可选方案，折中选择 | 自研 vs 买现成 vs 外包 |
💰 7.2.2 成本效益分析：算清经济账
成本三部分：
- 🏗️ 基础建设支出：房屋设施、办公设备、平台软件、工具软件
- 💸 一次性支出：咨询费、调研费、管理费、培训费、差旅费
- 🔄 运行维护费用：设备租金、维护费、消耗品、通信费、人员工资
收益三类：
- 💵 一次性收益：开支缩减（运行效率改进）、价值增升（资源利用改进）、多余设备出售回收
- 📈 非一次性收益：系统生命期内按月/年的持续性收益
- ❓ 不可定量收益：服务改进、操作失误风险减少、信息掌握改善、组织形象提升
三个关键指标：
- 📊 收益/投资比=系统生命期收益/投资
- ⏱️ 投资回收周期=收益累计超过支出累计的时间点
- 🔍 敏感性分析：关键因素（生命期长度、工作负荷、处理速度、配置等）变化时对开支收益的影响范围
📄 7.2.3 可行性分析报告
GB 8567-1988规定了格式。最重要的内容包括：项目背景（问题/环境/限制）、管理概要和建议、候选方案及选择标准、系统描述、经济可行性（成本/效益）、技术可行性（技术风险）、法律可行性、用户使用可行性、其他问题。
审查流程：项目负责人审查（内容可靠性）→ 上级主管审阅（项目地位评估）→ 得出"行或不行"的决断。
🔧 7.3 方案的制订和改进：从"做什么"到"怎么做"
问题定义阶段回答了"系统目标是什么"，方案制订阶段回答"系统如何实现"。主要工作三方面：
1. 确定软件架构——分析模型结构（功能分解体系或OO的类/关系图）、关键实现要素（用例、控制类、组织模式、算法模型）、特性解释。
2. 确定关键实现要素和手段——关键用例/控制类/组织模式/算法模型；选定基础计算平台（OS/数据库/Web服务器/中间件）、选定开发工具和环境。
3. 归结目标到最适合的计算体系——比较标准计算体系（.NET/J2EE等）与目标的匹配程度。典型的三层计算模式：
- 🖥️ 表示层：用户界面（C/S客户端、B/S浏览器中HTML/DHTML/Script/Applet）
- ⚙️ 事务逻辑层：处理请求、完成商务逻辑计算。COM是心脏，IIS+MTS管理组件
- 💾 数据服务层：提供数据来源，通过连接共享减少连接数
JSP模式：JSP(表示层)→EJB(业务逻辑层)→JDBC+数据库(数据服务层)。小规模网站JSP直接写逻辑=表示层和逻辑层合并。J2EE中EJB容器屏蔽了数据服务层。
🏚️ 7.4.1 遗留系统评价：老系统怎么办？
遗留系统=不知道怎么处理但对组织至关重要的老系统。特点：① 能完成重要业务但不完全满足 ② 性能落后技术过时 ③ 大型系统融入业务运行维护困难 ④ 没用现代工程方法，基本没文档。
评价方法包括5个活动：
- 启动评价：了解系统是否至关重要、商业目标、演化需求、期望寿命、使用期限、技术状态、企业是否愿意改变、是否有能力承受
- 商业价值评价：概要级（咨询、问卷、评价）+ 详细级（不符合业务规范的风险分析）
- 外部环境评价：硬件（供应商/维护费/失效率/年龄/功能/性能，每项1-4分）、支撑软件（OS/数据库/编译器/网络软件/应用软件）、企业基础设施（企业类型/组织技术成熟度/培训/支持人员水平/改变意愿）
- 应用软件评价：系统级（整体不可分）+ 部件级（各子系统特征：复杂性/数据/文档/依赖性/合法性/维护记录/大小/安全性）
- 分析评价结果：技术水平公式 OR=(P1·ORH+P2·ORS+P3·OAF+P4·ORA)/4，加权平均后与商业评价比较，分四象限
🗺️ 7.4.2 遗留系统演化策略：四象限决策
按技术水平（高/低）和商业价值（高/低）分四个象限，每种采取不同策略：
| 象限 | 技术水平 | 商业价值 | 策略 | 做法 |
|---|---|---|---|---|
| 第3象限 | 低 | 低 | 🗑️ 淘汰 | 全面重开发新系统替代 |
| 第4象限 | 低 | 高 | 📦 继承 | 兼容旧系统功能模型和数据模型，新老并行后逐渐切换 |
| 第1象限 | 高 | 高 | 🔧 改造 | 增强功能+改造数据模型 |
| 第2象限 | 高 | 低 | 🔗 集成 | 互连系统架构，作为从属系统集成 |
老王感慨："原来不是什么都要自己搞，系统规划的本质是选择和取舍。"但项目一旦确立，怎么分析需求、怎么设计系统？第8章的系统分析与设计方法在等着他。