1. 项目启动与需求分析
大家好，我是你们这门课的主讲。今天咱们聊聊项目启动和需求分析。
说实话，我见过太多项目，一上来就写代码，结果做着做着发现方向偏了，需求理解错了，最后返工重来。嗯，这其实是最浪费时间的做法。我个人习惯是，哪怕再急的项目，也得先把启动和需求这块走扎实了。
1.1 项目立项流程
项目立项，说白了就是回答三个问题：为什么要做？做出来给谁用？大概花多少钱和时间？
我经历过一个项目，老板说“这个功能很简单，一周搞定”。结果立项时没仔细评估，做到一半发现依赖的第三方系统要两个月才能对接好。你看，立项不严谨，后面全是坑。
标准的立项流程，我一般分这几步：
- 业务方提出需求 — 通常是产品经理或业务负责人发起
- 可行性评估 — 技术团队评估实现难度、技术风险
- 资源估算 — 需要多少人、多少服务器、多少时间
- 立项评审会 — 各方拍板，确认做还是不做
- 正式立项 — 输出立项文档，分配资源，启动项目
1.2 需求调研方法
需求调研，很多人觉得就是“问用户想要什么”。其实没那么简单。
用户说的，和他真正需要的，往往是两码事。我记得有一次，用户说“我想要一个红色的按钮”，调研后发现他真正的需求是“在紧急情况下能快速找到停止按钮”。你看，颜色只是表象。
我常用的调研方法有这几种：
| 方法 | 适用场景 | 我的经验 |
|---|---|---|
| 用户访谈 | 探索性需求，了解痛点 | 别只问一个人，至少访谈3-5个不同角色 |
| 问卷调查 | 大规模收集意见 | 问题要封闭式，别让用户写作文 |
| 竞品分析 | 明确功能基线 | 别照抄，要理解竞品为什么那么做 |
| 原型演示 | 验证需求理解是否一致 | 用Axure或Figma画个低保真原型，用户看了才懂 |
| 数据分析 | 基于现有系统优化 | 埋点数据不会骗人，比用户说的更真实 |
1.3 需求文档编写
需求文档，业内常叫PRD（Product Requirements Document）。这东西怎么写，其实有讲究。
我曾经见过一份需求文档，写了50页，全是文字描述，开发看完一头雾水。也见过一份文档，就10页，但每个功能点都有原型图、有逻辑说明、有异常处理，开发照着做就行。
我个人习惯，一份好的需求文档至少包含这些部分：
- 项目背景与目标 — 一句话说清楚为什么要做
- 用户角色定义 — 谁在用这个系统
- 功能列表 — 按优先级排列，P0/P1/P2
- 业务流程 — 用流程图展示核心路径
- 界面原型 — 每个页面的线框图
- 逻辑规则 — 字段校验、状态流转、权限控制
- 非功能需求 — 性能、安全、兼容性要求
举个例子，一个简单的登录功能，需求文档里应该怎么写？
功能名称：用户密码登录
优先级：P0
前置条件：用户已注册且账号未锁定
正常流程：
1. 用户输入手机号/邮箱和密码
2. 系统校验格式（手机号11位，邮箱含@）
3. 调用认证接口验证
4. 验证通过，生成，跳转首页
异常流程：
- 格式错误：提示“请输入正确的手机号或邮箱”
- 密码错误：提示“密码错误，还剩X次机会”
- 账号锁定：提示“账号已锁定，请30分钟后重试”
- 网络异常：提示“网络连接失败，请检查网络”
1.4 需求评审
需求评审，很多人觉得是走形式。其实不然，这是发现需求问题成本最低的环节。
为什么这么说？你想想看，一个需求问题如果在评审时发现，改一下文档就行。如果到了开发阶段才发现，代码要重写。如果到了测试阶段才发现，那整个版本可能都要延期。
我曾经参与过一个项目，需求评审时大家都没意见，结果开发做到一半发现有个核心逻辑没定义清楚——订单状态在“已支付”和“已发货”之间，如果用户申请退款怎么办？这个问题在评审时没人提，最后花了三天才把逻辑补上。
需求评审，我建议按这个流程走：
- 提前发文档 — 评审会前24小时把PRD发给大家，别在会上才让看
- 产品经理宣讲 — 过一遍核心流程和关键功能
- 开发提问 — 关注技术可行性和逻辑完整性
- 测试提问 — 关注异常场景和边界条件
- 设计提问 — 关注用户体验和交互一致性
- 记录待办事项 — 当场能确定的就确定，不能确定的记下来，会后跟进
- 评审结论 — 通过/有条件通过/不通过
嗯，到这里，项目启动与需求分析这块就讲完了。说白了，这个阶段花的时间越多，后面开发、测试、上线就越顺。别急着写代码，先把需求搞清楚，这是我这十几年项目经验里最深的体会。
下一章，咱们聊聊系统架构设计。到时候我会拿一个真实的电商系统做例子，从架构选型到模块拆分，一步步讲清楚。