前面三篇文章阐述了关于用户故事的Why、What、How、Who、When
Why着重介绍为什么使用户故事，而不是详尽的文档？
What、How、Who：什么是用户故事，怎么写，谁来写，谁使用？
以及When，在Scrum流程的各个环节如何使用用户故事？
这一篇将阐述如何搜集用户需求？并对比传统模式下和敏捷模式下，搜集需求的区别。
传统模式下和敏捷模式下，需求搜集的区别
传统的需求搜集方法是：引出、捕捉。
但现实中，客户自己都很难说清楚自己的需求是什么，只有一个一个的业务目标，一个一个的期望数据。有时候连数据都是未知的。
区分传统过程和敏捷过程的方法之一，就是看它们搜集需求的方式。
1、传统过程：项目早期就期望正确获取并写出所有的需求。
2、敏捷过程：深知时间维度对需求的影响。需求会随着时间的推移，以及过程中客户的反馈，不断变化和逐渐清晰。
系统思维的认知方式告诉我们，解决问题的最佳方式，并非是去找到引起这种变化的原因，因为促成这个变化有很多因素，非常复杂。解决问题的最佳方式，而是专注在当下，去看在当下这一刻，对客户，对市场最高价值的需求是什么？虽然随着时间的推移，千万种因素会使得这些价值产生变化。但是，保证当下（最近这个迭代）做正确的事情，才是以不变应万变的对策。
因此，对于产品来说，此刻不得不提到
敏捷宣言之三：客户协作胜过合同谈判
产品经理需要具备发展的思维
产品经理需要具备发展的思维，频繁地与客户合作，频繁的沟通交流，并保持节奏。而不是在一开始就期望一经定义永远不会变化。也不是尽可能地详细描述细节。
这个沟通交流的周期是，以一个迭代为间隙。在一个迭代结束，客户验收交付物，并产生反馈的时候，是产品与客户交流用户需求的最佳时间。
产品经理需要具备发展的思维，把用户需求看成动态变化的有生命的物质。《用户故事与敏捷方法》中把需求比喻成鱼，代表需求像鱼那样会长大也会死亡。
而产品经理获取需求的方式，是一个动态的不断拖网捞鱼的过程。重要的是在准确的时机，捕捞大个的鱼（高市场价值的需求），以获取最高回报，不必太过纠结细节。纠结于细节必将失去时机。
产品经理各种搜集需求的方法就是捞鱼的网：
1、用户访谈：客户合作中频繁使用的一种方法
2、问卷调查：不推荐，但可以为优先级排序做参考
3、观察：直接观察用户的使用方式和习惯
4、故事编写工作坊：推荐，所有人参与，使用快速原型法进行讨论
渔网：用户访谈
其中用户访谈是使用最多的渔网。
注意区分
--- 客户要求的需求
--- 客户真正想要的需求
真实项目过程中，经常遇到需求来回变化，迭代1客户要求按照方案A做需求，迭代2客户要求改为按照方案B，迭代3客户又觉得改回方案A好像更符合业务逻辑。
这是因为客户有时候也可能不善于理解，也难以表达他们的真实需求。因此，产品经理需要通过有技巧的提问，获得客户的真实需求。需要灵活应用提问技巧，最简单的办法就是：
1、多提开放式问题，避免封闭式问题。
举个简单的例子，请客吃饭，封闭式问题是这样问的，你喜欢吃色香味俱全的美食，是吗？我相信都知道对方将如何回答，这样的问题所获得的答案，对希望搜集信息的人一点帮助都没有。
如果你问客人喜欢吃什么，还一个相对封闭的问题，他可能会告诉你一道或者两道菜，其余的菜需要你自行脑补。
如果你这样问，首先说明在什么时间，哪些人，聚餐的目的，问问客户对这次聚餐有些什么期待，有没有什么忌口？尽量发散，尽量多的搜集信息。最后从海量信息里面，提炼出客户真正想要的需求，再加以确认。
还有问问题的角度，很多时候我们都没有和客户充分沟通的时候，从自己的角度闭门造车的想了一个方案，并拿着这个方案的某个细节去问客户，是不是这样？应该是这样，还是那样？在这样的情况下，客户一定不耐烦回答我们。因为这根本不是她想要的东西，干嘛要回答。
因此和客户沟通的角度就是，对她的需求，以及与需求相关的所有，包括她的想法，她的目标，她的诉求，她的痛点，她的业务掌握程度，技术熟练度，乃至生活都表现出极大的兴趣，以及渴望知道一切的耐心。
2、针对具体的问题，扩大提问的范围。
搜索速度需要多快？，不如问“对性能有什么要求？”
什么时候用封闭式问题？当信息搜集到足够的时候，运用封闭式问题收敛和验证最终的结果。
看起来很像撒网的过程。
一开始就使用封闭式问题，就像用一个鱼叉在挨个捞鱼。准确度查，效率低。
一开始使用开放式问题，撒网，过程中尽量扩大提问的范围，将足够多的高价值鱼打捞起来，然后用封闭式问题收网。收网的方法很多，其实就是一个验证的环节，有提问法，也有原型法，探针法......
最后，产品经理精准获取市场需求和客户需求的能力，取决于他快速捞取和判断的能力，因此一个敏捷项目的成败也和正确判断需求和恰当的时机捞取最高价值的需求息息相关。
下一篇将阐述，用户角色建模和用户故事编写。
