一、需求的层次及核心
- 三个层次：业务需求、用户需求、功能需求
需求的4个核心假设
- 假设用户痛点真实存在
- 假设我们的方案能够解决用户的痛点
- 假设我们的解决方案能够实现
- 假设用户愿意选择我们的方案
提升设计能力，降低变更成本与风险
简单设计原则（优先级由高到低）
- 通过所有测试 满足功能需求
- 没有重复 修改的话，可能修改多个地方
- 表达意图 方法、变量的命名
- 最少程序元素
如何应对河马需求
- 定期与老板沟通，看有什么变化
【需求变更】需求临时变更，如何做好应急处理？
二、需求变化的常见原因
需求变更的原因：
- 找错了用户痛点
- 痛点确实存在，得未解决用户的痛点
- 无法按原计划实现方案
- 没有竞争对手做的好，用户不愿使用
三、应对变更：程序员的头号噩梦
失败原因，限入技术细节，与用户沟通，用户不理解。
要引导用户，不要让用户牵着鼻子走。
四、总结
应用需求变更，5个方法应急处理：
- 跳出功能需求，挖掘业务需求和用户需求。
- 采用简单设计，提高设计能力，降低修改成本。
- 引入自动化测试，降低变更的风险。
- 延迟决策，尽量晚定细节，留出更多时间接受变化。
- 定期梳理需求池，避免出现紧急需求。
【需求评估】真伪需求，如何梳理分析？
切忌拿到功能需求就开干
清楚背景和痛点，再提出建议。
重视解决的问题，而不是解决方案。
忽略用户提出的方案，直奔问题。（用户故事）
业务和用户不是软件专家（产品经理和业务分析师）
用户旅程地图（挖掘用户需求的工具）
image.png
聚焦价值的需求管理课：需求变更和需求评估
image.png
image.png
总结
image.png
体会
用户旅程地图确实是一个好工具。
需求变更的约大部分来源是前期沟通方式、方法问题，没有对用户真实需求理解，没有挖掘出用户全部性需求。
