1.2 透过表象，分析本质
有一种低效的管理叫“打地鼠
”，有一种低质的医术叫“头痛医头，脚痛医脚”，有一种低级的观点是“软件项目失败的关键在于项目管理技能不足”。虽然提高项目管理能力很重要，但它不是万能的；现在许多软件项目遇到的问题，从表面上看是项目管理的问题，而其根源实际上是需求问题；如果不从根源上下工夫，那么就无法真正有效地解决这些问题。下面我们就列举几种最常见的表象，并简要地分析其背后的本质原因。
1.2.1 需求变更频繁
正如前面所说，需求变更频繁一直以来是困扰许多软件开发团队的重大问题之一；而且更大的问题在于许多软件开发团队并不重视对需求变更的分析和管理。
需求变更频繁是一种统称，可以类比为“发烧”；虽然都是发烧，但成因是不同的，有的是感冒引起、有的是脏器炎症引起、有的是长牙引起……因此不能简单地都开“退热净”；同样虽然是需求变更，其诱因也是不同的，有的是对原有需求的背离、有的是原有需求的遗漏、有的是业务流程变化引起的……因此也不可能用通用的“退热净”！不同的病症，有不同的原因，有不同的“药”。
● 需求变更是对原有需求的背离：说明需求描述与沟通有问题，导致需求在交流的过程产生失真；因此应该加强需求过程的管理，加强沟通手段的管理。
● 需求变更是对原有需求的补充：说明需求捕获有问题，需求不完整；因此应该加强需求捕获方法的组合应用，加强对业务模型的梳理。
● 需求变更集中在流程间：说明需要采用工作流引擎。
● 需求变更集中在用户界面方面：说明需要开发用户界面动态生成器。
● ……
另外，针对不同的需求变更的“高发地带”还可以总结出不同的“调研问题”，从而加强需求变更的可预测性。
● 流程变更频繁：上次组织机构变化是什么时候？上次岗位调整是什么？
● 数据字段变更频繁：业务表单上次变化是什么时候？
● 业务规则频繁：行业法规变化大吗？
● ……
与需求变更管理相关的更多内容，我们将在“第10章 变更管理操作要务”中讨论。
1.2.2 上线阻力大
许多软件项目在系统上线时经常会遇到很大的阻力，有的来自于操作层、有的则来自于管理层，给软件项目带来了巨大的困难。究其原因，通常是软件项目遭遇了行政因素；而常见的行政因素无外乎两大类。
1.利益冲突
由于信息系统会对业务流程产生这样那样的影响，会提高业务数据的管控力，因此经常会伤害到某些部门的既得利益，有时会导致新的利益冲突。
案例&场景：
某城市出租车GPS（卫星定位）系统上线之后，出租车司机群起而攻之，提出诸如价格太高、质量太差（阳光直射时屏幕上的字看不清、用久了会有外壳脱落等）……一系列问题，并且还上升到上访、请愿等形式，造成了较大的社会影响，给开发商带了巨大的压力。
而政府有关部门介入调查之后，发现真正的原因却是GPS终端中包含一个税控功能，能够将每天的营运数据发往中心，如果按这样的数据纳税，会导致税款上升30%～60%。
如果新的软件系统影响到涉众（stakeholder）的原有利益时，他们通常是无法直接地抱怨出来（例如，前面案例中的出租车司机们是不可能提出新系统的实现将提高其税款），因此总会找一些“冠冕堂皇”的理由作为阻碍系统上线的借口。而对于这种情况，如果没有准确地察觉到其真正的动机，只是简单地对他们提出的东西进行响应，那么最终的结果将是收获另外一堆意见，因此他们的目标只有一个，那就是阻碍系统的实施。
因此，这就要求我们在需求捕获的过程中细心地发现和总结潜在的行政因素（可以借助于诸如以下的问题：在针对哪些方面的需求讨论时争论最大？系统是否剥夺了某些人的决策权？），然后在系统实施之前将这些因素整理成文，直接提交给客户方的高层，这样就能够很好地减少开发团队的压力。
2.工作量增大
利益冲突的问题主要发生在管理层，对于基层（也就是操作层）而言，更常见的问题在于新系统通常会增加他们的工作量。当增大的工作量对他们日常工作产生影响时，在系统上线时就会遇到很大的阻力。针对这样的问题，实际上需要从需求阶段就开始着手解决：
● 提高易用性：诸如“业务申请受理”之类的场景，其具有重复性、规模大的特点；在需求阶段应该十分注意标识出此类的功能，在设计时应该充分基于业务实际场景来提高易用性、速度，否则就可能会使其成为日常工作的瓶颈。
● 工作量价值化：基层人员很多时候是无法理解新增的工作量有什么意义的，这样就会加大其抵触情绪；因此在需求阶段应该尽可能地标识出这些工作量对于实际业务、管理工作等方面带来了什么样的直接好处，这样也就能够更好地提高基层人员的积极性。
● 将数据迁移、准备工作独立出来：很多系统在刚上线时需要对历史数据进行处理，或者是录入大量的基础数据，因此在需求阶段应该标识出这些工作，以便有效地将其独立出来，不使其成为基层人员的负担。
1.2.3 运行效果差
虽然近几年来政府、企业投资的信息化项目逐渐开始从“装门面工程”向“业务价值提升工程”转变，但仍然有不少软件系统在上线之后运行效果较差，并未取得预期的效果。正因为如此，在产业内存在一个不太正常的现象，那就是许多软件公司都把“尾款（或称为终验款）”当作收不回来的东西；这是因为系统初验后就常常被扔到一边，并没有真正用起来，又怎么谈得上终验呢？
这种现象的存在，从根上说就是软件项目在开发的过程中缺乏有效的目标作为指引，与实际的业务过程存在脱节现象。而要缓解这一现象，在不同的层面有不同的方法：
● 从问题或机会入手，提高管理人员的推动力：未涉及其中，就没有全力以赴的动力；如果不能将系统的实施与管理人员的利益连接起来，就不可能获得这些管理人员的真正支持。而针对不同管理人员的内动力分析，就是需求阶段一个很重要的工作。
隐喻
有的时候我们经常说：“要成功地实施一个项目，首要工作就是在客户方为项目找一个爹！”。其中的含义就是要使管理人员的利益与系统连接起来，借助他的行政资源保障实施过程，毕竟项目经理是一个没有“权”力的经理，因此就需要“借”权，需要用“影响力”来弥补权力的缺乏。
● 从障碍和困难出发，解决操作人员的积极性：有了管理人员的推动，可以从制度上、过程规范上要求操作人员应用系统；但要使他们有积极性还需要为他们扫清使用障碍（也就是根据场景来设计更易用的系统），解决一些困难（也就是在原系统或手工操作过程中难以克服或需花费大量时间的问题）。
当然我们还可以根据实际的情况，在这些基本思想的基础上进行变通和扩展，下面这个场景就是一个例子。
案例&场景：
在某企业的信息系统上线时由于各个部门的经理们没有动力进行推动，而导致了整个系统处于闲置状态，开发团队的项目经理只能干着急。
这时我就给他一个这样的建议，先找到一个关系比较好、对他的关注点有所了解的部门经理，认真和他分析系统将对其带来的好处，然后使其推动自己的下属在局部应用起来。
一段时间后，当数据库中有一些信息之后再组织一次项目运行情况汇报会，在这个会上项目经理展示出各个部门的应用情况，说明数据库的记录数，但并不对其做任何评价，只谈数据。这时对方的高层领导就在会上对这个部门提出了表扬。
会后当项目经理再次找其他部门经理进行沟通时，就发现各个部门经理的态度都有了很大的改变，大家都纷纷就系统如何在本部门的应用进行了沟通和探讨。
这样，系统全面应用的突破口也就随之出现。这就是一种务实的“以点带面”的策略，往往能够获得很好的效果。
1.2.4 完全崩溃
有的时候还可能会遇到更可怕的事情，那就是最终的软件系统完全不可用，或者称之为崩溃了！这种情况大多是因为忽略了某方面的非功能需求，例如系统容量不足以支撑业务需求，系统没有足够的可靠性而经常死机等。
我们翻开任何一份软件需求规格说明书，一定都能够找到关于非功能需求的描述，那么怎么会忽略非功能需求呢？实际上，最常见也是最主要的问题在于非功能需求的描述上。不止一次地在不同的软件需求规格说明书中看到这样的现象，拿一个名为“设计原则”的章节，罗列了诸如高可靠性、高扩展性、高灵活性、高可用性……之类的所谓“非功能需求”；我不禁想问，什么样的可靠性叫“高可靠性”？我想，软件需求规格说明书的所有读者都会有相同的问题，只不过一般都不提出来，就当没有看见它罢了。
以这种“定性”的方法来描述非功能需求，实际上就是一种无效信息传递！很多讲述“软件需求”主题的书籍都建议你用“定量”的方法来描述，但“平均无故障时间为1 000个小时”是什么意思，恐怕写的人和读的人都没有明确感知吧！因此我们需要更有效地认识非功能需求的特点，采取更有效的措施来传达是缓解这一问题的关键。更多的内容，我们将在“第3章 软件需求与需求工程”中阐述。