探索.提问
12009概述
提问，即定义问题。通过有针对性的提问，找出客户的具体需求，并找出具体需求后的原因，即具体需求后要解决的根本问题。在提问中形成团队期望达成的业务目标或者想要解决的业务问题。如果问题无法清晰定义，那么找到的答案自然就会有偏差。因此，在寻找答案之前，应该先清晰地定义问题。
如何发现和识别用户的真实需求是目前所有企业面临的难题。通过不断地提问，澄清客户需求背后要实现的真正目标，以便找寻更多解决问题的方法，同时也有助于团队成员从业务问题出发，充分理解业务问题。
如何提问
实现什么 & 如何实现
“用户故事”作为一种描述需求的方式被广泛采用，然而，软件研发团队更关注“需求是什么”的问题。例如，我们经常遇到下面这种团队需求讨论的场景。
业务人员：你按照这个文档中的业务流程和界面样例开发就行了。
开发人员：这个流程走到这里时，遇到（……）这种情况时，这个字段里应该包含哪些选项？
业务人员：你可以这么做（……）
开发人员：那这样处理以后，接下来怎么办？
上述的提问目标是澄清用户的直接需求（即业务人员提出的解决方案）。从“满足客户需求”的服务心态来看，这样的工作方式也没有什么问题。然而，按照业务人员编写的文档开发，就能满足他们真实的需求吗？
为什么要实现
提问环节要求不仅仅是找到“实现什么”以及“如何实现”，更是要了解客户需求背后要解决的真正问题“为什么要实现”，以便规划更加方便快捷的验证方案或解决方案。
由于角色惯性，从开始讨论的那一刻起，我们就很容易跳过最重要的问题，也就是说，如何更好地为客户解决真正的问题，而这恰恰是我们应该做的。
假设我们正举办一个小型线下聚会，主题是“敏捷开发”。有位听众希望能够喝上一杯咖啡。为了更好地为客户服务，作为主办方，我们耐心地询问他“需要哪种口味的咖啡？”“热的，还是冰的？”“大杯，还是中杯？”“希望什么时间拿到？”。
所有这些问题都只是在问“做什么”和“怎么做”，并没有任何一句问及原因。如果客户想要解决的真正问题是“在听讲时不会因为困意而错过了听讲”，我们也许有很多方法解决他的诉求？也许我们可以录制视频，这样即使参与者在过程中开小差，在沙龙结束后，他们也能够回顾一下沙龙的所有内容。我们还有更多的方法来满足用户不错过精彩内容的需求。
为了解决客户的问题，我们可能会找到很多种解决方案，但前提是我们必须发现“正确的需求”。所谓“正确的需求”，是那些能够解决客户真正想要解决的问题，而不一定是由客户提出的解决方案。
我们接到一个工作任务时，我们应该更多地深入理解所要解决的问题，了解其背后的真正原因，不要过早地进入解决方案环节的讨论，而忽视了对问题的讨论。这样才能更好地解决问题，而不仅仅是完成软件功能的开发工作。
要点
在“提问”中，需要注意以下4点：
- 问题域的提出方及解决方案的提供方代表尽量到场，参与讨论。
- 多问几个“为什么”。尽量避免因为感觉自己熟悉这个问题域，而过早地放弃探索。
- 在条件允许的情况下，尽可能收集数据信息，以便作为问题理解和分析的佐证。
- 移情，使用同理心。设身处地站在客户或问题提出方的角度思考问题，还原客户问题的场景。