软件项目根据统计有80% 以上的项目不能够按时提交给客户使用，与其它类型的项目比是失败率最高的。是什么导致项目的延期甚至失败呢？
本文再此必要对项目的失败的原因作一个深入的分析，并提出一些解决的思路
决定一个项目成功的因素有很多：高质量的团队、清晰的项目目标、对项目进行的有效管理、有效控制的客户需求等。
在ＣＭＭ 软件成熟度模型的５个级别中，第２级中第一个 ＫＰＡ（关键过程域） 就是需求管理，ＣＭＭ 中第一级的概念是初始状态的公司，需求管理实际上是ＣＭＭ模型里面第一个要求实现的关键过程域，可见其重要性。
总结在多年的软件项目管理实践，我认为：软件项目管理过程中，需求的变更是无法避免的。如果哪一个开发商要对客户说：客户需求在开始确定后就不能修改，我估计他十有八、九拿不到这个订单，没有哪一个客户愿意。
如何才能改善需求的管理，减少需求变更或需求变更的影响了，我认为要在以下三个方面做好相应的工作：
１）与客户建立良性的、基于理性的合作环境
２）在软件工程的方位内，尽量减少需求变更的影响
３）建立一套行之有效的，在项目启动阶段就应该得到客户认可的需求管理制度
一、与客户建立良性的、基于理性的合作环境
需求过程本身的问题
·在需求确定的过程中，客户往往会把他建议的解决方法当成了需求本身
·客户或开发者有时候会假定对方已经明白自己的意思，有些需求是理所当然的。
外部因素导致的变更
·经营方向的改变
·政策因素的影响
我们能够因为客户的变更不在合约的目标范围之内而拒绝变更呢？在国内的软件项目实践中，在目前主要是以客户关系为中心的销售模式下，要做到这点非常的困难。
我们必须要假定需求是一定会修改的，
1） 与客户建立良性的、基于理性的关系
如何与客户建立理性和良好的关系呢？我们首先要对客户有一个分析和了解：
国内的客户分为两类：
一类为国家单位和大型企业的IT 部门，这些部门对项目的成本的敏感性比较低，但对项目的成功与否，是否会延期等非常敏感，因为在一个大型的企业或单位里面，这关系自己的表现。
另一类为小规模的企业，这类小规模的企业往往是由企业的负责人（或者直接就是老板）来拍板某一个系统，这类企业对项目的成本就会非常敏感。
在项目管理的概念中，有一个客户的干系人的概念，什么是项目的干系人？
在需求调研分析阶段，项目组对客户的整体组织结构、有关人员及其关系、工作职责等没有足够了解以致于无法得到完整需求或最终经权威用户代表确认的需求。由于项目经理和需求分析员的工作问题，客户参与程度部不高，客户方相关责任人不明确或对范围和需求责任心不强，提出的需求具有随意性，项目前期对需求的确认不够积极；或者是多个用户代表各说各话、昨是今非但同时又希望软件尽早交付；项目后期需求变化随意，造成项目范围的蔓延，进度的拖延，成本的扩大。 造成上述现象的原因是系统分析人员没有全面了解所有项目干系人的需求，并按照重要性优先级进行权衡取舍。全面的需求来自所有项目干系人。项目干系人STAKEHOLDER也有的翻译成利益关系人、利害关系人、利益干系人、利益共享者、涉众，如此等等，即所有可能受到项目结果重大影响的人。项目干系人即可能是项目的受益者，也是项目的风险承担者，甚至有可能是项目的受害者。项目干系人的需求包含明确的和隐含的，也可以分为NEED、WANT、WISH等不同层次。
不同的干系人其愿望和追求的目标往往相差甚远，因此对项目干系人的愿望进行平衡可能是相当困难的事情。例如政府部门准备建设的不少对群众办公的信息系统，上层管理机关往往希望能够采集尽可能多的信息项以便对数据进行多种多样的统计分析，同时为了对信息进行有效控制而增加一些审批流程；基层对外办公的窗口则因为办公速度的压力希望减少信息项的输入量；甚至有些不良的基层客户由于害怕建立透明度高的信息系统会影响他们的工作考核成绩而消极地应付，即所谓反需求；而客户的客户（办事群众）则希望相关政府机构能够简化工作流程，加快办事速度；一些客户相关的管理机构或组织也会制定一些有关的标准规范；作为项目干系人的公司领导层也可能会提出一些技术上、接口上、环境上的需求；甚至项目组本身因为技术、资源、进度等原因，需要对一些功能进行优先级排序和取舍。虽然不是所有人的需求都是可以满足的，特别是消极的反需求是不能接受的，但他们的需求都是应当考虑全面并进行平衡的。
软件开发项目的目的就是实现项目干系人的需求和愿望。如果对项目所有干系人没有进行足够的沟通和影响，使其尽可能地参与项目，则可能因为项目开始时项目范围和一些具体需求不够完整清晰，也可能因为某个项目干系人后期因为认识的变化而提出新的需求，造成工期的延长，成本的增加，甚至项目的完全失败。因此，应当从项目的启动开始，需求分析员及其项目成员就要分清项目干系人包含哪些人和组织，通过沟通协调对他们施加影响，驱动他们对项目的支持，调查并明确他们的需求和愿望，减小其对项目的阻力，以确保项目获得成功。以下是一些有效的措施：
1、尽快熟悉项目干系人全貌
有些项目在做需求调查时，由于受进度要求等客观因素影响，需求分析员与建设单位的技术部门交流较多，向业务管理部门和实际使用者调查不够深入，造成软件试用后不得不再对需求做较大调整，"从头再来"的部分比例很高，大大超过进度要求时间。因此，熟悉项目干系人全貌是进行需求调查的第一步，也是需求调查的基础。在定制开发项目的项目干系人中，最重要的是建设单位中的人事组织、业务关系。最好是能够用组织结构图画出相关单位的组织结构；用责任矩阵确定各部分的调研对象；建立调研对象通讯录以保证调研及分析期间及时的沟通。与此同时要注意项目干系人的主次关系，以便在他们之间的需求出现矛盾时能够进行合理的取舍。
熟悉建设单位内部相关部门的业务划分及它们之间的相互关系,为功能分析准备了必要的资料, 同时可以熟悉用户方的各类人员，并及时进行广泛、有效的沟通与交流。特别要与客户方业务与技术的规划者和实际使用者进行深入探讨，收集必要的原始资料，保证需求调查的完整性、正确性。
建设单位只是项目干系人中的一部分（当然是主要的部分），为了更好地了解项目干系人全貌，还应当在建设单位组织结构图基础上全体项目干系人结构图，以便更好更全面地进行需求调研分析。
2、详细描述各项业务，以利于让所有客户确认
尽可能全面详细地调查并且描述原有系统和用户希望将来系统具有的各项业务的流程，并将这些业务流程文档化后与客户进行讨论，对描述错误或不准确不精确的进行修改，最终让客户进行确认。从近年来开发的软件看，对业务处理过程了解的完整性和准确性非常重要。虽然对数据来说都是SIDUT（查增删改传），但具体业务都是分为若干步骤，每个步骤都有其业务名称，同一步骤可能对多个数据集进行不同操作，需要调查了解清楚才能设计出适合各流程业务节点用户业务特点和习惯的软件，使开发出来的软件更受欢迎。当然在进行软件概要设计时，要尽量排除业务流程的制约，即把流程中的各项业务结点工作作为独立的对象，充分考虑他们与其他各种业务对象的接口，在流程之间通过业务对象的相互调用实现其业务流程，这样，在业务流程发生有限的变化时，就能够比较方便地修改系统程序而实现新的需求。
对于各项业务的调查可以通过对以下资料的收集整理分析，这些资料来自各种各样的项目干系人：遵循的标准、组织发放的工作手册、作业流程、有关业务的上级通知、有关业务的办事指南、办理业务时需要填写的登记表、各种相关的统计报表及通过其他途径收集的类似系统的介绍、技术资料等等。
3、可视化需求调研，引导各种客户挖掘他们的需求
有的客户因为自己缺乏计算机知识，无法提出完整准确、隐含的或潜在的需求。但若这些需求不能满足将导致用户的不满。因此需求调研分析人员应善于想用户所想，不但要确定明确的需求，还要善于用启发的方式与用户探讨隐含的或潜在的需求，并结合各种调研分析技术挖掘超出客户期望的令人兴奋的需求。这就要求需求调研分析员要尽快完整地熟悉相关业务，从而能够站在用户的立场看待软件需求，想用户所想，做好业务与计算机之间的桥梁。利用可视化需求调研的方法可以很好地启发用户深入挖掘潜在的需求。可视化需求调研就是使用图表等工具来启发引导用户清楚地叙述需求，并且使需求更加全面完善。
对于高层领导，可以提供系统总体框架图；对于业务管理人员，可以用业务流程图来描述新旧系统的业务流程；对于客户中的技术人员，可以用数据流图、实体关系图或UML中的各种图形对系统进行各种角度的描述；而对于业务管理人员、客户中的技术人员、以及各层次各流程中的用户，画出用户界面图来进行需求挖掘，是个比较有效的沟通方式。 [本文共有 4 页，当前是第 1 页] <<上一页 下一页>>
|
|
|
|
|
|
|
您的位置：
