需求获取和分析难吗？

  现在越来越发先一些开发对需求获取过于泛泛。什么叫泛泛呢？其实中国人喜欢中庸。也听说过易经。在生活中处事不反对中庸。但是在获取需求和分析的时候坚决反对这种中庸。

  给个需求获取的场景：
 
小A:  老板你想做什么
Customer: 我想做一件衣服
小A:  那我给你量尺寸吧！
Customer: 好
小A：三维分别是：29，28，31。于是小A就带着三维回到店里交给做衣服的人进行按三维做衣服。

当小A交货的时候：场景如下
小A： 老板你的衣服做好了，你试试看合身不！
Customer：怎么你用的不是棉布啊，怎么没给我的裤子放长一点啊。衣服好像有点紧啊！这不料不适合我！。。。。
小A： 你当时这些没告诉我啊！我是一般的规格给你做的啊！你还你还是穿起来提合身的嘛！
Customer： 你当时没我还有什么啊，再说了我以为你明白我想要的啊！

点评： 通过上面的场景发现小A在获取需求的时候，不完整而且能不能收到客户的款还是一个问题了。这个过程由于小A对客户的需求获取不周全导致这个场景很容易发生不愉快的事情。


下面看看B的获取分析过程：场景重现
B:  老板你想做什么
Customer: 我想做一件衣服
B: 那你想要冬天的还是热天的呢？ 
Customer: 冬天
B： 你是想要这件衣服是做什么事情的时候穿(平时，参加聚会)
Customer： 平时
B： 那你平时冬天的衣服是希望紧凑点还是松散点
Customer： 松散点，因为怕冷想多穿几件衣服
B： 你一般冷天穿几件衣服呢？
Customer：一般3件，最多5件
B： 那你喜欢用什么布料呢！
Customer： 最好用丝的吧，
B： 那你喜欢什么样的颜色呢？
Customer： 浅蓝色或者浅红色
B： 我们店有一批不错的是浅红色的丝，那用浅红色的吧！你认为呢！
Customer： 好吧！不过我可不可以看看。
B： 没问题。你还有什么其他的要求吗？
Customer： 暂时没有：
B： 那我给你量下三维吧！你的三维分别是：29，28，31。到时候我们给你做的衣服三维是按照这个的基础上（+-0.5）你看怎么样！
Customer： 没问题。
B： 那今天先这样，到时候给你电话来我们店里试穿下衣服。
该需求获取基本上结束。下面进入一个试做和试穿的过程（开发原型）
B： 你好，有没有空？来我们店试穿下你上次订做的衣服
Customer：好的！不错！但是我觉得黑色的颜色好像更好看点。(用户开始进行需求变更了)
B: 不过上次我们交流的时候，我们说好的是浅红色啊。再说浅红色穿起来你看起来不错啊
Customer: 哦，那没关系了。看起来挺合身的。不过能不能在袖子上加些扣子
B： 不过这可能会增加这件衣服的费用！
Customer： 那没关系
B： 你想加两排扣子还是一排扣子或者其他什么样子
Customer： 我想在袖子上加两排扣子
B： 每排加几个扣子呢？
Customer： 3个吧
B： 好的。那还有什么要求没！
Customer： 没有了！
B： 下次我将专程将做好的衣服送到你家！
Customer： 好的
整个场景到处停一个段落：因为原型基本上完成，新增需求明确。上面这个场景可能不能很好的来说明需求获取和分析。但是能够得出如下
总结： 对于获取需求和需求分析，必须将一些模糊的词进行量化;比如大、小、几，多，高。。当客户说到这些的时候，最好能够得到一些具体的数词或者一个范围比如最少3件最多5件等等如果在需求或者和分析中出现模糊的词越多那么风险越大。在你无法更好的获取到需求的时候，请先将这些模糊的词进行量化。

希望可以来交流下，下次如果有需要将发帖给出通过需求到设计分析这个过程中的注意事项。同时也可以结合UML的一些图。前提是有朋友一起来交流或者要求！

照你的说法，是因为不够细致才导致需求获取出了问题，是个技术活，RP问题。这么简单？

你做需求，首先要能提出问题，这个能力怎么来,为什么会泛泛？不够细致、中庸？

你细致了，量化了，是否就能把客户的需求不断的给引出来？价格呢？

仔细想想，做需求的首先要具备什么能力。

不要说到中庸就觉得是贬义，请先去了解它。其实中庸就是一个度的把握。

从开发的角度来看，客户的需求经常是千奇百怪。所以需要开发去引导。
怎么引导呢，我的想法是这样，在了解了基本的需求后，就可以做，界面的东西尽早给客户看，其他的东西，一旦有原型就给客户看，使用。再由客户给建议。
这样在减少开发的工作量，也给开发的功能实现给一定的空间。敏捷开发其实就是这样做的。

应该是在这 业务方面不够熟悉, 如果熟悉了  就不会发生 小A那种情况了。
要做好B,技术也得过关.不然不算是好的分析了

很明显的！你首先要非常的了解业务！

其次，你熟悉业务了就能做需求了？不一定！这就是人的问题了！

最后，你要会分析~~

支持这个,这才是实际中真正面临的问题,LZ说的那是一个业务领域里新手和老手的区别,你叫B去铁匠铺给Customer打把剪刀,一样会犯A的错误. 甚至你做的衣服很合适Customer A,结果Customer A调走了,调来了Customer B,他却不喜欢这样的款式,你还得重做.同样是一件衣服,衣服功能也一样,人不一样,喜好不一样,你的需求也就变了,因此中庸未必是坏事.

其实说获取需求的人最好是业务高手这个是没有问题的！但是你手中没有这样的人的话！怎么办呢？不干吗？现在只能是将开发人员或者实施人员跟着客户一起去学习！先带着眼，耳朵然后接着根据实际客户的流程进行总结进行引导！不过这样的话，就必须不断缩短你的需求获取到原型的周期！ 在说一个问题：关于中庸！其实中庸的问题是在你不明确的情况下不要去明确一个结果。你要站在中间不表示对和错的角度去分析问题。一切根据引导用户的要求去进行分析。至于用户的要求是否合理也是需求去分析的。

但是总的来说：不管是做衣服，还是买菜本质上都有一些共同的特性。如果是新手，那么在去获取需求之前至少要对这些共同的特性进行了解这掌握适当的通过这样进行引导客户。这个获取就在于消除一些模糊的词。坚决不要连篇的很多，很少，大部分等等。

 

只能说小A不够专业.

其实如果你叫B去铁匠铺给Customer打造剪刀，可以不是该领域的人。（B在去之前首先必须知道剪刀是个什么东东）
例如：B先问Customer想要打造什么样的剪刀。Customer会告诉B它想要什么样的剪刀。这时候B不是里面回去跟打造剪刀的人说Customer说的。B应该先去找打造剪刀的人根据Customer说的进行简单的沟通。然后在回去找Customer接着问你从Customer得到的一些问题。这里就是你必须不停的通过问和学习进行获取。这个是获取需求人的策略和方法。
     

做需求本质就是从中庸中获取程序要的0，1条件。而不是一些模糊的词。（所以不管业务熟悉还是不怎么熟悉你获取需求的手段可能不一样）但是必须尽量将一些模糊的词进行得到用户的明确答复。基本上现在没有谁敢说能够获取足够的需求。只能消除一些没有量化的因素而带来的风险。我不赞成能够完全将客户的需求引出来。这个不太现实，只能消除我们能够预防的风险，这里我观点是尽量将一些可以量化的东西量化