OOPAA

    “体面汤、浓又黄，

盛在锅里不会凉！

说什么山珍海味，哪儿有这样儿香？

半夜起来喝面汤，体面汤！”

——刘易斯·卡罗尔（Lewis Carroll），《爱丽丝漫游仙境》

产品夸耀自己繁多的零碎特性，其中很多对于解决客户真正的业务需求几乎毫无帮助。

在一开始的时候，一切都显得那么美好。市场部有一个来自于客户的请求——添加额外的下拉菜单。然后，在产品中添加一个输出接口的需求来了，产品经理想要加上一份新的分析报表，DBA要求在数据库里增加一个新字段以改变背景的颜色。所有这些需求以及其他更多的需求，都交由开发人员负责加进到产品里面。随着需求的不断添加，产品的特性集不断增长，但过了一段时间之后，每个人——市场部、客户和开发团队——对如何将所有这些碎片整合在一起、这些碎片如何帮助实现业务目标，失去了理解。曾经带着明确目标出发的项目变成了难以下咽的、由各种无关特性炖成的一锅汤。

情况变得更加汤汁淋漓，因为感兴趣的各方都从不同的角度来看待产品的需求，根本不存在共同的、连通的思路。市场部从营销的角度把需求打包成一组一组的特性集合，也不管它们在功能上是否内聚。开发人员则按照自己所使用的实现技术对需求进行归类。各个客户也只是从他个人工作的角度出发单独地对需求进行考虑。这些离散的需求所带来的影响就是各人谈论进度或者对变更做出决定的方式都不一致。按照产品版本的主题再取折衷已不可能，因为根本就不存在一致的主题；相反，产品变成了混杂着各种玄机的大杂烩。

为什么如此多的产品最后以沦为特性汤收场呢？这一切都始于需求的源头——人们。

人们很自然而然地会认为自己的需求才是最重要的。同一个组织中的不同部门，或者不同的客户，都想获得属于自己的、与众不同的特性，于是提出的需求根本不顾及产品在整体业务上的一致性也就不足为奇。而这，就是分析师的工作了。

当零散的需求来了之后，分析师需要将它们与受之影响的业务流程映射起来。这种映射提供了一种方法——向不同的人们展示建议的变更对他们的工作可能产生的影响（有时非常令人惊讶）。这种分析让分析师获得了基本的理解，从而进一步发现人们真正需要的——以及变更是否提供了真正的好处，抑或仅仅是另一个滴入汤中的特性。

特性汤的另一个来源是设计人员在面对一项新需求的时候，不去追究其与既有产品在整体上的关联，就将其加入进来。设计人员应该发问，“它是否属于已声明的范围？”“与既有产品的接口是什么？”“它是否重复或者搞乱了已经存在的东西？”

在解决这些问题上的重复失败导致产品变成了一堆离散碎片的组合。需求是基于离散的特性，从本质上这意味着项目对于“什么是属于范围内的”以及“什么是超出范围的”没有客观的定义。因此，额外的需求就很容易从不同的来源渗透进产品里面——事实也确实如此。产品变得越发分离崩析，它也就越发难以评估，做出的变更就越发难以前后一致；一路螺旋直下，回天无术。

避开特性汤的组织有着很多的共同点：

• 尽可能不留余地、尽可能早地定义项目目标和非项目目标。

• 声明项目范围，并以精确定义输入/输出数据的形式时刻保持更新（参阅第24项模式，“白线”）。

• 拒绝那些对声明的目标没有积极效应、而又明显超出项目范围的需求——进一步锤炼、巩固了钢铁般的意志。

• 新需求的添加遵照被核准的、可追溯的变更管理流程进行，同时使用项目声明的目标对它们进行评估。

避免特性汤得靠纪律。时刻牢记着是你们——整个项目团队，而不是零散特性的请求者——将会身陷浓汤：这绝对划算。