原則39　先確定問題，再寫需求

DETERMINE THE PROBLEM BEFORE WRITING REQUIREMENTS

當面對他們認定的問題時，大多數工程師都會匆忙提供解決方案。如果工程師對這個問題的看法是正確的，那么解決方案可能奏效。然而，問題往往是難以捉摸的。例如，唐納德·高斯（Donald Gause）和杰拉爾德·溫伯格（Gerald Weinberg）描述了高層辦公樓中的一個“問題”，里面的住戶抱怨電梯等待時間太長。這真的是一個問題嗎？這是誰的問題？從居住者的角度來看，問題可能是浪費了他們太多時間。從房主的角度來看，問題可能是入住率（及租金）可能會下降。

顯而易見的解決辦法是提高電梯的速度。但其他解決方法可能包括（1）增加新電梯，（2）錯峰安排上班時間，（3）給快遞保留一些電梯，（4）提高租金（這樣業(yè)主可以接受降低后的入住率），（5）改進電梯使用的“歸位算法”（homing algorithm），以便在閑置時移動到高需求樓層。這些解決方案的成本、風險和時間延遲差別巨大。而任何一個方案生效，都取決于特定的場景。在試圖解決問題前，針對面臨問題的人及問題的本質，要確保深入分析了所有的可能選擇。在解決問題時，不要被最初方案帶來的潛在興奮所蒙蔽。方案的變化總是比構建系統的成本低。

Gause，D.，and G.Weinberg，Are Your Lights On？ New York: Dorset House，1990.