需求管理和控制

molei

公司是国企下的子公司，接的项目都是集团的项目；
客户都是领导，没有时间理会需求，他们只会说要达到什么目的，有什么基本功能；
下面的人说话不算；
项目只能自研需求，然后设计，开发出一定系统后给客户看，客户不满意再改；
公司有业务人员，可以开发需求；

对于这样的项目，怎么来管理需求？

archonwang

最简单的，Excel表格记录

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

对于需求的分析及归类是比较重要的工作，一定不能遗漏。

coco_yink

还不完全是这样，领导一般只给一个要求和一个时间期限。比如：要求你在某月某日，让他有一些基本的数据进行查看。具体的细节就会交代给下边的人和你沟通。等到那个期限，领导看了你做的东西之后，就会提出一大堆的意见，让你修改。他下边的人也会提出很多。然后回去改好之后，他可能又提，你又改。这样项目就永无止境了。

还有，很多项目涉及到多个机构，从集团，到分公司再到各个下属企业单位。从管理层次来说，有三个层次。每个层次的用户所关注的角度不同，需要的东西也不一样。另外，还有一个国有企业内部管理的问题。总之很复杂，不是三言两语说得清楚的。

gpo2002

楼主的情况，和我现在遇到的情况一样。
1。项目需求的实际拍板人是高层，而指派的项目负责人是个中低层人员，造成调研时很难保证得到完整的需求。
2。项目涉及的单位、部门多，并且高、中、低层人员对系统的要求都是站在自己的角度来看。对同一个业务的理解和要求本身就很难达成一致。导致项目推进后，由于部门及上下级间协调后造成需求前后变化大。
3。信息系统最重要的是业务流程的优化，很多返工都是甲方对业务流程重定义后造成的。

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

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

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

[ 本帖最后由 gpo2002 于 2010-3-31 00:21 编辑 ]

coco_yink

楼上的朋友，你好。你说的情况，和我们公司的情况好像，不是好像，是简直一模一样。

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

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

你说的第3点，应该是属于“需求开发”流程中的。属于业务需求开发的范畴。

molei

coco_yink

呃，我理解错误了。

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

其实好多项目都是在需求开发->需求确认->需求跟踪->需求变更 这样的过程中不断地一轮又一轮地循环的。

gpo2002

项目管理9大要素都是相互交织的，上面的还涉及到沟通管理部分。我也在看PMP资料，感受和你差不多。

belmount

变更管理是软件开发中必须在项目建立初期就建立好的机制。
大部分软件项目的失败来源于项目初期未建立明确的process，然后在项目后期还债。
为了保障每个项目都可以在可控的范围内发展，必须在企业内部建立统一的项目管理模型和一整套制度。
所以现在很多企业，包括hp,摩根stanly都建立了program management office，用于规范流程，协调项目目标以符合组织目标，合理分配项目资源等。
pmo直接对管理层负责，从更高层次上解决流程混乱的局面。

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