笔者从自身经验出发，就什么是用户故事、如何收集用户故事两个问题进行了分析讨论，一起来看看吧。
从最初的瀑布模式开始，需求就贯穿了产品与项目的始终，是一个产品搭建的重要信息来源，无论是有明确用户需求的企业级产品也好，还是没有明确用户需求的互联网app产品也罢，需求调研都是产品闭环的源头，调研的优劣直接关系到产品的成败。
记得最初去一家电信公司做项目，他们的需求都不是自己提，而是集团帮着提，有一套厚厚的集团规范，读起来非常的拗口、费解。
就和方言一样，可能A和B读完，会有各自不同的理解，总之那时候的产品说不好做也不好做，因为需求难理解，客户也不知道自己为什么要用系统，也不知道要做什么；
然而说好做也好做，因为客户也不需要真正使用系统，有时候就是装装样子，糊弄一下集团的规范。
后来就有了敏捷（中间跨度还是很大的，只不过一笔带过），敏捷以水的柔性，充分化解了之前瀑布模式死板和教条的化的项目流程。
但是很多企业以为敏捷就是解决项目与产品问题的万能良药，为了敏捷而敏捷，只不过以前写需求文档，现在改写用户故事，换汤不换药，把敏捷当成菩萨一下，以为供一供就能保佑项目顺利上线……
答案当然是：NO！
敏捷的用户故事，绝对不是这么LOW的，一个好的用户故事么，不是套用一个模版，把用户说的写上去就算完事了，前期还是需要大量的准备工作的，后面也得加入产品经历自己的分析和评判。
需求调研
一个用户故事，必须来自用户，但是可能又不是客户自己说出来的，有点费解，举个例子来说：一个家装客户，可能经常会跟设计师说，我家客厅比较暗，我看别人家又一个灯特别好看，我也想装一款，这个需求看似很合理，但是答应客户需求之前还是得自己质疑一下这个需求。
客户真的是需要灯么？装一个灯在客厅就能解决问题么？会不会有其他问题，比如容易磕头？安全问题？
在通过与客户深入沟通后，发现问题的本质，客户只是觉得那里太暗了，采光不是很好，那这个问题就从选择灯的类型变成了选择何种光源来解决客厅暗的问题，可能解决的方式就会有很大差别。
所以一个需求调研是否清楚，直接影响后面产品的设计的思路，影响产品的最终形态。
如何收集？
那用户故事究竟该如何收集呢？
一定要倾听，打开用户的话匣子让他喷，引导他说（其实就是多问问为什么，你期望什么之类）；不要强加干涉、不要喧宾夺主的自己说太多；
一定要把握好调研的节奏，明确目标，不要让调研变成你给客户的推销或培训，更不要让调研变成客户的抱怨，一定要产生有价值的信息；
一定要明确场景，不同的场景可能用户的需求是不一样的，可能会演变成多个用户故事；
一定要问用户、客户两种角色的需求，用户是最终使用的人，而客户是付钱的人，两种人会有两种截然不同的需求（但多数情况是只问客户的，毕竟人家给钱了，没给钱的，嘿嘿，那就等着接受我们复杂的系统和无休止的培训吧）；
一定要多问客户或用户期望的目标是什么，描述他们希望达到的目标的场景。
只有收集上述信息后，经过整理和分类，才能形成最终的用户故事，变成产品经理熟知的用户故事：xx用户在xx场景下，通过xxx操作，实现xxx，目的是xxx。
再引申一下，结合之前讲的思维方式培训，其实需求调研就是在印证你的思路是否正确，是否可以和用户同频；
在目标明确，目的相同的基础上，反向推演是否可以把产品和业务逻辑，套用进客户的需求中，满足客户基础需求，甚者给他们一些惊喜，如果是，那么你的产品至少是能拿的出手了。
