51Testing软件测试论坛

标题: 需求管理和控制 [打印本页]

作者: molei    时间: 2010-3-16 10:51
标题: 需求管理和控制
公司是国企下的子公司,接的项目都是集团的项目;
客户都是领导,没有时间理会需求,他们只会说要达到什么目的,有什么基本功能;
下面的人说话不算;
项目只能自研需求,然后设计,开发出一定系统后给客户看,客户不满意再改;
公司有业务人员,可以开发需求;

对于这样的项目,怎么来管理需求?
作者: archonwang    时间: 2010-3-22 14:54
最简单的,Excel表格记录

复杂些的,可以自己开发一个简单的跟踪系统,功能只要最基本的即可。

对于需求的分析及归类是比较重要的工作,一定不能遗漏。
作者: coco_yink    时间: 2010-3-30 15:59
还不完全是这样,领导一般只给一个要求和一个时间期限。比如:要求你在某月某日,让他有一些基本的数据进行查看。具体的细节就会交代给下边的人和你沟通。等到那个期限,领导看了你做的东西之后,就会提出一大堆的意见,让你修改。他下边的人也会提出很多。然后回去改好之后,他可能又提,你又改。这样项目就永无止境了。

还有,很多项目涉及到多个机构,从集团,到分公司再到各个下属企业单位。从管理层次来说,有三个层次。每个层次的用户所关注的角度不同,需要的东西也不一样。另外,还有一个国有企业内部管理的问题。总之很复杂,不是三言两语说得清楚的。
作者: gpo2002    时间: 2010-3-31 00:06
楼主的情况,和我现在遇到的情况一样。
1。项目需求的实际拍板人是高层,而指派的项目负责人是个中低层人员,造成调研时很难保证得到完整的需求。
2。项目涉及的单位、部门多,并且高、中、低层人员对系统的要求都是站在自己的角度来看。对同一个业务的理解和要求本身就很难达成一致。导致项目推进后,由于部门及上下级间协调后造成需求前后变化大。
3。信息系统最重要的是业务流程的优化,很多返工都是甲方对业务流程重定义后造成的。

我曾经的一个项目推进到中期完全发现原来的需求和设计行不通,最后重新设计才完成。而主要原因就是甲方项目负责人并不了解单位实际操作情况,我们根据他调研得到的需求做出来的东西,实际根本不能实施。

我现在的对策是
1。快速响应,快速反馈。每次调研完成后,完成一个版本马上提交客户演示。基本1周提交一次,省略掉次要部分,修改主要部分后,快速的得到用户的反馈意见。
2。加强和甲方的沟通,每周汇报系统开发情况。定期向项目决策人汇报演示系统。3。对于发生重大变更,要和甲方会议讨论后确认,同时做好会议纪要,甲方盖章。
3。平时加强对甲方业务的了解,特别是部门间和上下级的业务流转。

需求变更不可避免,我觉得关键还是要理解用户通过系统真正要解决什么问题。
领导的管理思路是什么。怎么样分配好功能满足各业务部门的需求同时减轻他们的工作量。

[ 本帖最后由 gpo2002 于 2010-3-31 00:21 编辑 ]
作者: coco_yink    时间: 2010-3-31 15:49
楼上的朋友,你好。你说的情况,和我们公司的情况好像,不是好像,是简直一模一样。

其实我最近都在学习需求管理方面的知识,以前从来没学习这么多理论。现在才发现其实我们做的很多事情都是有理论依据的,之前没有一种理论体系的引导,所以很多工作但感觉很茫然,还有一些成果浪费了,没有得到积累。

我发现你说的1、2点都是属于“需求管理流程”中的“需求跟踪”的范畴。部分难以把握需求的项目,就需要在做好初期的雏形之后,定期向客户演示系统,周期性地快速地得到到客户的反馈意见,慢慢完善。但是在做这个雏形之前,应该有初步的需求调研、沟通和需求确认。

你说的第3点,应该是属于“需求开发”流程中的。属于业务需求开发的范畴。
作者: molei    时间: 2010-3-31 15:57

作者: coco_yink    时间: 2010-3-31 16:35
呃,我理解错误了。

更正一下,1、2点是属于需求获取、需求确认的范畴,而不是需求跟踪。

其实好多项目都是在需求开发->需求确认->需求跟踪->需求变更 这样的过程中不断地一轮又一轮地循环的。
作者: gpo2002    时间: 2010-3-31 17:39
项目管理9大要素都是相互交织的,上面的还涉及到沟通管理部分。我也在看PMP资料,感受和你差不多。
作者: belmount    时间: 2010-8-26 14:45
变更管理是软件开发中必须在项目建立初期就建立好的机制。
大部分软件项目的失败来源于项目初期未建立明确的process,然后在项目后期还债。
为了保障每个项目都可以在可控的范围内发展,必须在企业内部建立统一的项目管理模型和一整套制度。
所以现在很多企业,包括hp,摩根stanly都建立了program management office,用于规范流程,协调项目目标以符合组织目标,合理分配项目资源等。
pmo直接对管理层负责,从更高层次上解决流程混乱的局面。

项目生存手册里面指出,不要指望客户能够提供什么需求,因为没有任何项目的需求是由客户完成的,需求建立在对客户的观察和理解的基础上。
但是务必在需求沟通, 分析, 确认和变更的流程进行之前告诉客户变更的影响。
使用快速迭代是一种方法,但是它的后果是造成项目的总体成本会上升。




欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2