4、需求优先级排序：MoSCoW方法、Kano模型、价值与复杂度矩阵、需求评审与确认
4.1 为什么优先级排序这么重要？
说实话，我见过太多项目死在「什么都想做」上。
有一次，一个创业团队找我做架构评审。产品经理列了40多个需求，每个都说是「核心功能」。我问他：「如果下周一必须上线，你砍掉哪20个？」他愣住了。
你看，这就是问题。没有优先级排序，团队就像无头苍蝇。资源有限，时间有限，你不可能满足所有人。
优先级排序，说白了就是回答三个问题：
- 哪些必须做？——不做项目就黄了
- 哪些应该做？——做了能加分，不做也能活
- 哪些可以不做？——做了浪费，不做省心
我个人习惯，在项目启动的第一周，就拉着产品、开发、测试一起做优先级排序。别等到开发到一半了，才发现资源不够用。
4.2 MoSCoW方法：最实用的优先级分类法
MoSCoW 是我用得最多的方法。它把需求分成四类：
| 分类 | 含义 | 占比建议 | 例子 |
|---|---|---|---|
| Must have | 必须有，否则项目失败 | 约20% | 用户登录、支付功能 |
| Should have | 应该有，但可以找替代方案 | 约30% | 消息推送、数据导出 |
| Could have | 可以有，锦上添花 | 约30% | 深色模式、动画效果 |
| Won't have | 这次不做，以后再说 | 约20% | 多语言支持、第三方集成 |
我曾经在一个电商项目中，产品经理把「商品推荐算法」标成了 Must have。我问他：「没有推荐算法，用户能不能下单？」他说能。我说：「那它就不是 Must have，最多是 Should have。」后来我们砍掉了这个需求，提前两周上线。
嗯，这里要注意：MoSCoW 不是一成不变的。随着项目推进，需求会变，优先级也要跟着调。我一般每两周重新审视一次。
4.3 Kano模型：从用户满意度看优先级
MoSCoW 是从「做不做」的角度看。Kano 模型是从「用户爽不爽」的角度看。
Kano 模型把需求分成五类：
- 基本型需求：做了用户没感觉，不做用户骂娘。比如登录功能、页面加载速度。
- 期望型需求：做了用户开心，不做用户失望。比如搜索功能、筛选条件。
- 兴奋型需求：做了用户惊喜，不做用户无所谓。比如一键换肤、智能推荐。
- 无差异型需求：做不做用户都没感觉。比如后台日志格式。
- 反向型需求：做了反而让用户不爽。比如强制弹窗广告。
你想想看，基本型需求必须优先满足。但很多团队犯的错误是——只盯着基本型需求，忽略了兴奋型需求。
我记得有一次做社交App，产品经理把「消息已读回执」标成了 Must have。我说：「这是基本型需求吗？用户没有已读回执，就不能聊天了？」他说不是。我说：「那它其实是期望型需求。我们先把聊天功能做稳定，再考虑已读回执。」后来上线后，用户反馈很好，没人抱怨没有已读回执。
4.4 价值与复杂度矩阵：用四象限做决策
MoSCoW 和 Kano 都是定性分析。但有时候，你需要更量化的方法。
价值与复杂度矩阵，是我在架构评审时必用的工具。它把需求放在四个象限：
| 高价值 | 低价值 | |
|---|---|---|
| 低复杂度 | 立即做（Quick Win） | 有空再做（Fill-in） |
| 高复杂度 | 规划做（Major Project） | 放弃做（Money Pit） |
怎么用？很简单：
- 给每个需求打「价值分」（1-10分）和「复杂度分」（1-10分）
- 价值分高的，优先做。复杂度分低的，优先做。
- 高价值低复杂度的，立刻做。低价值高复杂度的，直接砍掉。
我曾经在一个项目中，有个需求是「支持微信支付」。价值分9分，复杂度分2分。典型的 Quick Win。我们花了两天就搞定了，用户满意度直接飙升。
另一个需求是「支持多语言国际化」。价值分3分，复杂度分8分。典型的 Money Pit。我们直接砍掉了，放到二期再说。
4.5 需求评审与确认：别让优先级白排了
优先级排好了，不等于万事大吉。你还需要做需求评审和确认。
为什么？因为优先级是「我们以为的」，需求评审是「大家确认的」。两者可能不一样。
我一般这样组织需求评审：
- 会前准备：把需求文档和优先级列表提前发给大家。别在会上花时间读文档。
- 会上讨论：重点讨论 Must have 和 Should have 的需求。Could have 和 Won't have 的，简单过一下就行。
- 会后确认：发邮件或文档，让所有人签字确认。尤其是产品经理和项目经理。
我曾经吃过一次亏。有个需求评审会，大家口头都同意了。结果开发到一半，产品经理说：「这个需求不是 Must have 吗？怎么还没做？」我说：「上次评审时，你不是说改成 Should have 了吗？」他说：「我没说过啊。」
从那以后，我养成了一个习惯：每次评审结束，当场写会议纪要，发到群里，让大家回复「确认」。嗯，白纸黑字，谁也赖不掉。
4.6 总结：优先级排序的实战流程
好了，说了这么多，我总结一下我的实战流程：
- 收集需求：产品经理、用户反馈、竞品分析，统统收进来。
- 初步分类：用 MoSCoW 方法，分成 Must/Should/Could/Won't。
- 用户视角验证：用 Kano 模型，看看哪些是基本型、期望型、兴奋型。
- 量化评估：用价值与复杂度矩阵，给每个需求打分。
- 评审确认：拉上所有人，过一遍优先级，签字确认。
- 动态调整：每两周重新审视一次，根据实际情况调整。
你想想看，如果每个需求都按这个流程走一遍，还会出现「开发到一半发现资源不够」的情况吗？
不会的。因为你在开始之前，就已经想清楚了：哪些必须做，哪些可以砍。
这就是架构师的思维方式——不是什么都做，而是做对的事。