关于需求-是啥?为啥?

又一次简历受挫

每每看着招聘网上上"需求,分析,咨询,IT"关键字下的一摞摞的搜索结果,都让人提不起精神

干了四年了,业务经理也干了一年,带领着小20的团队,不敢说一点问题没有,但总还是有条不稳的引领这一个需求团队混杀在纷争复杂的各种斗争之间

想想之前来公司,文分需求,理分编码,傻乎乎的跟着大家一起干起了需求.

公司给培训,师傅给教方法,自己不断实践,总算是对需求是什么,怎么做有个小想法,懵懵懂懂的过了四年

平日里也会有些困惑,比如,同学/朋友问起你干啥的,我说做需求的,然后人家就困惑了,需求?需求是个啥?销售么?市场么?咨询么?然后再我费尽巴拉的说了一堆,我的工作内容之后,大家恍然大悟的说"哦,是跟软件开发有关是吧",于是索性,我以后就说"我是做IT的",然后大家也就不问了

平日里还有这样的困惑,每每看着编码,架构,QA的纷纷跳槽,各各飞出鸡窝进鸾庙,我也蠢蠢心动的,搜索职位,然后就出现,要不就是没有行业背景,要不就是不是计算机专业,除了AUTO-REPLY的,还有几秒迅速被PASS给回执的,总之,一个结论,您这样的,我们不需要

于是动起了写点东西的欲望.以我的理解,什么是需求,为什么做需求,怎么做需求

什么是需求?

我们团队很有意思,有来自业务部门的人,有做过需求的人,有做过设计的人,有做过编码的人,有做过测试的人.在一个需求团队中,你会发现这样那样有意思的冲突.

场景一: "这个用户不关心!"

每每有技术组/测试组的跟我抱怨,"XX脾气不好,总是不说清楚,一问到细节问题就总是说'这个用户不关心!'"

通常情况下,总是来自业务部门的人会出现这种问题,前台点个钮,后面批处理,里面怎么做,跟我没关系.最后结果对了就OK拉,想怎么设计怎么设计,你们想去吧

有意思,因为通常跟操作层用户调研时,你会听到相同的话. 我们不把这种没有分析过的东西叫需求,我们叫业务操作

场景二:"IF...ELSE..."

每次拿起业务规则文档,长篇累牍的IF...ELSE...,我就把需求人员叫来问,这个想要实现什么目的牙...然后需求人员就把这个逻辑给我复述了一遍...于是我随便指出一个步骤,挪挪顺序行不行牙,拆这么多步要干嘛牙,然后逐渐逐渐,才明白想要实现的业务规则是什么

通常情况下,总是做过设计的人,比较容易犯这样的问题,我都设计好了,您技术别改了,就我这个来吧

有意思,详细设计全省了,直接上来编码吧

场景三:"这个用例不是我的,你去问XX!"

又是每每有技术组/测试组的跟我抱怨,"问一个业务流程弄不清楚,功能之间不知道怎么互相影响的"

通常情况下,出现问题最多的是做过编码的人,我这摊是我这摊,别人摊的你问别人去

有意思,技术测试给弄的团团转,问了几个人还是不知道这流程要干嘛

场景四:"客户需求就这么写的"

也见过几个项目的客户需求,有的写的很笼统,有的写得很详细.现在这个项目的客户很成熟,把客户需求全写成了用例,规则写得很清楚. 于是,会发现,需求里面的句子,从客户需求COPY到了系统需求中,完全的忠于原著

于是开发测试脑仁儿疼了就找我抱怨,这个逻辑怎么回事

呀呀呀,我赶紧打开客户需求和系统需求一看,人家客户需求说简洁了,给理解偏了...

做需求的嘛,还是要动点脑子去调研的

任何一个事物的发生都不是偶然的,不是没有原因的,对需求的理解是在做需求之前就必须明确的

需求为何物? 个人感觉,客户需求是沿用PMP的概念,发起人,客户,(用户),其他干系人已量化并且记录下来的需要和期望,是开发团队与用户/客户订立的契约,;而系统需求是已被精化梳理后的客户需要和期望的二次确认,也同时是指导开发的可被分解实施的单个业务目标的集合.

举个简单的例子,什么是业务?就是口渴了要去解渴.什么是客户需求?就是当嘴唇发干,那么就需要找水,什么是系统需求?就是,口渴了一定嘴唇干么?还有没有其他的症状呢?有更好的衡量标准么?一定要喝水么?别的饮料可以喝么?找不到水呢?等等,等等.都是系统需求需要分析清楚的.

经过一系列的分析,我们会突然发现,客户需求也许只是在描述一种客户/用户体验到的场景,真正的需求隐藏在这个现象背后

为什么做需求?

很多小项目或者小SCRUM,需求感觉瞬间就做完了,通常项目经理又当爹又当妈,管着项目进度,同时了解分析需求.

需求的时间可短可长,不过以为需求工作可以被弱化,我觉得就大错特错了

前段时间跟架构组一起开会, 上来按照自己的理解了解了业务模块,就开始扎进解决方案了.结果,转一圈,这个需要先对需求了解了,那个需要先明确系统需要什么功能,又绕回到了需求

需求就像是路边灯,只有按着灯的亮才不会栽到水井里. 不然就摸着黑走夜路,不知道走到哪里去了

也有的说,很多小项目,直接拿到客户的要求就编码,做完了给客户瞅瞅,不行再改

我也非常同意,需求工作的开展从来不是跟项目割裂开的,既然如是,那么是把需求文档写全了,再开发,还是需求开发一起做,最终不过是要经济有效率的完成项目. 但是我一直以为,拿开发出的产品找客户确认的过程和把原型拿出来给客户确认的过程,都一样是需求工作的一部分,谁来做,怎么做,可以根据项目的情况具体来分析