小白兔蹦蹦跳跳到面包房，问：“老板，你们有没有一百个小面包啊？”
老板：“啊，......”
小白兔蹦蹦跳跳到面包房，问：“老板，你们有没有一百个小面包啊？”
老板：“啊，真抱歉，没有那么多”
“这样啊。。。”小白兔垂头丧气地走了。
第二天，小白兔蹦蹦跳跳到面包房,“老板，有没有一百个小面包啊？”
老板：“对不起，还是没有啊”
“这样啊。。。”小白兔又垂头丧气地走了。
第三天，小白兔蹦蹦跳跳到面包房,“老板，有没有一百个小面包啊？”
老板高兴的说：“有了，有了，今天我们有一百个小面包了！！”
小白兔掏出钱：“太好了，我买两个！”
在昨天需求的陷阱的文中，我们先不考虑这个淘气的小学生该去什么样的学校，不过对于需求调研的重要性已经引起大伙的主意。不过在我们到底该如何做好需求调研的工作，避免掉入需求的这个陷阱之后，要做好需求不是一句话或则一篇文章可以解释清楚的，毕竟这个课题有太多人在研究在考虑。今天我们还是从方法上去考虑，如何才能够让我们的需求尽可能能够达到开发的要求和满足客户的真正需要。用小白兔买面包的故事来说明简单与不简单的问题有点牵强，但是实际开发中如果没有处理好问题的话，使简单的问题复杂化，复杂的问题片面化，客户方与开发方何尝不会出现小白兔的现象。
1：简单
什么是简单？该如何简单？或许有不少人说小学生不适合作需求调研，因为他把简单的问题复杂化了，如果team中有这样的人做需求，对于项目组来说是一个恶梦。其实我们做项目的时候，都希望能够将复杂的问题简单化，多于同样能够解决客户的多种方法中，我相信简单的方法都会成为首选。所以问题的简单化不是一个过错，而是一个良好的方法，但是对于这种简单的做法必须有一个前提，那就是必须满足客户的功能和使用上的要求，这一点可能非常容易出现差错。很多人在做需求定义的时候，会有类似的问题存在：
1） 对于客户的业不理解，想当然的简单化
2） 客户提出的功能，用偷工的方式简单化
3） 客户提出的问题比较弱智，不需要考虑的简单化
4） 细节问题的简单化
对于这些方面的简单我想直接给项目的开发种下一个恶根，后续的开发反复追问吵闹是在所难免。
那么我们该如何选用简单的方式呢？还是那些老调的方法，就是问题的确认方式要简单，要让客户能够比较直观的看到你要做的东西，不论采用那种方法，比如界面演说，敏捷开发中的Demo推进的方法都可以。客户的优势在于他们对于本身的工作内容非常清楚，但是不要指望他们能够将这些问题用很专业的计算技术语的方法来描述清楚。也不要避免让客户想象系统是如何如何？这一切都不实际，两个人的理解很难是一样的，对于同一个月亮，可能一个想象的是光色多美，一个想象的是有月饼吃多好。所以如果用直观的方式来描述问题，抛开那么多深奥的建模工具，多于客户来说可能更容易理解。当然，如果客户的能力能够和你旗鼓相当，那么那些工具可能是最好的选择，所以的一切都需要紧记一点，交流的双方应该确定在同一层次上用相应的方式进行交流。
2：手段
简单的交流要有手段和技巧，如何避免客户反感然后得到客户的最大配合，这需要很强的EQ,但是在这些交流中，一些比较常用的方式倒可以大大提高你的交流效果。
1）选择性的问题永比叙述性的问题奏效
在做需求调研的时候，如果用“为什么。。。，该怎么。。。？”这种方式去询问客户比“是不是这样：1）….2)….”的这种方式要差很多，而且客户的回复速度上也有很大的差别，让客户选择其中的一点，客户一方面感觉你已经做了大量的工作和思考，另一方面替客户节约了不少的时间。
2）图比文描述直观
写文档可能对于做开发的人来说比较困难，对于客户来说，长篇巨幅的文章去起来也非常吃力，很多时候问题还很难描述清楚，再加上中国文字的精辟特点，描述的内容有时候理解起来会有歧义，所以对于很多的时候我建议使用图来描述问题，比如说界面的动作描述和一些其它的逻辑方式，用直观的图形来描述问题，客户可以减少阅读的时间，也很容易理解。
3）避免诗性大发
有时候我们做文档的时候，经常出现长句，一句话洋洋洒洒卸了三四行，总计过100字，客户读起来比天书还难读。还有有些描述过于简练深奥，像武侠小说中描述的那样：“刀，冷气逼人，随月光而落，一弘血影滑过，人便倒在地上。”诗词故事讲究的是一种意境，给人一种想象，但是作为技术性的文档来说，要避免给出这种想象的空间，问题要清晰，直观，明确。在描述问题的时候我们可以将长句分成短句，标上序号来按点描述问题，增强可读性。
3：不简单
其实对于需求调研工作来说是一件不简单的事情，因为作为项目开发的基础，他所承载的担子非常重，而且涉及到和客户沟通等问题。所以能够将需求确立清楚，对于开发来说不是一件轻松收集资料的事情。如何了解客户的需求，用非专业的沟通方式沟通专业的内容都不是那么轻松，如果抛开国情特色和人力不可抗拒的因素来说，这部分的工作可以说是整个项目的起头作用，到底是虎头还是鼠头，是项目的一个关键。
老板：“啊，真抱歉，没有那么多”
“这样啊。。。”小白兔垂头丧气地走了。
第二天，小白兔蹦蹦跳跳到面包房,“老板，有没有一百个小面包啊？”
老板：“对不起，还是没有啊”
“这样啊。。。”小白兔又垂头丧气地走了。
第三天，小白兔蹦蹦跳跳到面包房,“老板，有没有一百个小面包啊？”
老板高兴的说：“有了，有了，今天我们有一百个小面包了！！”
小白兔掏出钱：“太好了，我买两个！”
在昨天需求的陷阱的文中，我们先不考虑这个淘气的小学生该去什么样的学校，不过对于需求调研的重要性已经引起大伙的主意。不过在我们到底该如何做好需求调研的工作，避免掉入需求的这个陷阱之后，要做好需求不是一句话或则一篇文章可以解释清楚的，毕竟这个课题有太多人在研究在考虑。今天我们还是从方法上去考虑，如何才能够让我们的需求尽可能能够达到开发的要求和满足客户的真正需要。用小白兔买面包的故事来说明简单与不简单的问题有点牵强，但是实际开发中如果没有处理好问题的话，使简单的问题复杂化，复杂的问题片面化，客户方与开发方何尝不会出现小白兔的现象。
1：简单
什么是简单？该如何简单？或许有不少人说小学生不适合作需求调研，因为他把简单的问题复杂化了，如果team中有这样的人做需求，对于项目组来说是一个恶梦。其实我们做项目的时候，都希望能够将复杂的问题简单化，多于同样能够解决客户的多种方法中，我相信简单的方法都会成为首选。所以问题的简单化不是一个过错，而是一个良好的方法，但是对于这种简单的做法必须有一个前提，那就是必须满足客户的功能和使用上的要求，这一点可能非常容易出现差错。很多人在做需求定义的时候，会有类似的问题存在：
1） 对于客户的业不理解，想当然的简单化
2） 客户提出的功能，用偷工的方式简单化
3） 客户提出的问题比较弱智，不需要考虑的简单化
4） 细节问题的简单化
对于这些方面的简单我想直接给项目的开发种下一个恶根，后续的开发反复追问吵闹是在所难免。
那么我们该如何选用简单的方式呢？还是那些老调的方法，就是问题的确认方式要简单，要让客户能够比较直观的看到你要做的东西，不论采用那种方法，比如界面演说，敏捷开发中的Demo推进的方法都可以。客户的优势在于他们对于本身的工作内容非常清楚，但是不要指望他们能够将这些问题用很专业的计算技术语的方法来描述清楚。也不要避免让客户想象系统是如何如何？这一切都不实际，两个人的理解很难是一样的，对于同一个月亮，可能一个想象的是光色多美，一个想象的是有月饼吃多好。所以如果用直观的方式来描述问题，抛开那么多深奥的建模工具，多于客户来说可能更容易理解。当然，如果客户的能力能够和你旗鼓相当，那么那些工具可能是最好的选择，所以的一切都需要紧记一点，交流的双方应该确定在同一层次上用相应的方式进行交流。
2：手段
简单的交流要有手段和技巧，如何避免客户反感然后得到客户的最大配合，这需要很强的EQ,但是在这些交流中，一些比较常用的方式倒可以大大提高你的交流效果。
1）选择性的问题永比叙述性的问题奏效
在做需求调研的时候，如果用“为什么。。。，该怎么。。。？”这种方式去询问客户比“是不是这样：1）….2)….”的这种方式要差很多，而且客户的回复速度上也有很大的差别，让客户选择其中的一点，客户一方面感觉你已经做了大量的工作和思考，另一方面替客户节约了不少的时间。
2）图比文描述直观
写文档可能对于做开发的人来说比较困难，对于客户来说，长篇巨幅的文章去起来也非常吃力，很多时候问题还很难描述清楚，再加上中国文字的精辟特点，描述的内容有时候理解起来会有歧义，所以对于很多的时候我建议使用图来描述问题，比如说界面的动作描述和一些其它的逻辑方式，用直观的图形来描述问题，客户可以减少阅读的时间，也很容易理解。
3）避免诗性大发
有时候我们做文档的时候，经常出现长句，一句话洋洋洒洒卸了三四行，总计过100字，客户读起来比天书还难读。还有有些描述过于简练深奥，像武侠小说中描述的那样：“刀，冷气逼人，随月光而落，一弘血影滑过，人便倒在地上。”诗词故事讲究的是一种意境，给人一种想象，但是作为技术性的文档来说，要避免给出这种想象的空间，问题要清晰，直观，明确。在描述问题的时候我们可以将长句分成短句，标上序号来按点描述问题，增强可读性。
3：不简单
其实对于需求调研工作来说是一件不简单的事情，因为作为项目开发的基础，他所承载的担子非常重，而且涉及到和客户沟通等问题。所以能够将需求确立清楚，对于开发来说不是一件轻松收集资料的事情。如何了解客户的需求，用非专业的沟通方式沟通专业的内容都不是那么轻松，如果抛开国情特色和人力不可抗拒的因素来说，这部分的工作可以说是整个项目的起头作用，到底是虎头还是鼠头，是项目的一个关键。
