有一种管理叫做“打地鼠”，有一种低质的医术叫做“头痛医头，脚痛医脚”，有一种低级
的观点是“软件项目失败的关键在于项目管理技能不足”。虽然提高项目管理能力很重要，但它不是万能的；现在许多软件项目遇到的问题，从表面上看是项目管理的问题，而其根源实际上是需求问题；如果不能从根源上下功夫，那么就无法真正有效的解决问题。
1. 需求变更分析
正如前面所说，需求频繁变更是许多项目开发过程中都会遇到的重大问题，即使如此重要，但依然有很多人对需求分析不是很重视。
需求变更频繁是一种统称，可以类比为“发烧”；虽然都是发烧，但成因是不同的，有的是感冒引起的，有的是脏器发炎引起的。有的是长牙引起的……因此不能都用一种药来治疗。虽然是需求变更，其诱因也是不同的，有的是对原有需求的背离、有的是原有需求的遗漏、有的是业务流程变化引起的……因此也不能用同样的“药”！不同的病症，有不同的原因，有不同的“药”。
1） 需求变更是对原有需求的补充：说明需求捕获有问题，需求不完整；因此应该加强需求捕获方法的组合应用，加强对业务模型的梳理。
2） 需求变更集中在流程间：说明需要采用工作流引擎。
3） 需求变更集中在用户界面方面：说明需要开发用户界面动态生成器。
2. 上线阻力大
许多项目在系统上线时经常会遇到很大的阻力，有的来自操作层，有的则来自于管理层，给软件带来巨大的困难。究其原因，通常是软件项目遭遇了行政因素；而常见的行政因素无外乎两大类。
1） 利益冲突
由于信息系统会对业务流程产生这样或那样的影响，会提高业务数据的管控力，因此经常会伤害到某些部门的既得利益，有时会导致新的利益冲突。
2） 工作量大
利益冲突的问题主要发生在管理层，对于基层（也就是操作层）而言，更常见的问题在于新系统通常会增加他们的工作量。当增大的工作量对他们日常工作产生影响时，在系统上线时就会遇到很大的阻力。针对这样的问题，实际上需要从需求阶段就开始着手解决：
i) 提高易用性：诸如“业务申请受理”之类的场景，其具有重复性、规模大的特点；在需求阶段应该十分注意标识出此类的功能，在设计时应该充分基
于业务实际场景来提高易用性、速度，否则就可能会使其成为日常工作的瓶颈。
ii) 工作量价值化：基层人员很多时候是无法理解新增的工作有什么意义，这样就会加大其抵触情绪；因此在需求阶段应该尽可能地标识出这些工作量 对于实际业务、管理工作等方面带来了什么样的直接好处，这样也就能够更好地提高基层人员的积极性。
iii) 将数据迁移、准备工作独立出来：很多系统在刚上线时需要对历史数据进行处理，或者是录入大量的基础数据，因此自需求阶段应该标识出这些工
作，以便有效的将其独立出来，不使其成为基层人员的负担。
