1.2.8　需求变更

在软件的各个阶段都有可能产生需求变更。例如，在调研阶段，用户刚确定了某个问题的处理方式，过了几天可能又觉得换一种方式好；在设计阶段，设计者可能在设计过程中会发现需求问题，从而向用户提出变更建议，或者，用户参与设计评审后，可能会提出需要增加、修改功能；在开发阶段，开发者可能会发现设计问题，用户也可能提出追加功能、改变功能，设计者也可能觉得有些设计不尽如人意，从而提出需求变更；在试用阶段，用户可能会发现开发出来的软件很多地方并不能真正满足信息化管理的要求，提出需求变更；在正式使用阶段，用户的业务可能会发生变化，用户的管理思想也可能会发生变化，从而提出需求变更，等等。

产生需求变更的原因很多，常见的包括调研不充分、沟通有歧义、异常没考虑、规划不到位、设计有瑕疵、实现欠灵活、实施不熟练、业务会变化、管理在改善、想法在改变、软件要发展。

软件团队常用的控制需求变更的手段包括技术手段、沟通说服、成本约束等。有些控制方式并不是仅靠需求人员就能做到的，需要发挥团队的力量。

不同的需求变更差别巨大，有些需求变更处理起来很容易，有些需求变更处理起来相当麻烦。本书将需求变更分成4种：改变界面的需求变更，改变功能逻辑的需求变更，改变数据库结构的需求变更，改变历史数据的需求变更。这4种需求变更的处理难易程度是递增的。

处理需求变更，要尽量从根本上解决问题。从根本上解决问题，核心思想是从整个系统的角度出发考虑问题，而不是仅仅从一次需求变更的角度考虑。假如现在还处在调研阶段，如何处理这个需求呢？自然会将其跟别的需求一起进行系统性规划，会考虑软件的灵活性、健壮性、易学性、易用性等，绝对不能容忍那种看上去简直是胡搞的开发方式。

虽然大部分情况下，软件团队谈到需求变更都是惊慌失措、咬牙切齿的，但不能不承认，“塞翁失马，焉知非福”的古谚在处理需求变更的过程中同样有效。有些需求变更，可以提高客户的黏性；有些需求变更，可以直接给团队带来商务收益，带来利润；还有些需求变更，虽然看上去是“坏事”，但只要处理好了就能推动软件的发展，虽然不敢说“多多益善”，但至少没有看上去那么糟糕。