透过表象,分析本质

有一种管理叫做“打地鼠”,有一种低质的医术叫做“头痛医头,脚痛医脚”,有一种低级

的观点是“软件项目失败的关键在于项目管理技能不足”。虽然提高项目管理能力很重要,但它不是万能的;现在许多软件项目遇到的问题,从表面上看是项目管理的问题,而其根源实际上是需求问题;如果不能从根源上下功夫,那么就无法真正有效的解决问题。

1. 需求变更分析

  正如前面所说,需求频繁变更是许多项目开发过程中都会遇到的重大问题,即使如此重要,但依然有很多人对需求分析不是很重视。

  需求变更频繁是一种统称,可以类比为“发烧”;虽然都是发烧,但成因是不同的,有的是感冒引起的,有的是脏器发炎引起的。有的是长牙引起的……因此不能都用一种药来治疗。虽然是需求变更,其诱因也是不同的,有的是对原有需求的背离、有的是原有需求的遗漏、有的是业务流程变化引起的……因此也不能用同样的“药”!不同的病症,有不同的原因,有不同的“药”。

  1) 需求变更是对原有需求的补充:说明需求捕获有问题,需求不完整;因此应该加强需求捕获方法的组合应用,加强对业务模型的梳理。

  2) 需求变更集中在流程间:说明需要采用工作流引擎。

  3) 需求变更集中在用户界面方面:说明需要开发用户界面动态生成器。

2. 上线阻力大

  许多项目在系统上线时经常会遇到很大的阻力,有的来自操作层,有的则来自于管理层,给软件带来巨大的困难。究其原因,通常是软件项目遭遇了行政因素;而常见的行政因素无外乎两大类。

  1) 利益冲突

  由于信息系统会对业务流程产生这样或那样的影响,会提高业务数据的管控力,因此经常会伤害到某些部门的既得利益,有时会导致新的利益冲突。

  2) 工作量大

  利益冲突的问题主要发生在管理层,对于基层(也就是操作层)而言,更常见的问题在于新系统通常会增加他们的工作量。当增大的工作量对他们日常工作产生影响时,在系统上线时就会遇到很大的阻力。针对这样的问题,实际上需要从需求阶段就开始着手解决:

    i)  提高易用性:诸如“业务申请受理”之类的场景,其具有重复性、规模大的特点;在需求阶段应该十分注意标识出此类的功能,在设计时应该充分基

      于业务实际场景来提高易用性、速度,否则就可能会使其成为日常工作的瓶颈。

    ii)  工作量价值化:基层人员很多时候是无法理解新增的工作有什么意义,这样就会加大其抵触情绪;因此在需求阶段应该尽可能地标识出这些工作           

      量对于实际业务、管理工作等方面带来了什么样的直接好处,这样也就能够更好地提高基层人员的积极性。

    iii)  将数据迁移、准备工作独立出来:很多系统在刚上线时需要对历史数据进行处理,或者是录入大量的基础数据,因此自需求阶段应该标识出这些工

      作,以便有效的将其独立出来,不使其成为基层人员的负担。

  项目的开发是为了让人们的工作更加方便,而不是增加人们的工作量,如果加大了人们的工作量,必然会引起工作人员的反感。

  在项目的开发过程中,会遇到许许多多的问题,我们要尽可能的避免这些错误,完善系统的开发过程。

posted on 2018-01-16 20:16  账号你好  阅读(165)  评论(0编辑  收藏  举报