《The Design of Design》之 需求、罪念以及合同(需求)--《人月神话》作者之力作

任何在项目伊始就规划所有的可能需求之企图都会落败，并以客观的延误告终。-Pahl,Beitz 《Engineering Design》

关于需求：

项目伊始，有多少需求是有技术人员参与的？有多少需求是市场人员提供的？。。。

现实中，大部分此类需求只是客户那边的管理层，各自为阵提出自己的想法。而这些想法很多只是为了表明自己分量，现实自己工作多么重要，这是我亲身体验？

当年我作为客户方的代理人（甲方），领导说要搞信息化，然后下面的部门就忙乎起来，各自罗列自己的需求，倒也很认真（不认真会丢饭碗的，呵呵），这种状况持续一段时间后，大家都拿出各自的需求列表，在会议上，谁的需求列表长说话就有力，而需求列表短的则感觉脸面无光？

各人只关心各人的需求，没有人对需求进行相互沟通，整合（整合后的需求算谁的呢？年底奖金怎么算？呵呵），最后整个需求打印出来有一尺厚，大量的不知所谓的需求，谁也搞不清楚最终要干什么？没有人负责整理需求里的各种概念，大量交叉重复的需求，就这样交到程序员面前。

我记得非常清楚的是一件事情，一个需求里出现了“类型”的字样，另一个需求里出现了"类别"字样，大家围绕这两个概念有的说是Class,有的是Kind,也有说是Type...,因为

需求本身就没有统一，只是各个部门各自为阵的罗列，没有一个概念上的统一性，更没有人专门负责维护这种统一性，结果可想而知，这个项目开发了8年（甲方相当有钱），生产了无数的网页，可是大家却不知道可以干什么，如果不是纪律要求员工必须上这个网，否则谁也不会去看。

这种需求出台的画面可以想象：

每个列席人都有一个需求列表，这个列表最终在多大程序上被采纳，事关自我价值的认同和个人荣誉。讨论会上大家一片和气，我不给你添堵，你也别找我麻烦。

可是，有谁在需求制定过程中为最终产品本身-概念完整性，高效性，经济性和健壮性摇旗呐喊呢？

系统架构师在目前阶段能干什么呢？在这个阶段，系统架构师还无法掌握足够的领域知识来以事实为依据说服众人，因为这是在经典的、基于瀑布模型的产品过程中，

需求是在设计开始之前就要确定下来的。

抵制需求的膨胀和蠕变

需求膨胀的原因大部分和上面的场景有相似之处，我们必须抵制，方法是防范于未然或将这种势头扼制在摇篮之中。成功的项目往往在实际之初都只有少量几个概要的需求，随着开发的推进，这些需求被精化成更具体的子需求，而不是一开始就要精化到这种力度，这是过于理想化的。

现代流行的敏捷开发正是采用了这种方式，从少数几个需求开始，经过不停地迭代过程，开发的过程也是需求的探索过程，需求探索过程结束开发过程也随之结束。这种设计模式下，不需要人为地为某需求定制优先级，强调重要性，实际上优先级和重要性高的需求在探索过程中总是会先被发现。这种探索而来的需求，肯定是客户的真正需求，有用的需求，那些冗余的需求在这里会被很自然地整合。

需求的蠕变，主要是因为人们具有天生的发散思维，总是喜欢探索当前需求之外的场景，结果是某个具体的需求被无限衍生其功能，而衍生出来的这些功能都是通过一时脑热

而想到的，并不代表客户的真正需求。解决需求蠕变的方法是及早任命手腕强硬，经验丰富，领域知识到位的经理。