关于需求

今天老大在晨会上给我们谈了谈需求,获益匪浅,记录于此: 

关于需求:

1、什么是需求?——理解需求和功能的区别

 我们举个例子,比如用手机打电话。首先,你需要开机,然后,手机通过无线电信号连接到基站,然后,打开手机通讯簿,找到小朱的电话号码,接着,拨号、通话,通话完毕,挂断

 在这里,打电话是一个需求。给小朱打电话是一个需求的实例(需求的实例,有时也称为应用场景,可以拿来做系统测试用例,但是不能只开发专门给小朱打电话的手机!)。对于手机软件而言,必须提供:开机、联网、通讯簿、拨号、挂断这几项功能,才能满足打电话这一个需求。

 我们在做软件的时候,常常会碰到:我已经做完了所有的功能了呀,为什么用户还是不满意呢?这就是将功能和需求混淆了。如果手机分别提供开机、联网、通讯簿、拨号、挂断这几项功能,而不通过打电话这个需求将这些功能有机的联系起来,你说消费者还会买这款“具备了所有功能”的手机吗?

2、需求是需要分析的

 需求来自我们的用户。但,用户说的不一定是他想要的,他想要的未必都说了出来(也许是他不能、不会),所以,需求需要分析。

 有时候路上碰到熟人,说:“小朱,有空吧?我请你吃饭去!”我其实有点饿了,但是习惯性的客气几句:“啊,不啦不啦,谢谢、谢谢,改天改天!”这叫做“口不应心”。这种场合当然是处于客气,但是,对于软件用户,由于不是计算机专业的原因,的确不能说出他想要的来。

 比如现在天气热了,用户对你说,“小朱啊,帮我买只冰激凌来!”如果我不假思索,跑去买了一只给他,他肯定说:“哎呀,我要的是巧克力味道的,你买的是牛奶的!”无语~~~只能跑去自掏腰包买一个牛奶的。如果是软件系统,那么就意味着加班赶工重做。。。

 好了,第二次,另外一个用户要买冰激凌,我这次学聪明了,先问:“您是要牛奶的,还是巧克力的?”他说,“巧克力的。”,我继续问:“那么是什么牌子的,准备买多少钱的?”“伊犁的,2块钱的那种。”好的,拿钱去买。

 心想,这次应该没有问题了吧?买了给他,一尝,他说了,“哎呀,不对,还是牛奶的比较好!”晕倒~~~

 到底要怎么样呢?

 第三次,又有人要冰激凌,我决定这样:“您为什么要冰激凌?”,用户说:“因为我口渴。”我分析了一下,在夏天口渴的话,冰激凌并不是解渴的,相反,甜腻腻的冰激凌吃了会更渴;什么东西解渴呢?冰冻的绿茶是很解渴的,于是,我说:“您口渴的话,我建议还是喝绿茶比较好。冰冻的绿茶更加解渴。”如果用户是理性的,他肯定会同意。于是我买来绿茶,口渴解决,项目圆满完成!

 如果用户不理性呢?最好的做法是不要让这些人成为你的用户。如果碰到了,解决的办法也很多,但通常都要付出代价。比如,同时提供小份的冰激凌和绿茶的试用装给他,他一试就知道要什么了。但是,我们却要付出制作小份试用装的代价。对于软件系统,这个代价有时候是很昂贵的。

 所以,请要将《需求规格说明书》作为《用户要求记录单》来用,应该先运用你的专业知识来分析一下。

3、需求是会变的

 通过分析、沟通,终于确定了一份需求文档,签了字,值得庆祝!但是,先别大意,因为需求肯定会变的。

 需求会变是一个现实,就像太阳每天东升西落一样。随着工作开展的深入和对于系统的熟悉,用户原来的想法肯定会和刚开始看一份抽象的方案不一样。既然不会不变,我们只能想办法来应变!(残酷啊,现实!逼得我们进化!)

 通常有2个手段:

  1)积极的沟通。及时了解变化,并进行变更控制管理。

 2)在系统的架构设计上,为变化做准备。面向对象也好、面向服务也好、三层也好、四层也好,我们为什么把代码分开层次,为什么提供那么多抽象的接口?都是为了应对变化,为了我们在这个需求像云彩一样变化的环境中能够适应。

 所以,在痴迷的学习这些架构、设计模式的时候,别忘记是为什么要学习他们。

4、保持沟通渠道的畅通

 说了上面一大堆,有一个前提还没有讲,就是和用户的沟通渠道。(当然同样重要的是公司内部的机制和沟通渠道,不过这不在本次的议题中,以后有机会再谈。)

 即使和用户争吵也比不相往来要好。需求是需要沟通来了解、来确认、来变化的。沟通,未必能够做好需求(原因多方面,比如用户对系统并不关心。。。);但是不沟通,项目就失去了成功的机会。

 无论无何,留住这个沟通的渠道,也许突然有一天用户对你说:“哎呀,你辛苦啦,上次提的那个功能不做算啦!”:)

 

posted @ 2006-07-14 14:23  文野  阅读(12747)  评论(15编辑  收藏  举报