80/20法则在完美软件开发中的逻辑链

软件是一种固化的思维→思维的交换是从杂乱、无序的信息中，提取有价值信息的过程→量上等价的信息，价值不等价→要能标识清楚什么是核心价值。

从用户来的信息大多杂乱，既无层次，也无条理，所以第一步是要对其进行归类。

各种信息大致可以按图6-2所示归类。

图6-2 需求的类别

归类之后，我们往往发现信息依然庞杂。如果我们认为需求中所包含的每条信息分别对应一定的价值，那么其和就是软件的整体价值。而显然的，价值在等量信息上的分布是不均匀的（80/20定律）。这就要求标识出核心价值的所在，在项目所能支配的资源是有限的时候，这种标识将决定资源分配原则。

我们看一个极端情形。大多时候使用性要求会消耗掉的人月在很大的一个范围内浮动，可以投入项目整体资源的10%，也可以投入50%。在iPhone里，这部分可能是核心价值，所以资源需要向这类要求上倾斜，但在不以此为核心的项目里（比如项目管理软件），仍然使用这种比例，就可能导致项目的失败。这些关键要求与软件的存在价值产生直接对应。这不只是一种形式上的优先级，事实上也定义出了软件的大致边界，与这些核心价值关联小的，就是可以舍弃的要求。

一个往往被忽略的事实是，标识出关键要求也是保证概念完整性的有效手段。自从《人月神话》提出确保概念完整性这一原则以来，大多数人对此表示认同。(www.xing528.com)

但与此相对的是，随着软件的越发庞杂，其牵涉的概念也就越为丰富，这样也就必须多人同时对软件的需求进行开发和维护，这一现实本身反过来又构成对概念完整性的破坏。

为应对这种情形，需求本身就必须分出层级，最顶层的就是关键要求，而其他要求则是对这些关键要求的完善和补充。

关键要求往往与领域模型相对应。比如说，我们前面提到过的项目管理系统，没有对现存主要问题以及对Effort驱动，关键路径，资源分配这样概念的统一建模，是描绘不出关键要求的。

概念完整性新解

如果说软件开发自身包含着两个根本步骤：需求的开发和实现。那么概念完整性无疑也包含着两个子项。需求上的概念完整性和设计上的概念完整性。而为确保概念完整性，显然的手术师团队型组织更为适合。简单来讲就是需求由一个人员负责，设计由一个人负责。这反过来定义了两个尺度，一是需求开发的尺度，二是设计的尺度。在限定时间内，需求开发和设计最好只做到1个人可以做到的程度，这样的话组织效率会高。

这似乎有点抽象，但想象一下，需求开发是可以无限制向纵深扩展的，极端情形下可以试图预先把每个按钮都定义清楚。但无限制做下去大多时候得不偿失，这样就需要判定做到哪里告一段落，剩下的则在迭代的过程中解决，而上面所讲的正是一个判断的依据。