来源: 发布时间:2011/4/20 浏览次数:1563次
其实这个问题不应该成为一个问题,因为一个真正意义上的的项目经理是不需要去做需求分析的,而应该是让专职的需求分析人员去做。我的理解,项目经理在工作过程中,与需求沾边的工作应该是对于项目范围的定义:确定哪些是在项目中要做的,哪些是不用去理会它的,清楚地定义项目的边界。除此之外,其它的工作都应该交由专门的人员去进行专业的信息采集与处理。但大家都知道,在实际的工作中,项目经理往往是既当爹来又当妈,一个人做N个人的活,尤其是当项目不大的时候,项目经理更是要一马当先地什么都做,几手都要抓,同时,老板对你的期望又是几手都要硬。因此,从现实的角度考虑,这个问题还是要探讨一下的。 记得我刚从学校毕业到公司的时候,曾无知地告诉老板说我对需求分析还是很有经验的,老板当时就笑着对我说,其实要想成为一个有经验的需求分析人员,起码要有十年的工作经历。当时只是觉得老板嫌我刚出道罢了,但做了一些项目之后,我对于需求分析这件工作有了更深刻的认识,也清醒地了解到需求分析真不是一件容易做的事。 首先,是我们对领域知识的缺乏。客户所在的领域并不都是我们所熟知的,这不像是在学校里做课程设计,不是图书馆管理系统,就是学生管理系统,连蒙带猜也能编出来。行业的多样性必然会导致需求领域知识的多样性,面对这样的困境,又怎么能要求我们在与客户短短的几次交谈中就获取足够的信息来完成一个复杂的软件产品呢。
1. 细晰地划分项目干系人(Stakeholder):尤其是分清什么是客户,什么是使用者。在了解需求的时候,我们能从哪些人中获取信息。同时还要注意到,获取的信息是否得到负责人的确认。 2.需求分析会议:与客户的会议当然必不可少。从中尽可能多的找出不清楚的地方,及时的提出,如果客户允许可以进行录音,不过这一招估计很难做到,大部分时候客户可不想留下自己的话柄。与项目组成员的开会是为了在组内加深对需求的了解,集思广义,再用点头脑分暴之类的东东,可以发现更多的求知问题。
3.在初始的需求得到后,要对其进行细致的分析,划分功能块及其属性和约束条件。 更多的知识,可以参考温伯格的《探索需求——设计前的质量》。
|
【大 中 小】【打印】【关闭】 |