- 原文地址：Imaginary problems, the root of bad software
- 原文作者：George
- 譯文出自：掘金翻譯計劃
- 本文永久連結：github.com/xitu/gold-m…
- 譯者：ssshooter
從使用的工具，到團隊內部的溝通質量，到開發人員的利益，以及你使用的測試方法，有許多因素可以成為低質量軟體的催化劑。
我認為其中最主要的問題是，幾乎所有低質量軟體的根源：虛構問題。
複雜的軟體並非設計之初就過於繁雜或功能失調。只是因為它在製作過程中添油加醋，最終結果有別於初心。
播客應用
假設您是播客主持，想擁有自己的網站，可以在其中銷售促銷產品，可以不經第三方接廣告，最重要的是，向您的觀眾提供播客，視訊和部落格文章。
你這個小小的網頁應用可能有如下要求：
- 北美地區可以快速載入內容，播客直播與下載。
- 99.99% 的使用者在前 15 分鐘內不會遇到應用崩潰，當然，最好永遠不會發生。
- 與 Google AdWords 較好地整合，有時間的話再接入其他廣告商。
- 動態連結到我的 Zazzle 上的最新產品，可以的話，根據使用者觀看的劇集向使用者提供推薦。
- 因為我在 Facebook 做直播，所以要整合 Facebook 直播模組。如果可以自己做出一套直播系統，不依賴於 Facebook，那就更好了。
你把這些要求交給一個承包商，聊了一下。兩個月後，他們向你展示 MVP，你氣炸了，你覺得浪費了 15000 美元在一件垃圾上，你只想把你的錢要回來。
看著這東西生氣是正常的，因為第一次開啟它時螢幕像當機一樣。你問他如何修改網站上的廣告，他指了指那個又醜又讓人看不懂的自定義 UI。Zazzle 的商品連結有一半是破損或是缺少影像的，Facebook 直播流還有延遲！
但開發團隊對你的憤怒感到困惑，從他們的角度來看，他們已經為你赴湯蹈火了。
他們全心全意編寫了這個應用，它有一些驚人的特性：
- 最先進的推薦系統。
- 轉播你的視訊或直播的演算法（用於前面提到的推薦系統）。
- 世界各地可在 200ms 內載入你的首頁。
- 幾乎從頭開始構建流媒體協議和客戶端，你隨時可以從 Facebook 直播切換過來。
- 可讓你輕鬆整合 20 多個廣告平臺的服務。
問題來了，你需要的僅僅是核心功能，如果有餘力實現，才加入其他特性。然而，開發團隊收到的需求可能截然不同了。開發團隊聽到了一些激動人心的挑戰……還有一些無聊的基本功能，他們不怎麼在意。
最慘的是你沒有直接與開發者溝通，而是像在玩傳話遊戲一樣，跟一個銷售人員談過，銷售人員與中層管理人員會面，然後編寫了套業務規範並將它們交給了 PM，PM 編寫了一些技術規範並將它們交給了團隊負責人/架構師，負責人開始與他的團隊設計產品。每經過一層交接，需求都可能被扭曲。
這是一種應對機制
想象問題通常比實際問題更好玩。天才喜歡玩競技遊戲，構建和解決數學問題，甚至編寫試圖回答有關人類狀況這種抽象問題的書籍，所有這些都是免費的。不過，一般程式設計師可能會向您收取相當數量的費用，為你構建一個相對簡單的 Android 應用。這不是因為平庸的程式設計師比天才更難找到，只是因為前者做的事情都很有趣，後者可能會比較無聊。
大多數程式設計師希望獲得報酬並同時獲得樂趣。但是，對大多數情況下，這相當困難。當然，對於我們大多數人來說，“樂趣”的定義是完全不同的，但對於許多工程師來說，“樂趣”可以歸結為，可解決性範圍內，有趣並具有挑戰性的問題。
你給一個有點頭腦的人一堆不能自動化完成的無聊任務，他們遲早會被逼瘋。不過經歷了數十億年的進化，人類大腦在保持理智方面非常有才能。就像童年困難或虐待的受害者可以在童話書中得到解脫，企業程式設計或自由網路開發的受害者可以在解決虛構問題中得到解脫。
軟體工程師為自己創造虛構問題的數量，與他們的想象力和他們應該解決的實際問題的難度有關。
我們應該意識到，這個問題並不是開發人員所獨有的。管理，銷售，HR，顧問，法務甚至會計都有自己獨有的方式來創造虛構問題。當他們出席的會議內容很少涉及到自己的時候，他們主動讓自己更多地參與決策，過分強調與他們角色有關的問題（例如法務：我們的狗狗日託 App 必須從上線第 1 天 101% 符合 GDPR，我們不能成為法律先例）。儘管沒有必要，他們還是僱用了一整個團隊處理這個問題，這麼做顯得他們在這個專案中很重要，有做實事。
人是活的，問題是死的，所以聰明人總能找到一種應對方式。
傳話驅動式設計
虛構問題不僅僅因為開發人員太無聊，也因為溝通鏈太長。
我偶爾會接一些外包。以前，外包客戶是不能自己挑的，這就意味著我甚至可能會在工作中遇到 DID（人格分裂）和 ADHD（多動症）病例。我曾收發了 100 多封郵件，僅僅是討論 MVP 裡微不足道的細節；曾遇到有人在一週內把專案中的每一個需求都改了個遍的情況；曾有客戶問過諸如“這可以發行虛擬貨幣嗎？”或“我們可以在這裡加人工智慧嗎？”等問題。
當然，大多數客戶還是理智的，但他們往往因為缺乏相關知識，無法清晰表達他們的需求。但這沒問題，因為這是我作為“計算機專業人員”工作的一部分，幫助人們根據他們的使用場景，判斷他們的軟體需要或不需要什麼。但是當你和客戶之間相隔數層，這件事便會變得十分困難。
大多數公司喜歡僱傭銷售人員安利潛在客戶，協商價格並概述這個價格可以得到什麼功能。還有另一批善於交際的人與客戶討論更多深度要求和細節，其實他們也算是銷售人員，只是職位名稱不同。接著是內部領導層的意見，多級管理層以及技術團隊內部的層級結構。
需求經歷這麼多人，即使這些人的意見是好的，事情也會發生變化。有些會因其無意義而被改變，這些定義是愚蠢的，所以需要重新定義。銷售人員可能會說“只要多付 39999，我們就可以在區塊鏈上實現這個功能”……然後後面的人要思考“在區塊鏈實現這個功能”是什麼鬼意思。
所以通常需求變化的原因有兩點，在多級傳遞中有人誤解了某些事情，或者有人使用上述應對機制來使他或團隊的工作更有趣和令人印象深刻。
因此，最原始的需求，最迫切需要解決的問題，在各級傳達中丟失。並被虛構問題和一片空白所取代，接著，大家都用他們自己虛構問題填補這些空白，因為現有的問題真的很讓人乏味，他們一個應對方式便是填補這些空白。
過度複雜和自然選擇
通常情況下，存在虛構問題更深層的原因是，它們有助於團隊或公司的壯大，虛構問題成為維持公司不可或缺的一部分。
People who are bred, selected and compensated to find complicated solutions do not have an incentive to implement simplified ones. — Taleb
你聽說過僅靠三位工程師就能輕鬆地搭建網上銀行系統的情況嗎？他們使用功能設計理論和記憶體安全語言，從頭開發了一些完美無瑕的銀行軟體，然後開始將大型銀行遷移到他們驚人的基礎設施。
可能沒聽過，因為根本不存在。甚至，還有成千上萬的團隊成千上萬的開發人員，連“回滾”這麼簡單的概念都不清楚，而恰恰是他們，在日復一日地編寫銀行軟體。
數字的儲存和傳輸的技術要求並不高。建立整個網際網路的索引，在 2 秒內提供問題搜尋結果才是一個難題，只有少數聰明人去想方設法解決這個問題。
問題在於銀行生態系統非常善於保持一種無人監管的狀態。這臺執行良好的機器保留了自己的斂財機制。它的領導者是掠奪於社會的腐敗者，但組織的領導者只是其成員的一個象徵。
我的意思不是在銀行工作的人都是壞人。相反，他們通常是很友善，致力於為家人提高生活質量。但他們要的不是修復銀行軟體，而是保持就業。在現在的經濟環境中，丟了工作可不是開玩笑的。在銀行業中，話多，主動可以讓你更有存在感。
所以銀行業這風氣，不是因為行之有效，而是已經產生了慣性。這種慣性以處理虛構問題的形式出現，以避免解決實際問題。如果點明瞭的真正的問題，給其他人的工作帶來威脅，可能會導致你被解僱，甚至像高盛這樣特別令人討厭的“機構”，給一些聯邦調查局官員寄了封信，然後毀掉你一生。
It is difficult to get a man to understand something, when his salary depends upon his not understanding it! — Upton Sinclair
企業最高管理層（C-suite）不會在意他們的高層管理人員（upper management）將90％的時間花在“客戶會議”上，這些在熱帶島嶼舉辦的“會議”還花費了百萬美元的“其他費用”。因為高層管理人員對他們本身的腐敗視而不見。
高層管理人員不會在意中層管理人員（middle managers）買下幾個古怪的辦公室，僱傭三名祕書和十幾名實習生。因為有了中層管理人員，他們能活在華爾街之狼的幻想中。
中層管理人員不會在意直線經理（line managers）將時間花在怎麼修改“改進我們的敏捷方法”的 PPT，而非降低成本。因為直線經理滿足了他們對獨裁的幻想。
直線經理不會在意技術團隊負責人和架構師滿口都是“下一代系統間的介面使用 JRPC 和 使用 Hibernate 和 Spring 的微服務”，而不是優化那成噸的 Mysql 查詢要查老半天。因為團隊負責人假裝不知道他們的上司甚至連 Excel 都用不好，還幾周到辦公室一次。
團隊負責人不會在意開發人員使用新的 JS 框架，一年改 10 次 UI，而不是檢查以下資料庫查詢為什麼這麼慢。因為開發人員假裝不知道他們的領隊根本沒寫程式碼，最多也就畫個 DOT 圖。
這是一個解決虛構問題的惡性迴圈，從 CEO 假裝不知道多賺三千萬也不能解決自己的家庭問題，到 UX 實習生假裝不知道重新設計一個“提交按鈕”，他們的密碼還是以明文傳輸。
但是每個人都需要不斷解決虛構問題，因為一旦他們停下來關注真正的問題，他們可能會意識到整個系統的崩塌。他們可能會發現 Debra 已經坐在那個角落，盯著內部機房的監控圖表 10 年，儘管該公司 5 年前已經遷移到 AWS。他們可能會意識到他們 99% 的工作就是延續別人的工作……這個事實對絕大部分人都難以接受，所以我才說，他們一定會找到了一種應對方式。
如果發現譯文存在錯誤或其他需要改進的地方，歡迎到 掘金翻譯計劃 對譯文進行修改並 PR，也可獲得相應獎勵積分。文章開頭的 本文永久連結 即為本文在 GitHub 上的 MarkDown 連結。
掘金翻譯計劃 是一個翻譯優質網際網路技術文章的社群，文章來源為 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智慧等領域，想要檢視更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。