项目在缺乏明确范围的时候要能够把握系统的功能需求相当困难。项目愿景是客户希望最终能够达到的目标，如何达到预期的目标?过程如何操作?将来需要哪些类型的工作人员负责执行?应用过程，处理的方法和模式如何应用?这些问题客户可能从来没有考虑过，更不能够为技术人员提供所谓需求，只希望透过技术人员的专业知识和经验，提供客户能够达到目的的应用系统。

　　今天软件工程的挑战

　　要能够有效完成项目的交付，我们便需要在项目前期建立明确的范围，只要我们能够完成范围内的工作，客户便能够进行有效的验收过程。但是我们在软件工程中没有把范围建立起来，我们便需要不断满足客户的思维，来提供客户所希望达到的目的。

　　很多IT项目经理在项目启动的时候，把工作重点放在把握“客户需求”上，但执行调研的技术人员却把“客户需求”误解成系统的“功能需求”，希望通过调研的过程去理解系统需要哪些应用功能。回顾20世纪70、80年代的开发过程，客户需求是项目范围，与开发过程中的“需求说明(Requirement Statements)有一定的差异。

　　我国的软件产业有本身的特色，我国的技术人员也有本身的工作习惯，我国的用户对软件要求有个别的期盼和要求，这些都影响软件开发模式的应用，采用欧美的软件开发制度基本上不能够满足我国的软件产业现状，也不一定能够解决我国软件产业的困境。大部分软件项目的失败不是技术应用的失败，是未能把握项目的焦点和项目重心所导致的失败。那么软件项目的焦点和项目重心究竟是什么呢?

　　客户提供的所谓需求，实际上在今天的项目中是未来交付中所必须涵盖的功能，也是交付物的一些基本质量要求。客户对项目的验收是依据我们在项目完成后的最终交付物，我们必须摆脱过去的传统思维，不要在项目起动的时候尝试把握那些基本上不存在的需求，必须明确项目交付的验收目标，在项目启动时能够把有关的最终交付明确下来，便能够降低项目失败的比例。

　　我在未来数月会继续跟希赛的网友分享过去进行信息化项目的一些经验，如何采用“项目组件分拆方法”(Project Components Decomposition Method ，PCDM)，在项目初期确认项目的最终交付物，让项目在开发过程中减低客户的修改要求，让我们能够更有效地把握IT专业知识，提供社会所需的高质软件，提升我国软件人员的专业水平。

上一页  [1] [2] [3] [4]