小余

灵感源于交流,创新出自思考
posts - 50, comments - 864, trackbacks - 13, articles - 3

需求的陷阱--简单不简单

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

Feedback

#1楼 [楼主]   回复  引用  查看    

2008-06-02 13:31 by 小余(Yice)      
自己先鄙一下

#2楼    回复  引用  查看    

2008-06-02 13:35 by 无意      
mark 一下

#3楼    回复  引用  查看    

2008-06-02 13:41 by kiler      
lz的例子很有趣的说。
我觉得要避免这种陷阱,开发人员应该尽可能的去学习客户的业务,多和客户沟通,多了解客户,才能给客户提出一个合理的解决方案。

这个例子的老板的错误就是缺乏和客户的沟通,客户只是问“有没有100个面包”,老板就主观的断定客户要买100个面包。自作主张帮帮客户做决定,其实这种错误在开发里面貌似还是不少的。

#4楼    回复  引用  查看    

2008-06-02 13:41 by 无意      
你说的很有道理,我现在就是在做公安的需求,业务上很多的不懂,烦死了,
也是第一次一个人做需求。

#5楼    回复  引用  查看    

2008-06-02 13:50 by kiler      
@无意
看不懂就和客户多聊聊,问问他们现在的业务现状是什么,了解一下他们现有业务流程最麻烦的事情是什么,把你自己当成一个客户去想象你的系统能为客户解决什么问题。

#6楼    回复  引用    

2008-06-02 15:01 by 匿名 [未注册用户]

最近做的一个项目,上个公司做了一年半,放弃了.原来定三个月完成,我们又做了一年半多,还离结束遥遥无期.老板都急了,有什么办法.公司给客户的权限是想提什么要求都可以,需求/设计,甚至人员调配都是客户说了算,惹不起啊.只有总结为什么完不成的时候,是开发人员的责任,扣奖金.有时候一个需求可以反复做几遍,只要客户乐意,前面提的要求,用不到一天就又变了,返工是家常便饭.
而且,只要改动不论大小,即使是改一个按钮文字,都要在改好之后给客户演示一遍,并且讲一下改了什么(人家提完要求就忘记了啊).最大的特点是客户是个领导,但是按照他的要求做的程序,下面的人不买账,人家不用啊.开发人员还要求爷爷告奶奶的去让人家用.有的钉子户坚决不用,项目一拖再拖.

这项目做到这份上,博主帮忙分析一下,谁之过?项目如何才能结?

#7楼    回复  引用  查看    

2008-06-02 15:42 by 红尘中迷茫      
@匿名
公司给客户的权限是想提什么要求都可以,需求/设计,甚至人员调配都是客户说了算,
------------------------------
就凭这句还分析什么呀。你们老板也太。。。。

#8楼    回复  引用  查看    

2008-06-02 15:52 by 赵俊      
@匿名
公司给客户的权限是想提什么要求都可以?那就好办了,跟客户耍嘴皮子,讲到他们点头,我们这边市场人员素质就是高,他们跟客户讲故事的时候我在旁边听的一愣一愣。

#9楼    回复  引用    

2008-06-02 16:03 by caoruijun123123 [未注册用户]
针对楼上这位老兄的问题,估计绝大多数开发者都遇到过,只是没有你说的这么严重罢了。我想你们每次需求的变更都是以文档的格式记录下来的吧,并且更改之前都有专门的需求人员和客户分析过,那如果这样还经常改动,那完全可以拿着需求变更的历史记录和客户去谈。

#10楼    回复  引用  查看    

2008-06-02 16:14 by Leem      
楼上的那有这样做的,这样你们还不累死阿.

#11楼    回复  引用    

2008-06-02 17:06 by 匿名 [未注册用户]
--引用--------------------------------------------------
赵俊: @匿名
公司给客户的权限是想提什么要求都可以?那就好办了,跟客户耍嘴皮子,讲到他们点头,我们这边市场人员素质就是高,他们跟客户讲故事的时候我在旁边听的一愣一愣。
--------------------------------------------------------
我们在公司顶多算个工人,人家是领导,公司老板见了都要让三分的,不平等的地位,我们去了只能照要求做.做的不好,还骂的跟孙子似的.这一年半做的那叫累啊.

除了跳槽,真没有什么办法了?

#12楼    回复  引用    

2008-06-02 17:27 by www.chinacmsb.cn [未注册用户]
这个例子 真形象~~~

#13楼 [楼主]   回复  引用  查看    

2008-06-02 18:53 by 小余(Yice)      
--引用--------------------------------------------------
kiler: lz的例子很有趣的说。
我觉得要避免这种陷阱,开发人员应该尽可能的去学习客户的业务,多和客户沟通,多了解客户,才能给客户提出一个合理的解决方案。

这个例子的老板的错误就是缺乏和客户的沟通,客户只是问“有没有100个面包”,老板就主观的断定客户要买100个面包。自作主张帮帮客户做决定,其实这种错误在开发里面貌似还是不少的。
--------------------------------------------------------
嗯,沟通在任何环节中都非常重要,闭门造驹岂能成功

#14楼 [楼主]   回复  引用  查看    

2008-06-02 18:54 by 小余(Yice)      
--引用--------------------------------------------------
无意: 你说的很有道理,我现在就是在做公安的需求,业务上很多的不懂,烦死了,
也是第一次一个人做需求。
--------------------------------------------------------
虚心学习,不懂就问,切莫不懂装懂。

#15楼 [楼主]   回复  引用  查看    

2008-06-02 18:55 by 小余(Yice)      
--引用--------------------------------------------------
匿名:
最近做的一个项目,上个公司做了一年半,放弃了.原来定三个月完成,我们又做了一年半多,还离结束遥遥无期.老板都急了,有什么办法.公司给客户的权限是想提什么要求都可以,需求/设计,甚至人员调配都是客户说了算,惹不起啊.只有总结为什么完不成的时候,是开发人员的责任,扣奖金.有时候一个需求可以反复做几遍,只要客户乐意,前面提的要求,用不到一天就又变了,返工是家常便饭.
而且,只要改动不论大小,即使是改一个按钮文字,都要在改好之后给客户演示一遍,并且讲一下改了什么(人家提完要求就忘记了啊).最大的特点是客户是个领导,但是按照他的要求做的程序,下面的人不买账,人家不用啊.开发人员还要求爷爷告奶奶的去让人家用.有的钉子户坚决不用,项目一拖再拖.

这项目做到这份上,博主帮忙分析一下,谁之过?项目如何才能结?

--------------------------------------------------------
这个现象可以说是比较特殊,但也不少件,看来明天该再写一篇来讨论这个问题。

#16楼    回复  引用  查看    

2008-06-02 19:31 by Vincent      
--引用--------------------------------------------------
匿名:
最近做的一个项目,上个公司做了一年半,放弃了.原来定三个月完成,我们又做了一年半多,还离结束遥遥无期.老板都急了,有什么办法.公司给客户的权限是想提什么要求都可以,需求/设计,甚至人员调配都是客户说了算,惹不起啊.只有总结为什么完不成的时候,是开发人员的责任,扣奖金.有时候一个需求可以反复做几遍,只要客户乐意,前面提的要求,用不到一天就又变了,返工是家常便饭.
而且,只要改动不论大小,即使是改一个按钮文字,都要在改好之后给客户演示一遍,并且讲一下改了什么(人家提完要求就忘记了啊).最大的特点是客户是个领导,但是按照他的要求做的程序,下面的人不买账,人家不用啊.开发人员还要求爷爷告奶奶的去让人家用.有的钉子户坚决不用,项目一拖再拖.

这项目做到这份上,博主帮忙分析一下,谁之过?项目如何才能结?

--------------------------------------------------------
记得我在一个企业做mis的时候遇到过类似的问题:
1,部门主管A要求上一个系统方便对下属子部门工作效率的考核,所以提出需求来开发系统,此时我们面对的客户是A.需求也只是A.
2,当实现了A的需求后,要求部署下去,让各个子部门去应用,并完善系统.
3,子部门领导B,认为这个系统对他们来说并不会提高什么,反而自己的工作还被上级更有利的监督起来.所以他从思想上是不希望这套系统能够部署起来的.
4,B在看完系统的演示后,提出需求,我们开始修改.
5,由于B是反对上系统又迫于压力不能直接反对上级决定的情况下,每次新需求修改结束后,他都会提出新的问题要求继续修改.
6,mis部门主管询问,为什么这个系统经历这么长时间还不能上线,B回答"你们一直都没有开发完".
7,1年半后,部门主管A发现B的工作有问题,辞退了B.由此我们才被真正的解放出来.(辞退B由于别的原因,而在辞退B后A才明白原来B一直在为这个系统的开发人为的制造障碍.)
8,我们经历了1年半的痛苦煎熬,我们的主管从开始怀疑我们的能力,到干脆对我们不报任何希望,到最后的真相大白.我们要承受多大的压力.

谈需求,是建立在对方需要你来帮助解决问题的先决条件上的,如果没有这个先决条件,也就没什么可谈的了.

#17楼    回复  引用  查看    

2008-06-02 20:56 by 皇帝的新装      
从来没有需求

#18楼    回复  引用  查看    

2008-06-03 00:06 by 求知无傲      
有时间再细细品读。

#19楼    回复  引用  查看    

2008-06-03 09:13 by 巫云      
很多时候买卖双方的地位就是不平等的,必然有强势和弱势的区别。必须通过具有中国特色的社会主义的特殊手段来摆平。

#20楼    回复  引用  查看    

2008-06-03 09:32 by Beginor      
同感,正在闭门造车。

#21楼    回复  引用  查看    

2008-06-03 12:15 by 水言木      
好文,顶!!!

#22楼    回复  引用    

2008-06-03 12:56 by 随便说说 [未注册用户]
--引用--------------------------------------------------
匿名:
最近做的一个项目,上个公司做了一年半,放弃了.原来定三个月完成,我们又做了一年半多,还离结束遥遥无期.老板都急了,有什么办法.公司给客户的权限是想提什么要求都可以,需求/设计,甚至人员调配都是客户说了算,惹不起啊.只有总结为什么完不成的时候,是开发人员的责任,扣奖金.有时候一个需求可以反复做几遍,只要客户乐意,前面提的要求,用不到一天就又变了,返工是家常便饭.
而且,只要改动不论大小,即使是改一个按钮文字,都要在改好之后给客户演示一遍,并且讲一下改了什么(人家提完要求就忘记了啊).最大的特点是客户是个领导,但是按照他的要求做的程序,下面的人不买账,人家不用啊.开发人员还要求爷爷告奶奶的去让人家用.有的钉子户坚决不用,项目一拖再拖.

这项目做到这份上,博主帮忙分析一下,谁之过?项目如何才能结?

--------------------------------------------------------
重大需求有变化时要形成文档,然后客户签字。功能验收就已文档为准,以后需要再更改加钱,否则不管。
还有就是对于“人家提完要求就忘记了啊”,其实你们在演示的时候,客户也许脑子一热就提一些要求,这个好办,所有客户提出的修改建议必须落实到文字(客户写功能修改说明),必须客户写该文档,这样他们就不会随便提出修改建议了(因为怕麻烦)。

#23楼    回复  引用  查看    

2008-06-03 14:20 by 风海迷沙      
小白免,出来见上帝。

#24楼    回复  引用  查看    

2008-06-03 16:03 by John Rambo      
我们其实就是买东西的。
买东西的关键在于说服客户买我们(能做的)的东西,而不无限探索客户的需求。
we are not god damn 赛靠类这斯特。

#25楼    回复  引用  查看    

2008-06-03 17:59 by 墙外行人      
受教啦

#26楼    回复  引用  查看    

2008-06-10 13:35 by Dorian Deng      
@Vincent
多与用户沟通,沟通不成,直接向双方领导上报情况,没有人的青春可以浪费。

#27楼    回复  引用  查看    

2008-08-09 11:10 by 毁于随      
楼主写的很好.我也挺有感触的,现在这个项目就是在需求非常不明确的基础上就开工了.究其原因,确实不是一件简单的事,客户对开发公司的压价,公司为了能够做二期或者三期的工程,对于深层次的需求又让我提出来.开发的过程中,难免要进行猜测客户的需求,为了应对客户需求的变更,程序的结构上要做得更灵活的能够应对需求(这其实也挺煅炼人的),真的很是头痛.现在这个项目也要上线了,还不知道会出现什么后果.顺便说一下,这个项目用的一个ORM的方案真是让我头疼呀,PD带的一个源码级的东西.