OOPAA

    “體面湯、濃又黃，

盛在鍋里不會涼！

說什么山珍海味，哪兒有這樣兒香？

半夜起來喝面湯，體面湯！”

——劉易斯·卡羅爾（Lewis Carroll），《愛麗絲漫游仙境》

產品夸耀自己繁多的零碎特性，其中很多對于解決客戶真正的業務需求幾乎毫無幫助。

在一開始的時候，一切都顯得那么美好。市場部有一個來自于客戶的請求——添加額外的下拉菜單。然后，在產品中添加一個輸出接口的需求來了，產品經理想要加上一份新的分析報表，DBA要求在數據庫里增加一個新字段以改變背景的顏色。所有這些需求以及其他更多的需求，都交由開發人員負責加進到產品里面。隨著需求的不斷添加，產品的特性集不斷增長，但過了一段時間之后，每個人——市場部、客戶和開發團隊——對如何將所有這些碎片整合在一起、這些碎片如何幫助實現業務目標，失去了理解。曾經帶著明確目標出發的項目變成了難以下咽的、由各種無關特性燉成的一鍋湯。

情況變得更加湯汁淋漓，因為感興趣的各方都從不同的角度來看待產品的需求，根本不存在共同的、連通的思路。市場部從營銷的角度把需求打包成一組一組的特性集合，也不管它們在功能上是否內聚。開發人員則按照自己所使用的實現技術對需求進行歸類。各個客戶也只是從他個人工作的角度出發單獨地對需求進行考慮。這些離散的需求所帶來的影響就是各人談論進度或者對變更做出決定的方式都不一致。按照產品版本的主題再取折衷已不可能，因為根本就不存在一致的主題；相反，產品變成了混雜著各種玄機的大雜燴。

為什么如此多的產品最后以淪為特性湯收場呢？這一切都始于需求的源頭——人們。

人們很自然而然地會認為自己的需求才是最重要的。同一個組織中的不同部門，或者不同的客戶，都想獲得屬于自己的、與眾不同的特性，于是提出的需求根本不顧及產品在整體業務上的一致性也就不足為奇。而這，就是分析師的工作了。

當零散的需求來了之后，分析師需要將它們與受之影響的業務流程映射起來。這種映射提供了一種方法——向不同的人們展示建議的變更對他們的工作可能產生的影響（有時非常令人驚訝）。這種分析讓分析師獲得了基本的理解，從而進一步發現人們真正需要的——以及變更是否提供了真正的好處，抑或僅僅是另一個滴入湯中的特性。

特性湯的另一個來源是設計人員在面對一項新需求的時候，不去追究其與既有產品在整體上的關聯，就將其加入進來。設計人員應該發問，“它是否屬于已聲明的范圍？”“與既有產品的接口是什么？”“它是否重復或者搞亂了已經存在的東西？”

在解決這些問題上的重復失敗導致產品變成了一堆離散碎片的組合。需求是基于離散的特性，從本質上這意味著項目對于“什么是屬于范圍內的”以及“什么是超出范圍的”沒有客觀的定義。因此，額外的需求就很容易從不同的來源滲透進產品里面——事實也確實如此。產品變得越發分離崩析，它也就越發難以評估，做出的變更就越發難以前后一致；一路螺旋直下，回天無術。

避開特性湯的組織有著很多的共同點：

• 盡可能不留余地、盡可能早地定義項目目標和非項目目標。

• 聲明項目范圍，并以精確定義輸入/輸出數據的形式時刻保持更新（參閱第24項模式，“白線”）。

• 拒絕那些對聲明的目標沒有積極效應、而又明顯超出項目范圍的需求——進一步錘煉、鞏固了鋼鐵般的意志。

• 新需求的添加遵照被核準的、可追溯的變更管理流程進行，同時使用項目聲明的目標對它們進行評估。

避免特性湯得靠紀律。時刻牢記著是你們——整個項目團隊，而不是零散特性的請求者——將會身陷濃湯：這絕對劃算。