观的信息,建立起良好的沟通渠道和方式。第二阶段:诱导式。这一阶段是在开发方已经了解了具体用户方的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等具体实际、客观的信息基础上,结合现有的硬件、软件实现方案,做出简单的用户流程页面,同时结合以往的项目经验对用户采用诱导式、启发式的调研方法和手段,和用户一起探讨业务流程设计的合理性、准确性、便易性、习惯性。用户可以操作简单演示的DEMO,来感受一下整个业务流程的设计合理性、准确性等问题,及时地提出改进意见和方法。第三阶段:确认式。这一阶段是在上述两个阶段成果的基础上,进行具体的流程细化、数据确认。这个阶段开发方必须提供原型系统和明确的业务流程报告、数据项表,并能清晰地向用户描述系统的业务流设计目标。用户方可以通过审查业务流程报告、数据项表以及承建方提供的DEMO系统,来提出反馈意见,并对已经可接受的报告、文档签字确认。三个阶段或者说三步法的实施和采用,对用户和承建方都同样提供了项目成功的保证。
1.4 需求管理的策略
在需求管理上应遵循以下策略: (1)需求一定要与投入有必然的联系,否则如果需求变更的成本由开发方来承担,则项目需求的变更就成为了必然。在项目的开始无论是开发方还是出资方都要明确这点:需求发生变化,软件开发的投入也要变。(2)需求的变更要经过出资者的认可。需求的变更将引起投入的变化,所以要通过出资者的认可,这样才会对需求的变更有成本的概念,能够慎重地对待需求的变更。(3)小的需求变更也要经过正规的需求管理流程。小的需求变更也要经过正规的需求管理流程,否则会积少成多。在实践中,人们往往不愿意为小的需求变更去执行正规的需求管理过程,认为降低了开发效率,浪费了时间。正是由于这种观念才使需求的渐变不可控,最终导致项目的失败。(4)精确的需求与范围定义并不会阻止需求的变更。并非对需求定义的越细,越能避免需求的渐变,这是两个层面的问题。太细的需求定义对需求渐变没有任何效果,因为需求的变化是永恒的,并不会因为需求写细了,它就不变化了。(5)注意沟通的技巧。实际情况是用户、开发者都认识了到了上面的几点问题,但是由于需求的变更可能来自客户方、也可能来自开发方,作为客户他们可能不愿意为需求的变更付出更多的投资,开发方有可能是主动的变更了需求,他们的目的可能是使软件做的更精致,于是作为需求管理者、项目经理需要采用各种沟通技巧来使项目的各方各得其所。基于上述的问题,必须对需求进行管理,使需求能够真正成为软件工程和管理的基线,使软件计划、活动和工作产品同软件需求保持一致,使需求可以复用。
1.5 监理方责任
为了保证项目的成功,作为第三方的监理公司也必须加强项目管理和项目分析工作,要提醒开发方、客户方重视需求分析的重要性,采用必要的手段和方法来进行需求调研。在原则上,需求阶段监理应尊重承建方的项目管理和项目分析能力;在具体的任务开展上,以不深入、不干扰承建方的自主权为主,除非在项目合作过程中发现承建方的项目管理以及项目分析能力存在很大的差距和不足;在具体的操作上可以坚持吸收、同化、贯彻的方法和手段。只有这样才能切切实实地把握用户的需求和方向,才能在将来的功能界定、开发范围上有发言权。
2 范围管理
对于项目中哪些该做,哪些不该做,做到什么程度等问题,都是由范围管理来决定的。与需求相关的一系列问题,都属于项目范围管理的问题。
2.1 产品范围与项目范围
项目中花费大量时间和精力用于需求调研分析,也是为了确定项目范围。范围的概念应包含两个方面,一个是产