原创

挨踢项目求生法则(3)——需求篇

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://fireball.blog.csdn.net/article/details/9042125
摘要

知道什么是挨踢项目吧?什么!不知道?那IT项目知道了吧?为了不让客户踢、不让老板踢、项目组成员之间不互相踢,俺为大家分享一些减少被踢机会的心得体会。就算不能让项目成功,也至少不会死得那么惨吧!我将分团队建设篇、战略篇、需求篇、设计篇、编码篇、测试篇、实施篇和计划篇为你分享,本篇是需求篇。


什么叫挨踢项目?


IT项目,特别是软件开发项目,都属于“挨踢”项目的范畴。挨踢项目的几大特点:
1.需求不确定。
2.技术不确定。
3.工期限死。
4.预算限死

两大不确定和两大限死,你想不“挨踢”都难!


由“我要吃饭”的故事想到的

某天某客户跟你说:“我要吃饭!”
你非常关注客户这个需求:“请问您要吃中餐还是西餐呢?您想吃什么呢?”
客户非常开心,一下子说出了很多想吃的:
“西餐嘛,不错,听说那个菲力牛排很不错,配上红酒更加美味!”
“不过听说某某路的那个潮汕牛肉丸火锅,牛味很浓,牛气冲天……”
“哎呀,最近上火,还是不吃这些上火的东西了,吃日本寿司吧,听说那里有日本菜自助餐,有生蚝,正啊!”
“啊,不行哦,最近日本核辐射,海鲜还是不吃了”
……
最后客户说:
“你还是先弄一顿给我尝尝吧,见到菜才能提出具体需求啊!”
遇到这样的客户,你可能想找10个馒头塞到他嘴里面,让他撑饱,搞定!

当你搞了大半天需求调研,仍然不知道客户想吃啥的时候,客户终于露馅了:“你快点吧,我饿得不行了!”
原来客户想解决肚子饿的问题啊,你马上说:“附近有一家XX大酒店,里面的粤菜很不错,人均消费300元可以搞定!”
客户很开心:“谢谢您请吃饭,让您破费了!”
你傻眼了,需求调研费还没有收呢,还要请吃饭!你说:“不好意思,吃饭的费用需要您自己搞定啊,而且我们还要收10%的需求调研费!”
客户急了:“我只有10块钱啊!”
你气死了,10块钱的预算想吃这么多东西!于是你提出一个解决方案:“咱们去那个XX快餐吧,那里的饭和白粥是随便吃的!咱们是老关系了,我们再赞助您10块,也不收您需求调研费了。”
没等你说话,客户就抓着你的手奔向那个XX快餐了:“快点吧,我快饿晕了!”

以上故事纯属虚构,如有雷同实属不幸!

这个故事是软件项目需求工作的缩影,客户的表面需求似乎很多,而且变来变去,很可能是因为我们没有抓住“我很饿”这个根本需求。客户可能提出很多匪夷所思的需求,提出一些超出自己预算范围的需求,如果我们能抓住客户的根本需求,让客户认识到自己的预算限制,再加上我们高水平的发挥,我们是有可能做出能满足客户根本需求,并且符合预算的软件系统。


需求分析需求管理

我们可能经常听到一些关于需求方面的说词,如:需求开发、需求分析、需求调研、需求管理等等,下面将这些概念稍微梳理一下。
1)需求分析:
其他说法:需求调研、需求开发
关注点:如何获取和确认需求?
2)需求管理:
“双赢”:客户能赢,我们也能赢!在“双赢”的基础上,处理以下问题:
a)如何签署需求?
b)如何处理需求变更?
需求驱动地工作。
a)用需求指导计划、设计、编码、测试、实施等工作。
b)不做或少做与需求无关的事情。

需求分析和需求管理的工作,我统称为需求工作。需求工作中的问题有些是需求分析的问题,有些是需求管理的问题,或者是两者兼而有之。


法则1:搞清楚需要

解决肚子饿的问题,是客户的根本需求,客户的根本需求或者说需求之源泉,我称之为需要!如果客户是公费吃喝的,嘴馋想吃东西,那么满足这个需要的做法又不太一样了。
客户一般不会直接说出需要,往往提出的是他自认为能解决这个需要的某种解决方案。“我要吃饭”只是表面需求,透过这个表面需求,找到需要是需求工作的根本!我们需要思考:客户为什么有这样的要求?客户希望解决什么问题?如果找到客户的真正需要了,那么我们需要进一步思考:有什么简单的方法可以满足客户的这个需要?

客户的需要其实很少会变的,变的是那些表面需求,多问问我们自己:我们抓住了客户的需要没有?有些客户对自己的需要很清楚,但有些客户可能只有朦胧的想法,我们需要总结出客户真正想要的东西并与客户确认。


法则2:搞清楚限制条件

10块钱解决肚子饿的问题,和100元解决肚子饿的问题,差异可以很大,所谓的看钱吃饭!
如果我们能搞清楚客户的需要,其实10块钱也可以有比较完美的解决方案的,可以去大排档吃个面、炒粉之类的,不是不可以的。某牛筋丸汤粉,才10块钱,但有8个牛筋丸,味道好极了,而且可以饱肚子!
除了预算,系统的技术条件限制,需要与第三方系统接口等其他限制条件,也需要事先搞清楚。需要、限制条件要和客户高层达成共识,一起努力找出在限制条件下可以满足需要的需求解决方案。


法则3:持续确认


曾经有人问我,几十页甚至上百页的需求规格说明书,如何让客户确认?
我反问:这几十上百页的需求文档是闭门造车写了n天后,才给客户确认的吗?对于客户来说,该文档是从天而降,他之前没有见过其中任何的内容吗?
需求不是等全部写出来才去确认的,要持续地逐步地确认。我曾经做过一个项目,连续5天进行需求调研的工作,第5天几十页的需求文档写出来了,给客户签字确认,客户很快就签字了!这份文档的绝大部分内容,在之前的4天他都曾经确认过,第5天只是一个最终的确认而已。
持续确认好处:
1.能尽快发现问题,能帮助我们尽早确认需要,避免后期可能的需求变更。

2.客户能逐步消化需求。


法则4:不要“二手需求”

曾经有一个某政府部门的项目,系统是各业务部门使用的,但需求只能从信息科那里获取。信息科的人自认为很牛,对项目组说:“需求向我们要就可以了!”而这个项目上线后,具体使用系统的部门就是不买帐,最后这个系统由信息科验收了。
信息科提供的是“二手需求”,向客户调研需求时,一定要避免“二手需求”!

上述案例你可能会觉得有点好笑,其实“二手需求”在项目组内也经常会发生。
某测试人员问为什么要做这个功能?开发说:这个你不用管,你这样这样测就可以了……
某实施人员觉得某功能看上去不太符合逻辑,提出疑问。开发说了一大通实施人员听不懂的技术用语,然后实施人员只能憋着不说话了。
项目组的测试人员、实施人员应该接触第一手的需求,最好能直接面对客户,而不是通过开发人员转述需求。


法则5:成为业务专家


你可能遇到过这样的情况,客户经常抱怨软件不好用,然后我们问:如何不好用?客户好容易说出了一些要求,我们按照这些要求修改了系统,但客户总是不满意,总是说不好用。诸如此类,不断重复。
客户说啥,我们做啥,是比较落后的一种层次。我们应该处在客户的利益,提出超出客户想法的解决方案。要打造有竞争力的产品或项目,成为业务专家是必须的,不能偷这个懒,不要仅停留在需求调研这样的层次,而是要引领需求,给客户带来更先进的知识和管理办法。


法则6:需求是“设计”出来的


手机订餐系统的故事我经常拿出来举例子,大意是:
某公司有一个订餐系统,但高层要求在这个基础上做一个手机订餐系统,让外出工作或请假的同事可以方便定午餐。手机订餐项目组花了九牛二虎之力,终于弄出这个系统,但问题多多。高层领导很不高兴:这点小事都折腾这么久!后来有人说:外出工作或请假的同事,打电话回公司,让前台帮忙订餐不就可以了?
“解决不方便订餐的问题”是需要,而“手机订餐系统”只是可以满足该需要的某种解决方案,我们完全可以通过其他更加简单的方法来满足需要。我个人观点:除了需要是来自客户的想法外,系统要具体做什么功能之类的需求,不是通过问客户问出来的,而是我们根据客户的需要,理解了客户的业务流程后,并根据限制条件,设计出来的!当然客户提出来的想法,会给我们带来很多启发,但我们不应该仅停留在需求调研的层次,而是提供一个高性价比的需求解决方案。


法则7:七分需求分析,三分需求管理


遇到客户变来变去的情况,我们可能第一反应是:有没有搞错!当初就应该让他签字!最好就是录音!
如果我们连客户的需要都搞不清楚,就去抱怨客户需求变来变去,那我们的水平未免有点低了。其实真正很难缠的客户、不讲道理的客户很少的,只是我们水平未够,不能理解或找出客户真正想要什么,才让我们误以为客户变来变去。
需求工作可能有很多问题,应该以做好需求分析工作为主,而需求管理为辅,两者比例大概是七三开。需求分析工作做好了,需求的问题可以减少很多,而且客户也会非常认可你的专业水平,这样后续的工作就比较容易处理了。

当然也可能会遇到很难缠又不能绕过的客户,遇到这样的情况,建议你看看“挨踢项目管理求生法则(2)——战略篇”,如果从战略上判断该项目有很大问题,那么最好不要做这个项目,如果不幸要负责这样的项目,那么记住其中一个法则“输少当赢”。


作者:张传波

创新工场创业课堂讲师

《火球——UML大战需求分析》作者

www.umlonline.org 创办人

文章最后发布于: 2013-06-06 20:38:29
展开阅读全文
0 个人打赏

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 编程工作室 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览