首先,重要的一个问题是,为什么要做需求分析,或者说需求分析的意义是什么?每个人对这个问题可能都会有不同的体会。我的看法是,需求分析的意义在于准确无歧义地表达项目需要交付的产品,并且获得需求方的认可,从而为整个项目建立一个基准。指望需求不变化是几乎不可能的,不管是开发者还是需求方都有可能随着项目的进展提出变更的需求,所以需求分析(及变更管理)的目标不是定义一个不会再改变的需求,而是从开发开始到项目结束,双方对于需求(包括变更后的)的认知都是一致的。 yixieshi.com
  这样说可能有点抽象,我们可以来拿一个例子进行说明。
  比如项目初期形成的需求分析中有这样一段描述:“应用系统能够根据预先定义的个性化模板,定期自动对每条用户的数据生成对应的pdf报告文件,并发送到在用户信息中预先设定好的电子邮箱中。”
  针对这条需求,开发人员找到了一个自动生成pdf文件的插件,这个插件会读取一个xml模板,然后根据传入的数据生成pdf文件。一段时间后,功能做好了,用户的项目经理看了生成的pdf觉得不错,项目进展顺利。
  可是,到了阶段验收的时候,用户组织了一段时间的试用,对这个功能大家都觉得不满意,因为普通用户根本不会编辑xml模板,觉得很麻烦,而且容易出现格式错误。这时,用户提出应该提供一个编辑界面,让用户以所见即所得的方式来编辑模板,这也是很自然的。 互联网的一些事
  问题来了:开发人员认为这是对需求的变更,需求里没有提到要做这么个界面嘛!这样会导致项目的进度、预算都需要调整,也许有人还会要求用户增加开发费用。而用户会认为这是开发的工作没做好,怎么能做个功能出来让用户自己编辑xml呢?一百个用户里也难找出一个用户知道xml是啥东西,更别说编辑它了。所以双方会在这个问题上纠缠不清。而这只是整个项目中很小的一块需求,一叶而知秋,其他部分的问题也肯定少不了。
  这里面到底是用户不讲理,还是开发人员偷懒?其实都不是,我觉得问题出在需求定义得不严谨。如果开发人员在需求分析过程中和用户交流过模板的格式问题,用户会在第一时间明确模板编辑的需求,这样写出来的需求可能会是这样的:“应用系统能够提供pdf模板编辑功能,让用户以所见即所得的方式自行定义个性化模板,根据该模板定期自动对每条用户的数据生成对应的pdf报告文件,并发送到在用户信息中预先设定好的电子邮箱中。”这样的需求更严谨,事后出现争议的问题减少了。当然,你还可以在里面找出一些不够严谨的地方,比如“定期”是什么概念,固定一周一次还是一月一次,还是用户可以自定义,或者是提供几个标准选项让用户自选?所有这些不明确的定义,都是需求分析过程中要重视的。除非你对于它的不确定性及其可能带来的坏结果有充分的把握,否则忽略它会在未来给项目带来麻烦。
  小结一下我的想法:在项目中,用户的字典里是单证、收入、报表、审核等,而开发人员的字典里则是键值、索引、按钮、事件这些,而需求分析像是一位翻译,把用户的语言和开发人员的语言融合到一起,让双方准确理解对方的意思,从而在开始开发工作之前让双方都真正明白对方的思路。
  对于需求分析中关键的因素,我自己的体会主要有如下三点:
  一、深刻理解业务
  需求分析人员需要对用户的业务有非常深刻的理解。所谓非常深刻的理解,是说你能和用户的管理层他们的业务问题谈笑风生。如果做金融产品不懂风险管控,做论坛不懂SEO,做人事系统不懂组织行为,如何能对业务有深刻的理解呢?
  有人看到这里要说了,用户给我讲明白需要做什么功能行了,我对他的行业了解那么深有什么必要呢?我想说的是,做需求分析也是分很多层次的,层次越高,需要对业务的理解越深。
  我再举一个例子吧。某个项目要开发一套企业管理系统,客户是一个企业集团,下属很多分公司,都在做多条产品线业务,集团对分公司的业务管理一盘散沙的问题很头疼。之前的做法是每个分公司每个月底将每条产品线的业务报表传真到集团,然后集团进行业务统计。现在客户提出的需求是,在每个分公司都部署一套和集团一样的业务管理系统,并在集团的平台中做一个数据上报模块,让各个分公司都可以从自己系统中导出电子版数据并上传给集团,从而提高接收和统计的效率。
  “还可以”的需求分析能够把这个需求准确描述,严谨定义,让开发人员开发出用户满意的功能。“比较好”的需求分析则可以更进一步,和用户探讨是否可以做成一套大集中的系统,分公司无须上报可以让集团随时看到各个分公司的业务状况,从而杜绝虚报瞒报数据的问题。“更好的”需求分析也许可以和用户探讨通过信息系统的支持实现矩阵化的业务管理,在不改变组织结构(因为组织结构问题已经超出需求分析的范畴,甚至超过了项目范围了)的情况下,提高集团对各条业务线的宏观管理能力,从而更好地落实集团对于各条产品线的战略。
  也许有人还有“更更好的”业务分析,但你可以看到,越深入业务的分析结果对于用户的价值越大,用户对整个开发团队的认可程度也会更高。这对于项目的成功是非常重要的。如果客户很感谢你提出了让他能加强业务管控能力的方案,他还会和你纠缠菜单的颜色够不够好看么?

  二、充分和用户沟通 互联网的一些事
  首先要搞清楚你有哪些用户,他们之间的关系是怎样的。有句老话叫众口难调,用户之间的观点也会有冲突。比如高管希望采集的数据越多越好,现在用不上将来可能弄个数据挖掘工具突然有奇效了也说不定;负责采集数据的一线用户当然希望数据越少越好,只要自己够用行了。有些业务部门不希望自己的业务数据被太多人知道,有些项目甚至会让一些部门失去权力,一些领导丢掉职位。所以在一个项目里,需求讨论会上往往会有各种各样的声音。声音后面是立场,立场后面是利益。缺乏经验的需求分析人员很容易迷失在这些声音里,后做出来的需求成了四不像,而这正是某些用户希望看到的结果。
  这时候怎么办呢?老码农俺有一个秘方:找用户大的领导讨论项目的整体思路,然后按大领导的意见把用户需求筛选一遍,凡是和大领导思路明显冲突的一律扔到一边,把符合大领导思路的那些需求充分细化。啥叫大领导?不是什么IT部经理、信息处处长、客户项目经理之类的,而是能拍板决定和这个项目相关的业务问题的人,比如做人事系统,大领导至少是人力总监,做财务系统至少是财务总监,当然能再往上让一把手积极参与进来更好了。和大领导讨论的过程,既是了解大领导思路的过程,也是筛选需求的过程,更重要的是,获取大领导支持的过程。有了大领导的支持,再开会的时候,底下吵吵嚷嚷,你也能气定神闲,胸有成竹。
上一页12下一页
本文内容不用于商业目的,如涉及知识产权问题,请权利人联系SPASVO小编(021-61079698-8054),我们将立即处理,马上删除。