您的位置: 网界网 > 周报全文 > 正文

[周报全文]让需求更模糊一些吧

2006年12月20日 17:07:26 | 作者:○ 网络世界特约撰稿人 刘庆 | 来源:$page.getBroMedia() | 查看本文手机版

摘要:

标签

         站在需求方,或许总是会有一种感慨,就是觉得实现者不理解自己。而实现者也有诸多抱怨,觉得为什么需求总是变来变去的。总体来看,如果说后者希望需求是稳定不变这一点不太现实的话,那么,前者不假思索地就提出一个需求也未免不太负责任。

         前几天,客户要做一项分析,需要提取某些数据。我就写了一封邮件,用文字方式表述自己的需求,让同事帮忙提取数据。第二天一看,结果吓了一跳。因为提供来的东西跟我想象的不太一样,有一堆乱七八糟的记录在里面。按道理,那些都是应当剔除掉的。

         那么,问题出在哪里呢?是我没有描述清楚,还是SQL写错了?于是,我重新检查那封邮件,发现在表达方面确实存在很多不严谨的地方。例如“非移动号码”,这并没有一个标准说法。在数据库里面,有多种号码类型,可以通过好几个字段区别出来“非移动”,比如从品牌、从运营商都可以。那么,该用哪一个来统一口径就成了问题。

         另一个问题是,在我的文字描述里面还漏掉了一些限制条件。例如,对于本地的号码需要单独取出,但忘了说明。如果是在实际写脚本,应该是忘不了的。但写这封邮件的时候,并没有深入到细节,用那种写SQL的思路去写这段话。

         不得已,我只好补充了一些约束条件,明确了统计口径,再重新取数。结果却发现,这样做了之后,提取的信息仍然不能满足分析目的,早知道应该多提取一些字段。可惜的是,一开始并没有意识到哪些信息有用。再深入一些看,发现数据的时间周期也没有说明清楚,只是提出要某种数据,却没有说明需要哪个月份的数据。但问题是,如果我真的将这些都考虑清楚的话,那就跟自己写一段脚本差不了多少。如果这是一项常规的工作,倒还值得,可以形成需求书,并且将脚本纳入流程。但如果是一次性的提数,将描述需求和技术实现分开,是否仍然值得呢?

数据的供求矛盾

         于是,我就联想到那些市场部的人,很多也都是向IT部门提取数据,对于统计口径,同样也存在着太多模糊的说法。比如前一段,一个地市公司的市场分析人员打电话,要为经营分析会议准备数据,他们的IT系统办不到,便找我们帮忙。由于事情紧急,便先在电话里头说了。他告诉我,要取“10月份某种套餐生效的用户收入情况”,并且确认了一系列口径,例如“收入情况”应该包括哪些信息、哪些套餐之类的。挂了电话,一旁的同事又想起来,什么叫作“生效”?是指10月份新办理的生效,还是10月份所有有效的?

         如此这般,往往问清楚了这个问题,又出现一个新问题。通过电话来来回回确认好几次,才慢慢把这个口径确认清楚。但即便如此,当我们再继续往深入想的时候也发现,其实他们提出的这个需求恐怕还是不能完全满足实际所需。因为我猜测,他们之所以提取这个数据,是为了证明这个套餐的创收能力,但如果没有对比也说明不了问题,也许需要几个月的历史数据。但这时,数据脚本已经开始运行,时间也来不及了。最终,我估计,等他们接到这个数据之后,可能就会发现信息还不够。当然,也可能因为不好意思再折腾我们,便凑合着用了。

         实际上,这里存在的一个问题就是:将业务描述与技术实现同步的难度很大。解决的途径基本上有几种:一是从沟通层面入手,业务的、技术的人一块干活,出现对描述模糊的地方,口头沟通澄清即可。不过这往往也不太现实,除非是在一个项目里面还有可能。二是在业务描述的技巧上面,要求做需求描述的人(+微信关注网络世界),尽可能准确表达自己所需,不要太多的反复。三是从职责上面解决。比如分析人员让数据库人员帮忙提取数据,技术人员写好脚本,调整两次以后,如果发现结果还是不能满足需求者(因为每次需求者都会根据现有数据想到新的分析角度),那么,也许应该将脚本交给需求者自己来DIY了。当然,这需要他具备这个技能。其四,还有一种“远水解不了近渴”的方法,即建立一个从业务语言到技术语言的标准,让业务描述更加准确。例如说“非移动号码”,反映到SQL条件上就是某个字段not in(a,b,c)。而之所以说这是远水,因为这实在不是一日之功,需要长时间的准备和规划。

         站在需求方,或许总是会有一种感慨,就是觉得实现者不理解自己。而实现者也有诸多抱怨,觉得为什么需求总是变来变去的。总起来看,如果说后者希望需求是稳定不变这一点不太现实的话,那么,前者不假思索地就提出一个需求也未免不太负责任。

超越需求的真正价值

         做需求分析的人都熟知一句口号,即“了解需求还要超越需求”,话说着简单,可超越并非你想超就能超的。举例来讲,去分析客户需求背后更深层次的需求,可以算是一种超越。比如说上面提到的那个例子,一个提取“10月份某种套餐生效的用户收入情况”的需求,指出了需要某些字段的数据,这其实将我们的价值降低了,让我们变成一种干苦力的了。因为这个需求比较死,不需要动太大的脑子。分析一下,其实客户需要的并不是这个数据,他们的目的可能是想证明某种套餐带来不错的效益。将这个作为需求,应该提取什么数据,如何证明,那是我们要做的事情。当然,如果就事论事的话,在短短一个小时之内能够满足他们的,也就是死板地提取数据而已。不过,这也表明,我们在他们那边没有体现自身价值,不然怎么不早说呢。

         如此,从另一个角度出发我们可以这样说:一旦一份需求被客户描述的非常清楚了,满足需求者的价值就降低了。

1
[责任编辑:程永来 cheng_yonglai@cnw.com.cn]