提示：本文共有 878 个字，阅读大概需要 2 分钟。
1、试图满足各种“用户需求”，最后发现众口难调。往往在细小的、具体的功能上，我们很在意“用户需求”。用户说出来的要求通常是不系统的，是想起啥就要啥。如果产品的设计者只是简单的按用户的要求去做产品，那么后果是…“隐身，对其隐身，隐身对其可见…”按照这种“惟用户需求是从”的方式做一阵子，设计者往往会感叹众口难调，于是很容易陷入另外一种错误中… 2、认为用户其实不知道自己想要什么“如果我问我的用户，他们只会说要一匹更快的马。”—亨利 福特“如果只按用户需求来做，永远也不会有walkman。”—很多讲产品策划的老师都这么说 在这个标榜“用户价值”的时代里，谁一张嘴都是“用户有这样的需求…”“…这是用户需求啊~”或许过分嘲讽类似的说法并没有什么积极的意义，产生这样的说法还是因为我们并没意识到滥用“用户需求”概念的害处。 因此用户的需求到底是什么就需要“用户需求分析”，所谓"需求分析"，是指对要解决的问题进行详细的分析，弄清楚问题的要求，包括需要输入什么数据，要得到什么结果，最后应输出什么。可以说，在软件工程当中的“需求分析”就是确定要计算机“做什么”，这就是用户故事。 可以工作的软件能够更好、更真实的反应项目进度状况。精力和智力所限，人天生只能关注很小的部分。 根据排队原理，用户故事的不确定性是导致系统开发周期非线性膨胀的主要因素。不确定因素主要有：不确定的迭代长度，不确定的用户故事集合，用户故事大小差距很大，团队成员不固定发布时间，不固定新的需求到达时间。解决的方案就是让一切变得确定，稳定。需要把大的任务切成类似大小的小的用户故事。这样就大大减小了不确定性，提高了效率。 每个小功能的完成都是一个反馈点，可以及时沟通信息。大块需求导致很多需求的缺陷往往在最终测试的时候才发现的，如果不能及早完成，尽快测试，缺陷会越来越难以解决。软件很少一次就做好，多次反馈以及不断演进才是一个真正能把功能做好的策略。沟通更加及时，有问题可以及时发现，立刻解决，而不需要过长时间的等待。 使用用户故事，也让需求变得简单、明了，一次很容易让不同人同时去完成。
看到此处说明本文对你还是有帮助的，关于“浅淡需求分析与用户故事”留言是大家的经验之谈相信也会对你有益，推荐继续阅读下面的相关内容，与本文相关度极高！
