需求分析,在大公司可能并不需要项目经理主导,有专门的需求分析师和架构师去完成这个工作,中小公司可能仍然需要项目经理充当主角,由项目经理负责与甲方业务人员共同完成需求的收集、整理以及分析工作。
不管哪种情况,项目经理都必须对业务充分了解,只有这样才能更好地把控项目的进度,而且了解业务的最佳场合就是需求搜集阶段,这个阶段可以和甲方业务人员充分接触,充分了解对方的业务。
很多项目经理是从开发工程师转变而来,对什么是业务有些人云亦云,很多人只要一谈到业务就立即联想到系统和平台,这种做法有些欠妥。我们说的业务,是指甲方的业务,换句话说就是甲方每天干的工作,但是,我们显然并不需要了解全部,而只是一部分,而系统只是对这些业务的线上体现。为了充分理解甲方的业务,我们需要在需求分析阶段获取很多的信息,下面我针对这个阶段的工作提一些建议:
1、首先我们需要准备一些必要的工具,本子、笔、录音笔、照相机、文件夹等是必须的。很多人就带一双耳朵,回来全凭回忆,这是不建议的;
2、准备一些需求分析文档的模板,输出文档一定要正规化;
3、准备好调研清单,这份清单不是苦思冥想出来的,要有根据。在制作清单之前,我们先要初步了解对方的业务,主要是依据对方的网站或搜索出来的零星资料,顺便了解一下对方有哪些系统。然后根据这些了解到的内容结合自己的理解,形成调研清单。清单中的内容很多,我这里也无法一一列举,这里给大家一些常用的方法,了解对方都有哪些部门,就是组织结构。了解对方的产品是什么,实际上就是生产什么?了解生产过程如何?概括起来就是过程、操作者、输入、输出。抓住这几点,基本上就可以理清思路。
另外,清单上也要问及对方的IT建设情况,为后续的平台部署做好准备。
4、准备一份申请书,向对方申请调研,上面有调研日期、天数、调研对象(部门或个人)、调研主题、调研方式、日程安排等。
5、将申请书和调研清单提交本公司领导和销售,一般会由销售和对方联络人进行沟通,约定时间;
6、调研时一般会按照申请书上的调研计划去进行,如有临时变更的,一定要提前和对方商议,另外,未经对方允许,不要随意向其他无关的人询问甲方情况,这是比较忌讳的。
7、每天的调研内容要及时汇总形成需求文档,并在小组进行交流,如果遇到问题,及时加入调研清单,以备次日向对方咨询;
8、需求调研只是需求分析的第一个环节,需求调研形成的文档也原始需求文档,也叫需求说明书,这个需求说明书只是记录了一条一条的需求,不存在主观地分析。但是这个需求说明书一般也会让甲方负责人签个字,但是大多数人不会去签,这没有太大的关系,所谓的签字仅仅表示该需求属实而已。
9、需求说明需要经过认真地分析,这种需求分析的过程是非常复杂的过程,需要依赖理论的支持和经验的积累,限于篇幅,我无法在这里详细描述,今后我会安排专门的系列来介绍如何进行需求分析。需求分析的结果就形成了需求分析说明书,也就是我们通常所说的需求分析规格说明书。这个说明书一方面将用户的需求进行条理化,从而更加清晰和容易理解,另一方面为概要设计提供了原始的业务框架。
需求分析规格说明书是需要按照一定的模板来进行撰写,一般甲方可能都要求提供这个文档,一方面为了存档,另一方面也为了今后维护系统提供依据。
10、注意穿着正式,言行规范。
需求调研分析阶段是很重要的环节,也属于重要的里程碑节点,很多甲方就是从这时开始结算,所以要非常重视。同时还有一个重要的方面就是,很多甲方都选择在这个时候近距离观察项目团队,稍有不慎,就会造成恶劣的影响。