需求获取和分析难吗？

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

  给个需求获取的场景：
 

引用

    一天一家裁缝店接到一个贵宾的电话，要在这个家裁缝店做一套衣服。但是不巧的是该店之前上门获取客户需求的人B不在，这是老板只好叫了小A去上门获取客户的需求了。(下面是小A 和 Customer的对话)
 

小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的一些图。前提是有朋友一起来交流或者要求！

评论

28 楼 nininia 2011-01-18  

为什么现在需求都分析不清楚啊，我觉得不是成本问题。是现在的一个通病，需求人员的错误不是自己来弥补的，是开发人员用时间和加班给他擦屁股的。开发人员除了日外包，哪一个人在开发过程中，没遇到需求矛盾或者模糊的时候啊，你去问需求人员，他告诉你的过程，试问是不是一个他知道自己错了的过程，如果开发人员忽视这个需求错误呢，用户以后提出来，谁来改。说不定开发人员的上级还要说开发人员不够认真呢，这就是需求人员犯错没事。所以需求人员不用想太多的原因，多跟用户在没有程序界面的沟通下，那么难吗？？

27 楼 ppgunjack 2011-01-17  

客户过来说做衣服，不给客户切二两肉的裁缝就算合格了
国内的公司跟着项目跑，跑需求的不懂实现，实现的不会面对客户，屠夫拉着当厨子，厨子拉着当马夫的多了，不用期望自己或者下属能当个类型2的裁缝，何况有些客户可能进了你的裁缝店开口就是来两斤肉
有能力能出快速原型的裁缝，不管是裁缝1还是裁缝2只要聪明点的都基本够摆平项目了
真要做需求，想办法弄几个老外的顶尖产品或者挖几个墙角研究研究，需求就解决一大半了
老外是产品驱动项目，边做产品边做标准，用标准裁剪需求，买了我第一代，你就得买我第二代
国内大多是项目驱动产品，人脉决定单子，吃了上顿没下顿，打枪换个地方
区别的本质原因就是国外好的企业sa，顾问都是1，20年工作经历的行业尖子，实现、业务和眼光俱佳，国内很多都是5-10年游击队，简历很耀眼，实现能力很狗血

26 楼 anky_end 2011-01-15  

gtssgtss 写道

amwiacel 写道

jiangduxi 写道

前一段时间面试过一个需求分析师的岗位，最后一个技术总监说需求分析需要有3年-5年的架构经验！大家也可以谈谈如果招聘需求分析该具备出业务，架构熟悉外的其他要求吗？

需求是业务活！那人讲的架构是业务还是技术？他是技术总监，那应该是系统架构吧！首先，这是二码事情，二来，他要懂业务和技术都熟悉的人！可是，真正有这料的人，难找！

不懂技术谈需求?谈完开发人员说实现不了,等着赔钱?

纯粹从技术上来说没有实现不了的，几乎可以这么说
唯一是看成本

公司够大往往需求人员是精通业务
但是小公司往往随便凑人

25 楼 gtssgtss 2011-01-06  

amwiacel 写道

jiangduxi 写道

前一段时间面试过一个需求分析师的岗位，最后一个技术总监说需求分析需要有3年-5年的架构经验！大家也可以谈谈如果招聘需求分析该具备出业务，架构熟悉外的其他要求吗？

需求是业务活！那人讲的架构是业务还是技术？他是技术总监，那应该是系统架构吧！首先，这是二码事情，二来，他要懂业务和技术都熟悉的人！可是，真正有这料的人，难找！

不懂技术谈需求?谈完开发人员说实现不了,等着赔钱?

24 楼 sleepinglord 2011-01-06  

lz的例子问题很大。我以为，情况大概应该是这样的（另一个学徒C去见客户)


C：老板你想做什么？
客户：我想做件衣服。
C：什么样的衣服呢？
客户：我也不是很清楚，只是我下星期要出席一个聚会，想做件新衣服。
C：有什么特别要求么？是晚礼服还是？
客户：不是很庄重的聚会，晚礼服就不必了，但是要显得精神一些，年轻一些才好。
C：颜色呢？
客户：嗯，不要太艳了吧。
…………
C获得了客户的尺寸以后，提出希望客户到店里去找一些衣服来试试看。
等客户到了店里，试穿了七八件衣服，仍然觉得不满意，但也都是些“这个是不是太老气了？”“这个蕾丝不好看，换一种样子。”这样的意见。
…………
后面的故事用软件的话就是，不断地提供原型（这个在裁缝铺来说成本太高了，但是在软件中太常见到），客户不断地提意见，最后才敲定某种样式。即便如此，做出来以后，客户仍然会提出“我需要配我新买的那条围巾，希望能在某些方面改改（仍然不会有具体整改意见）”这样的修改意见。

我想说的两件事是：
1.指望需求收集人员精通业务是不现实的：一方面太多的需求收集人员可能对业务了解仅限于表面，甚至一知半解；另一方面太多的业务你不真的去干上一年半载，根本无法了解。
2.我认为，在lz的例子里，A和B没有质的区别，只有量的不同。B因为比较熟悉业务，因此能在一开始提出更多的问题。但我以为需求最大的特性在于变化，永远不要认为收集到了全部的需求，也不能指望一次性地想到所有问题，即便你是个老裁缝。与其把精力放到一开始的全面，不如把精力放到如何适应变化。

据此，我的观点是：
1.用户通常不知道自己明确地想要什么，需要你引导用户来提，逐步引导用户说出他心中所想并明确之，而不是根据你的知识和经验来做问卷式的调查。你更多应该是倾听者的角色。
2.需求收集不是一蹴而就的，是一个长期的，变化的过程，因此应该拥抱变化，提高快速适应能力。
3.业务能力的提高是必要的，快速学习也是必要的，但不应要求需求收集人员有专家级别的专业水准和一线业务精英的业务水平（有当然更好，但不必要）！

菜鸟乱弹，欢迎拍砖。

23 楼 Dev|il 2010-12-26  

呵呵，这就是新手和老手的区别,老手能远观未来,而新手却想不到这么多,业务逻辑和重要

22 楼 jiangduxi 2010-08-09  

lihuachuan 写道

LZ的故事场景，感觉不是在和用户对话，而是在和领域专家对话
用户很多时候并不知道
三维是按照这个的基础上（+-0.5）是什么概念，
或者浅红色是什么样的，因为浅红色也有不下几十个的色值

这个时候就变成了要拿一个样板给用户看（这就要考验需求师的能力）
或者开发一个原型出来（这样当然比拿样板成本高了）
不然等你定型做出一件粉红色的衣服时，它要一件黑色衣服，那就亏了

该场景不是和领域专家对话。如果是的话，其引导方式有问题了。如果是领域专家的话，那么其实本质上那个需求分析人员就不会有那么多盲点了。领域专家会帮需求分析人员搞定！

用户很多时候是不知道，这就是需要需求分析人员了。他不知道是技术的实现，但是他知道他想要什么，只是不知道怎么实现而已！比如:  一个顾客点在饭馆里点了一个菜，他说要辣的口味。这个就是他的需求，他可能不知道你这个饭馆里面用什么办法让菜饭符合他的辣的口味，但是当他吃的是很就知道辣不辣。所以要引导的是你店里能够辣的作料，让他选择！

“三维是按照这个的基础上（+-0.5）是什么概念，”这个其实很简单当你和用户都不能很好的把握精度，那么就出现这个大于或者小于一个可接受的值。

“这个时候就变成了要拿一个样板给用户看（这就要考验需求师的能力）”：这个其实可以根据公司之前的一些已经有的功能或者一些模型暂时给客户看，这个本身不是需求分析师的能力而是该团队的案例。

“开发一个原型出来（这样当然比拿样板成本高了）”这个其实如果你一点都不明白用户想要做什么，这个原型可能会让需求分析人员发点时间。这个原型等同于伪代码！

21 楼 lihuachuan 2010-08-09  

LZ的故事场景，感觉不是在和用户对话，而是在和领域专家对话
用户很多时候并不知道
三维是按照这个的基础上（+-0.5）是什么概念，
或者浅红色是什么样的，因为浅红色也有不下几十个的色值

这个时候就变成了要拿一个样板给用户看（这就要考验需求师的能力）
或者开发一个原型出来（这样当然比拿样板成本高了）
不然等你定型做出一件粉红色的衣服时，它要一件黑色衣服，那就亏了

20 楼 jiangduxi 2010-08-09  

王者之剑 写道

有一个人，学了三个月裁缝出师了，就以为万事大吉了，客户上门了，问，你要做什么样的衣服阿，你想用什么样的布料阿，你想做成什么样式阿。

客户说，您看做什么样的合适，他做了，做的就是他师父教的那两种样式之一。
客户说，我想做什么什么样的，他不会做，说我给您推荐更合适的，推荐的就是他师父教的两种样式之一。

   切不可按照师傅或者书本上来做，师傅和书本上给出的是事务的内函，具体事务是可能内函是不变的诞生外延就有很多种了。原则是内函，灵活应变是外延。按照师傅教的或者书本上来的是呆板和书呆子。根本不适合去做需求。因为需求本身就是变于不变的合成体。师傅或者书本上给出的是不变的成型的。它是很难适应这种变于不变的合成体。但是你可以依据师傅或者书本上的成型体进行灵活应变。

19 楼 王者之剑 2010-08-09  

有一个人，学了三个月裁缝出师了，就以为万事大吉了，客户上门了，问，你要做什么样的衣服阿，你想用什么样的布料阿，你想做成什么样式阿。

客户说，您看做什么样的合适，他做了，做的就是他师父教的那两种样式之一。
客户说，我想做什么什么样的，他不会做，说我给您推荐更合适的，推荐的就是他师父教的两种样式之一。

18 楼 王者之剑 2010-08-09  

既然已经废话这么多了，那就再说两句
如果我去学做裁缝的需求

那么我的做法是
1.逛，大街，商场门口，写字楼门口，各种卖服装的。
  服装的风格，分类，对应什么样的人。（一周，目前为止，我上街从不关心这个）
2.学，学一些专业的知识，例如学术性的，什么样的人喜欢或者适合穿什么样的衣服。（一周，目前为止，我从不看这样的文字）
3.定，我服务一些什么样的对象，什么样的群体
4.看，客户来了，看客户目前是什么样的风格，试着猜测客户的职业，身份，爱好。
5.试，给客户推荐本店的几种风格款式，观察客户的态度
等等

信念：人靠衣裳马靠鞍，服装要能为客户加分

5分钟胡写，我想真要去搞个3个月，也会有些收获吧。

17 楼 王者之剑 2010-08-09  

这个例子非常经典，说明问题主要来源于软件开发人员不够专业。
现实中，即便是有名的裁缝，客户也可能会提出各种要求和问题，但这不会够成灾难。
要我去做裁缝，肯定栽了，要我做软件，目前为止还没有。
因为我对做裁缝没有兴趣，我对做软件，对通过软件系统解决问题最有兴趣。

我说的专业，首先是指一种态度，然后是指一些行动。
有积极的态度才能克服惰性，克服畏难情绪。需求搞不清楚，难道不是因为搞需求的人不想搞清楚需求吗？

态度：愿意学习新东西，不畏难。
行动：迅速学习新东西。

时时刻刻告诫自己：要有专业精神。

还有什么搞不定的吗？

如果让你白手起家，在一个比较复杂的行业中，估计要一年两年吧。但是你到的公司总有一些资料，总有一些经验，客户也不是抱着和你过不去的态度来给你钱让你做项目的吧。
我认为，你要是有积极的态度，不出三个月，你应该能比较好的做需求了。

如果系统有2000个功能，你看一个功能用10分钟，2000／（8＊6）＝ 40天

关键是你有兴趣深入了解客户的业务吗？

关键是你有不怕麻烦，自己就是来解决麻烦的这样的信念吗？

有的人提到钱的问题？
当你根据客户最开始的2个小问题，整理出100个功能需求的时候
你可以对这些功能进行分类，搞清楚这些功能之间的关系。
20个是最小的子集
其他的是不同程度的增强
我相信能说服客户先做哪些后做哪些。

见得多的恐怕不是整理出了100个功能，而是客户说两个做两个，再说两个，再做两个。
客户说要按电话号码查询，那就不给做按其它方式查询的，不给做也就罢了，心里一直担心客户会提按其它方式查询。

我有一个经验，你担心的事情多半会发生的。

16 楼 rocwon 2010-08-06  

需求。。
1. 行业知识
2. 分析方法
3. 沟通技巧

15 楼 jiangduxi 2010-08-06  

一蓑烟雨任平生 写道

需求分析师，按照产品实施公司的说法，一般叫功能顾问，我的体会是要在某一个具体的业务领域有5年以上的项目经验，至少独立承担过2个同类项目的功能设计和功能测试，能独立完成售前方案，如果是开发人员出身最好，但是技术背景并不是非常的关键。至于你们技术总监所说的需要3-5年技术架构的经验，那是胡嘞嘞，能做技术架构的未必能做功能，完全不同的2个领域。

赞成！我个人也觉得做需求分析师，必须具备很好的沟通和对业务有一定的熟悉程度。并且对该业务的大致功能点清晰。至于需要架构经验。我觉得有点牵强：不管是企业架构还是系统应用架构都不是简单的事情！做企业架构的一般站的高度一定不定，做应用架构技术也相当的牛。而不是告诉人家现在流行MVC使用SSH这样的程度！

14 楼 一蓑烟雨任平生 2010-08-06  

需求分析师，按照产品实施公司的说法，一般叫功能顾问，我的体会是要在某一个具体的业务领域有5年以上的项目经验，至少独立承担过2个同类项目的功能设计和功能测试，能独立完成售前方案，如果是开发人员出身最好，但是技术背景并不是非常的关键。至于你们技术总监所说的需要3-5年技术架构的经验，那是胡嘞嘞，能做技术架构的未必能做功能，完全不同的2个领域。

13 楼 cleanerje 2010-08-06  

现在阶段，缺的是钱！而不是能做这个工作的人。
第一种方法，用户也凑合着能穿啊！虽然质量用户不满意，但用户就愿意出那么多钱。
第二种方法，用户虽然爽了，可是用户不给你那么多钱啊！
一件衣服用户就给你100块钱帮他做。如果你用第二种方法给他做衣服，光时间成本你就耗不起了。自然没有哪个服务商用第二种方法来赚钱。

12 楼 amwiacel 2010-08-06  

jiangduxi 写道

前一段时间面试过一个需求分析师的岗位，最后一个技术总监说需求分析需要有3年-5年的架构经验！大家也可以谈谈如果招聘需求分析该具备出业务，架构熟悉外的其他要求吗？

需求是业务活！那人讲的架构是业务还是技术？他是技术总监，那应该是系统架构吧！首先，这是二码事情，二来，他要懂业务和技术都熟悉的人！可是，真正有这料的人，难找！

11 楼 jordanlc 2010-08-05  

个人觉得首先是要搞明白客户是想要干什么，就算考虑非常细致如果不理解客户用来干什么，百密总有一疏

10 楼 jiangduxi 2010-08-05  

前一段时间面试过一个需求分析师的岗位，最后一个技术总监说需求分析需要有3年-5年的架构经验！大家也可以谈谈如果招聘需求分析该具备出业务，架构熟悉外的其他要求吗？

9 楼 jiangduxi 2010-08-05  

一蓑烟雨任平生 写道

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

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

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

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

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