Scott Davis — Broomfield, Colorado, USA
微波爐的啟示#
作者說自己的微波爐實際上只用一個按鍵：「加一分鐘」。煮開水按三下，融化起司按一下，加熱薄餅則按下後 15 秒開門——就這樣。
但他的微波爐實際上有許多從未用過的功能。為什麼？因為設計委員會偏好複雜性，並把它美化成「功能豐富（feature-rich）」。
沒有人一開始就想做出不必要的複雜產品。複雜性是在不注意時偷偷滋生的。
複雜度放大器 vs. 複雜度吸收器#
以 Amazon 的「一鍵購買（one-click purchase）」為例——用戶只需點擊一次，背後的複雜邏輯全由系統承擔。
軟體本質上處理複雜問題。真正的問題是：你把多少複雜性轉嫁給了使用者？
- 複雜度放大器：將問題的複雜性傳遞給使用者，讓他們負擔
- 複雜度吸收器（complexity sink）：代替使用者承受問題的複雜性
重點： 優秀的軟體是複雜度吸收器——它替使用者扛下問題的複雜性，而不是把它轉嫁出去。
專案經理也是複雜度吸收器#
身為軟體專案經理，你同樣需要在各方之間扮演複雜度吸收器的角色：
- 當使用者提出看似矛盾的需求，你的工作是協助釐清，而不是原封不動丟給開發人員
- 當開發人員以晦澀的技術理由說某個需求無法實現，你的工作是轉化這個複雜性，給使用者足夠的資訊，引導他們選擇替代方案
值得不斷自問的問題#
- 你的應用程式使用起來有多容易？
- 新增一個功能有多容易？
- 回報一個 bug 有多容易？
- 部署新版本、回滾壞版本有多容易？
技巧： 簡潔不會自然發生，需要主動經營。複雜性是你不注意時自然滋生的東西——必須有意識地抵制它。
補充： 複雜性往往藏在「功能豐富」的美好說辭背後。在評估每一個新功能時，先問：「這真的是使用者需要的，還是我們覺得應該有的？」