从“树上十只鸟，开枪打死一只，还剩几只？”思考产品需求获取与分析
需求评审
- 作用：同步产品对于需求的详细设计；收集大家对于需求的各种反馈（重点）
- 站在用户角度考虑问题的合理性 （包含产品设计和开发实现逻辑）
【比如之前阿里云出现泄漏企业源代码问题：托管提供internal、public、private三个访问权限，平台认为的internal是阿里云平台内登陆可见，而用户认为是公司内部，这不算bug，但属于用户体验类。所以设计者要充分考虑使用者使用场景出现的问题。】 - 挖掘隐式需求：就是把习惯性思维明确化，互相理解一致
X-Y PROBLEM：https://coolshell.cn/articles/10804.html
X-Y Problem最大的严重的问题就是：在一个根本错误的方向上浪费他人大量的时间和精力！
一、产品需求
现在有一个 PC 客户端的命令行工具，这个工具可以接收三个命令行参数，其中，前两个是数字，最后一个是运算符，运算符只支持加减乘除四种，工具的功能就是把前两个数字使用运算符做下运算，然后输出运算结果。
二、在需求评审中讨论
2.1 合理性
- 前两个是数字，最后是操作符，不符合普通用户的操作习惯
- 只支持四种运算是否功能太弱，让开发同学不要写死
- 需求中，参数类型不正确，提示“您输入的参数类型不支持，请重新输入”
这个提示并不明确，参数类型不支持，应该明确支持操作数、运算符哪些类型。和产品商量后为“你输入的参数类型不正确，运算数只支持浮点型，运算符中只支持+-*/，分隔符支持空格和的逗号。” - 另一个合理性例子：个问题往往是产品原型产生初期就被遗漏的问题，带来的后果是用户体验度差。举个例子，用户通过手持端进入领取优惠页面，一系列验证用户操作完毕后，提示领取成功。现在，作为一个用户，大多数情况下应该会找使用优惠券的入口，或者去查看这个优惠券如何使用。然并卵，产品经理忽视了最终的体验对象，只是将用户领取优惠完成来当做这一动作的终结。所以说，测试不仅仅是去验证产品原型，还要考虑业务逻辑是否正常。
2.2 全面性
- 在主分支上拓展旁分支。
2.3 挖掘隐式需求
- 这个需求是明确了参数类型和参数个数，从而很容易想到①三个参数正常、异常情况 ②参数个数正常、异常情况
- 隐式需求是参数间分隔符，开发可能以自己以为的方式实现，比如默认是空格。但是在实际应用中，可能也有很多用户使用逗号、分号等分割，此时要明确是什么分隔符。
- 除数为0
- 其他需求：比如能够手机号登录系统，则要不同运营商所有类型的手机号都能登录
能够用邮箱登录，则要不同后缀的邮箱均能登录
2.4 优先级
某些需求项与已有功能有“冲突”，针对这些需求项，是否明确了优先级，并评估优先级的合理性。
推荐看：给需求做体检