需求分析

需求分析就是把用户的一句话，变成一份“做什么、为什么做、做到什么程度算好”的清单。

需求从哪来

来源	一句话说明
用户反馈	用户在使用中直接提出的问题或想要的功能
老板 / 客户	出钱或拍板的人提出的目标和想法
数据分析	从埋点、转化率、留存等数据里看出的异常或机会
竞品	对手已经做了、用户会拿来对比的功能
客服工单	客服每天收到的重复问题，通常代表一批用户的痛点

来源要记清楚，后面判断优先级时，“谁提的”“提了几次”都是依据。
同一句话从不同来源进来，含义可能不一样，先别急着合并。

需求池

需求先收着，再统一筛。不要一收到就开工，也不要丢在聊天记录里。

字段	说明
编号	每条需求一个唯一编号，方便引用
来源	用户反馈 / 老板 / 数据 / 竞品 / 客服
提出人	具体是谁提的
原始描述	用户原话，先不改写
状态	待评估 → 已评估 → 排期中 → 开发中 → 已上线 / 已拒绝

状态要用统一的一套词。别今天写“待处理”、明天写“待定”，最后没人知道到底做没做。

真需求 vs 伪需求

用户说的，不一定是用户真正要的。

连续追问：连问三次“为什么”。
- 用户说“我要一个导出按钮” → 为什么？→ “我要发给老板看” → 为什么？→ 其实他要的是“自动生成周报发给老板”，导出只是他自己想的实现方式。
还原使用场景：问清楚谁、在什么时候、为了什么用。没有场景的需求，一律先打问号。
区分“用户说的”与“用户真正要的”：
- 用户说的：一个具体的做法（要个按钮、要个颜色、要个入口）。
- 用户真正要的：他要解决的问题（想更快、想省事、想有面子）。
- 产品经理给的是解决方案，不是照抄用户说的做法。

需求优先级

优先级的作用是：资源有限时，先做什么、后做什么。下面三种方法选一种或组合用都行。

四象限法

按“重要”和“紧急”两个维度分成四类。

象限	判断	处理方式
重要且紧急	不做就出问题	马上做
重要不紧急	影响长期价值	排进迭代，别拖
紧急不重要	别人催得急	尽快处理或交给别人
都不紧急	可有可无	先放需求池

适用场景：需求多、时间紧，需要快速拍板先做哪些。

MoSCoW

按“必须做到什么程度”分成四类。

等级	含义	说明
Must（必须有）	没有就不能上线	核心流程，缺一不可
Should（应该有）	很重要，但可以稍后	体验关键，尽量本次做
Could（可以有）	有更好，没有也行	锦上添花
Won’t（这次不会有）	明确这次不做	写清楚，避免误会

适用场景：一个版本要定范围，需要和客户说明白“这次做到哪”。

KANO

按“满足程度带来的感受”分成三类。

类型	特点	例子
基本型	没有会骂，有了也不夸	登录能成功
期望型	做得越多越满意	加载越快越满意
兴奋型	没想到但很惊喜	一键生成分享海报

适用场景：想区分“不做会被骂”和“做了会加分”的功能，好控制投入。

需求边界

边界就是明确“做什么”和“不做什么”，并且写进文档。

in scope（范围内的）：这一轮要交付的功能，逐条列出。
out of scope（范围外的）：这一轮明确不做的功能，也要逐条列出，并写清原因或计划时间。

只写“做什么”不够，一定要写“不做什么”。否则上线后客户一句“我以为是包含的”，就要扯皮。

写法示例：

范围内：手机号 + 验证码登录、忘记密码、登录失败提示。
范围外：第三方微信登录（本次不做，计划下个版本）、多设备登录限制（本次不做）。

验收标准怎么写

验收标准（acceptance criteria）是“做到什么程度算合格”。要求：可验证、可判定，不靠感觉。

差的写法：“登录要快、要好用”（没法判定快是多少、好用是什么）
好的写法：“输入正确的手机号和验证码后，3 秒内跳转到首页”
好的写法：“验证码错误时，页面提示’验证码错误’，且不跳转”

对比：

差的写法	好的写法
页面要好看	首页在 1920×1080 分辨率下不出现横向滚动条
支持上传图片	支持上传 jpg / png，单张不超过 5MB，超出时给出提示
消息要实时	对方发送消息后，1 秒内在我方页面显示

相关文档