2、需求分析与定义：如何收集启动需求？需求优先级排序方法（MoSCoW、Kano模型）
需求分析这事儿，说简单也简单，说复杂能让你掉一层皮。
我见过太多项目，启动会上大家拍着胸脯说“需求很明确”，结果做到一半才发现，每个人脑子里的“明确”根本不是一回事。产品经理想要花里胡哨的功能，开发想偷懒，老板想要快，用户想要稳——全拧在一起。
所以，需求收集和优先级排序，不是走个过场。它是整个启动流程的“地基”。地基歪了，后面盖多高的楼都得塌。
2.1 需求收集：别坐在办公室里拍脑袋
我个人习惯，启动阶段第一件事不是开会，是去“现场”。
这里的现场，可能是用户访谈、数据分析、竞品调研，甚至是翻翻客服聊天记录。你得搞清楚：谁在用？在什么场景下用？痛点到底是什么？
核心原则：需求不是“想出来”的，是“挖出来”的。
常用的收集手段，我列个清单：
- 用户访谈：一对一聊，别搞小组座谈。小组里容易有人带节奏，一对一才能听到真话。
- 问卷调查：适合大范围验证，但问题设计要小心，别诱导回答。
- 数据分析：看用户行为日志，比听用户嘴上说的更靠谱。用户经常“言行不一”。
- 竞品分析：看看别人踩过的坑，别自己再踩一遍。
- 利益相关者访谈：老板、运营、销售、客服……每个人视角不同，需求也五花八门。
我的小技巧：每次访谈结束，立刻整理录音。别等第二天，记忆会骗人。我曾经因为偷懒，隔了一周才整理，结果发现关键细节全忘了，气得我抽了自己一嘴巴。
2.2 需求分类：先分清楚再谈排序
收集回来的需求，往往是杂乱的。有人想要“登录快一点”，有人想要“界面好看点”，还有人想要“能导出Excel”。
你不能直接拿这些去排优先级。得先分类。
我一般分成四类：
| 分类 | 说明 | 例子 |
|---|---|---|
| 功能需求 | 系统必须做什么 | 用户注册、商品搜索 |
| 非功能需求 | 系统做得怎么样 | 响应时间 < 200ms、支持 1000 并发 |
| 约束条件 | 必须遵守的限制 | 必须用 Java、部署在私有云 |
| 业务规则 | 业务逻辑的硬性规定 | 满 200 包邮、VIP 用户免运费 |
分好类之后，你才能用对工具去排优先级。不然就是鸡同鸭讲。
2.3 优先级排序：MoSCoW 模型
MoSCoW 是我最常用的方法，没有之一。简单、粗暴、有效。
它把需求分成四个等级：
- M - Must have（必须有）：没有这个功能，项目就废了。比如支付系统里的“付款”功能。
- S - Should have（应该有）：很重要，但暂时没有也能活。比如“订单备注”功能。
- C - Could have（可以有）：锦上添花，有更好，没有也无所谓。比如“深色模式”。
- W - Won't have（这次不做）：明确告诉所有人，这次不搞。比如“多语言支持”。
注意：很多人会把 M 和 S 搞混。我有个判断标准——如果砍掉这个需求，上线当天会被用户骂死，那就是 M。如果只是被吐槽两句，那就是 S。
举个例子，一个电商 App 的启动需求：
| 需求 | MoSCoW 分类 | 理由 |
|---|---|---|
| 用户登录 | M | 没有登录，无法下单 |
| 商品搜索 | M | 核心功能 |
| 订单历史 | S | 重要，但第一期可以没有 |
| 商品推荐 | C | 有更好，但算法复杂 |
| 多语言 | W | 这次只做国内市场 |
2.4 优先级排序：Kano 模型
MoSCoW 是从“项目交付”角度看的。Kano 模型则是从“用户满意度”角度看的。
Kano 把需求分成五类：
- 基本型需求：做了用户没感觉，不做用户会炸。比如“电梯里的按钮”。
- 期望型需求：做了用户开心，不做用户不爽。比如“电梯里的空调”。
- 兴奋型需求：做了用户惊喜，不做用户也无所谓。比如“电梯里的音乐”。
- 无差异需求：做不做用户都没感觉。比如“电梯按钮的材质”。
- 反向需求：做了反而让用户讨厌。比如“电梯里强制播放广告”。
关键点：基本型需求必须优先满足，这是底线。兴奋型需求是差异化竞争点，但别花太多精力。
我自己的经验是，把 MoSCoW 和 Kano 结合起来用：
- 基本型需求 → 几乎都是 Must have
- 期望型需求 → 大部分是 Should have 或 Could have
- 兴奋型需求 → 通常是 Could have，偶尔可以升到 Should have
2.5 需求优先级决策流程
光有模型还不够，你得有个决策流程。不然大家吵起来，谁嗓门大谁说了算，那就乱套了。
我一般走这几步：
- 收集原始需求：不做任何过滤，先全收进来。
- 分类：按功能/非功能/约束/业务规则分好。
- Kano 分类：判断每个需求属于哪一类用户满意度类型。
- MoSCoW 排序：结合项目目标和资源，给出 Must/Should/Could/Won't。
- 评审：拉上产品、开发、测试、运营一起过一遍。谁有意见当场说。
- 签字确认：所有利益相关者签字。别口头答应，后面翻脸不认账的事我见多了。
避坑指南：我曾经在一个项目里，老板拍脑袋把“用户积分系统”定为 Must have，结果开发了两个月，上线后用户根本不用。后来一查，用户只关心价格和物流，积分对他们毫无吸引力。所以，优先级排序一定要基于数据，而不是基于谁的官大。
2.6 需求优先级决策流程全景图
下面这张图，把整个流程串起来了。你可以把它贴在墙上，每次讨论需求时看一眼，能少吵很多架。
2.7 常见坑与避坑指南
最后，聊几个我踩过的坑，你遇到了绕着走。
- 坑一：需求收集不全——只问了老板，没问用户。结果做出来没人用。
- 坑二：优先级排序靠吵架——谁嗓门大谁说了算。最后全是 Must have，等于没有优先级。
- 坑三：忽略非功能需求——功能做全了，结果上线就崩。性能、安全、可扩展性，这些必须提前想清楚。
- 坑四：没有签字确认——做到一半，需求方说“这不是我要的”。你哭都没地方哭。
我的血泪教训：有一次，我负责一个后台管理系统。需求方说“报表导出”是 Could have，我就没太在意。结果上线当天，客户说没有报表导出就不付款。最后全员加班三天补功能。从那以后，所有需求必须白纸黑字写清楚，并且让需求方签字。别信口头承诺。
需求分析这事儿，没有捷径。但有了 MoSCoW 和 Kano 这两个工具，至少你能把一团乱麻理出个头绪来。剩下的，就是多问、多听、多确认。