糟糕的軟體設計:幻想出來的問題

網易雲社群發表於2018-12-05


翻譯 :蔡雪丹

歡迎訪問網易雲社群,瞭解更多網易技術產品運營經驗。


有許多因素可以成為糟糕的軟體形成的催化劑:從正在使⽤的⼯具,到團隊溝通,到開發⼈員在推動 其成功上可獲得的個⼈利益,再到測試⽅法。


我認為在這其中有⼀個主要問題,⼀個⼏乎可以作為所有軟體變成糟糕軟體推動⼒的根源:幻想出來的 問題。


⼤多數複雜或壞掉的軟體並不是設計得過於複雜或功能失調,它只是被設計做了很多超出預期⽬的的 事情。


假設你是⼀個播客主持⼈,你想要定製⼀個⽹站可以銷售你的⼴告產品,在沒有第三⽅介⼊的情況下 賺錢,最重要的是,可以向你的觀眾提供播客、視訊和部落格。

  • 你的⼩web應⽤的需求可能如下所示:

  • 在北美⽹絡下有較短的載入時間,可以實時播放和下載部落格流。

  • 99.99%的⽤戶⾄少在頭15分鐘內不會崩潰或卡住,最好始終不會崩潰或卡住。

  • 如果有時間的話,最好可以與⾕歌⼴告以及其他⼀些第三⽅⼴告提供商較好地整合。

  • 動態連結到⾃⼰Zazzle商店的最新產品,如果可能的話,可以根據⽤戶消費的內容向他們提供建 議。

  • 與Facebook實時播放器整合。如果可以有⼀個不需要Facebook流媒體的替代解決⽅案就更好 了。

你把這些需求給了⼀個承包商團隊,然後你與他們聊了⼀會⼉,似乎每個⼈都明⽩的你意思。然⽽, 兩個⽉後,當他們帶著最⼩可運⾏產品(MVP)回來時,你的臉變紅了。你發現你只是在⼀塊垃圾上 浪費了15000美元,你想要回你的錢。


因為第⼀次開啟應⽤程式時,螢幕會卡住。你問他們如何選擇允許在⽹站上運⾏的⼴告型別,他們指 出⼀個醜陋、難以讓⼈理解的⾃定義⻚⾯( UI )。半數Zazzle商品連結是斷開的或丟失的圖⽚, Facebook直播流的也有延時!


但是開發者團隊對你的⽓憤感到很困惑—從他們的⻆度來看,這些都是理所當然的--因為他們已經經 歷過地獄式地開發之後回來找你了。

他們全⼼全意建立了這個應⽤,它擁有⼀些驚⼈的功能:

  • 最先進的推薦系統

  • 實時⽣成所有流副本的演算法

  • ⾸屏載入時間在全世界⽹絡內都可以低於200ms

  • 流媒體協議和客戶端⼏乎都是重頭構建的,因為不想依賴Facebook直播

  • 這項服務可以讓你輕鬆整合20多個⼴告交易


這個問題在於你想你的核⼼產品擁有⼀堆額外的功能,如果它們易於實現的話。但是開發團隊聽到的 是不⼀樣的東⻄,他們聽到了⼀些對他們來說可以攻克的挑戰…以及⼀系列⽆聊、基礎,他們根本不 想去測試或者關⼼的功能。


更糟糕的是,你沒有直接與這些開發者進⾏溝通—你就像在玩電話傳聲遊戲⼀樣進⾏溝通。你和⼀個 銷售⼈員談過,他和⼀箇中層管理⼈員開了會,這個管理⼈員寫了⼀些業務規範交給了PM,PM寫了 技術規範交給了團隊負責⼈或⼯程師,最後,這個⼈和他的團隊開始設計這個產品,每個⼈在設計的 過程中或多或少也都加了些⾃⼰的曲解。


更糟糕的是,你沒有直接與這些開發者進⾏溝通—你就像在玩電話傳聲遊戲⼀樣進⾏溝通。你和⼀個 銷售⼈員談過,他和⼀箇中層管理⼈員開了會,這個管理⼈員寫了⼀些業務規範交給了PM,PM寫了 技術規範交給了團隊負責⼈或⼯程師,最後,這個⼈和他的團隊開始設計這個產品,每個⼈在設計的 過程中或多或少也都加了些⾃⼰的曲解。


⼤多數程式設計師希望得到報酬,同時享受樂趣。當然,“樂趣”的定義對每個⼈來說都不⼀樣,但對許多 ⼯程師來說,它歸結為解決可解決範圍內的有趣且富有挑戰性的問題。

糟糕的軟體設計:幻想出來的問題


給⼀個有點聰明的⼈太多⽆法⾃動化的⽆聊任務,你最終會讓他發瘋。然⽽,經過數⼗億年的進化, ⼈類的⼤腦在保持理智⽅⾯⾮常有天賦。就像童年困苦或虐待的受害者可以在幻想書中找到逃避,企 業中或者進⾏⾃由web開發的受害者可以在解決想象中的問題時獲得解脫。 ⼀個軟體⼯程師可以想象出來問題的數量取決於他們的想象⼒,也取決於他們應該解決的真實問題難度。


應該注意的是,這個問題並不是開發者獨有的,管理部⻔、銷售部⻔、⼈⼒部分、後勤⽀持、法務, 甚⾄會計部⻔都有他們獨有的⽅式來建立想象中的問題。當他們沒有被要求或者形式性地參加某⼀會 議時,會試圖讓⾃⼰更多地參與決策。他們過分強調某個與他們⻆⾊相關的⼩問題,或者招募更⼤的 團隊來說明他們的重要性。


當問題變得愚蠢時,聰明的⼈總能找到解決的辦法。


但是很多想象中的問題並不僅是⽆聊的開發者造成的,它們也有可能是⻓溝通鏈產⽣的結果。


當我第⼀次開始接觸⾃由職業客戶時,不可謂不過分周到。我們電⼦郵件的交談鏈已經持續了100多 次,僅僅討論關於內部MVP的⼀些⽆關緊要的細節。我讓⼈在⼀周內改動了項⽬的每⼀項要求,我問 了⽤戶⼀些問題,⽐如“這是ICO嗎?或者“我們能在這⾥新增⼀些⼈⼯智慧元素嗎?"


誠然,⼤多數客戶都⽐這更精明,但即使如此,他們經常缺乏表達或構建⼀些需求所需的知識。這很 好,作為我“計算機⼈員”職業的⼀部分,我的⼯作就是幫助⼈們根據他們的⽤例指出他們想做什麼和 不需要什麼。但是當你和客戶之間隔了好⼏層進⾏溝通時,確定需要什麼就變得更加困難了。


需求變更是因為有⼈誤解了⼀個意圖,或者是因為有⼈試圖應付上述⽆聊的需求


⼤多數公司喜歡由⼀個銷售⼈員對潛在客戶進⾏推銷,協商價格,並概述可能的功能。他們也專⻔有 ⼀個⼈與客戶討論更深⼊的需求和細節,這通常是另⼀個銷售⼈員,但職別略有不同。然後是技術團 隊內部的指揮鏈、各種級別的管理,可能還有⼀些其它層級結構。


當⼀份客戶需求列表流轉很多⼈時,即使這些⼈擁有最好的想法,⼀些東⻄也不可避免地會在層層翻 譯中丟失。有時,這種變化是因為最初的需求沒有意義,或者有時需要重新定義需求。銷售⼈員可能 會告訴客戶,“只需額外⽀付39,999英鎊,我們就可以在區塊鏈做這件事。但這讓所有遇到需求的⼈ 都想知道“在區塊鏈上做”的定義是什麼。"


很多時候,需求會改變是因為有⼈誤解了⼀個意圖,或者因為有⼈試圖應付上述⽆聊的需求,試圖讓 他的⼯作或者他團隊的⼯作更有趣,更令⼈印象深刻。


因此經歷所有這些,最初的需求—真正的問題在這過程中已經被溶解了—丟失了。它們被想象中的問 題和空洞所取代,並且你會發現很多⼈已經準備好⽤他們想象中的問題來填補這些空洞,因為他們真 正需要解決的問題很⽆聊,填補這些空洞給了他們⼀種⽅法來應對這種⽆聊。


過度複雜化和⾃然選擇


想象中的問題的存在往往有更陰暗的原因:問題可以幫助團隊或公司成⻓,甚⾄可以成為其功能不可分 割的⼀部分。

那些通過被培養、挑選和補償來尋找複雜解決⽅案的⼈往往沒有動⼒去實施簡化的解決⽅案。 -- Nassim Nicholas Taleb


你聽過那三位web⼯程師嗎?他們發現安全的⽹上銀⾏其實是⼀個很容易解決的問題,他們從零開始 開發了⼀些完美的銀⾏軟體,使⽤功能設計⽅法論和記憶體安全語⾔,然後開始將主要銀⾏遷移到他們 驚⼈的基礎設施中。


也許你沒有聽過過他們,因為他們不存在。然⽽,有許多由成千上萬的開發⼈員組成的團隊,他們⽆ 法掌握像“回滾”這樣的簡單概念,從⽽不斷創造銀⾏軟體。


數字的儲存和傳輸並不是⼀個特別困難的問題,檢索整個互聯⽹內容並在短時間內為⾃然語⾔查詢提 供相關結果是⼀個難題,但也⼏個聰明⼈設法去解決這個問題。


但是⽹上銀⾏業存在的問題是,銀⾏⾃身的⽣態系統已經⼗分善於維持⾃⼰的賺錢等級,它的領導者 是腐敗的⽔蛭,他們掠奪社會--但組織中的領導者只是其成員的⼀個症狀。


我不認為⼤多數銀⾏下屬員⼯是邪惡或懷有惡意的,與此相反,他們通常是⼀些友好的⼩夥⼦,為家 庭提供⻝物、住所和教育,但是他們的主要動機並不是修復銀⾏軟體,⽽是保住⼯作。對⼀些⼈來 說,這今天的經濟形勢下失去⼯作不是開玩笑的事;在銀⾏業,嘴巴⼤或太過主動表現很容易在紀律 委員會⾯前暴露⾃⼰。


因此,銀⾏系統仍然保持原樣--不是因為這些系統是⾼效的,⽽是因為慣性。這種惰性的表現形式是 為了解決想象中的問題,以避免解決真正的問題。—真正的問題⼀旦被指出,就會威脅到其他⼈的⼯ 作。聚焦於這些真正的問題可能會導致被解僱,甚⾄,在⼀些特別惡劣的“機構”,⽐如⾼盛,讓⼏個 毀滅⽣活的棕⾊信封送到聯邦調查局那⾥會引發奇怪的⾃殺。


當⼀個⼈的薪⽔取決於他對某件事的不瞭解時,要讓他了解某件事是很困難的!- — Upton Sinclair


⾼層管理員忽略了這樣⼀個事實,即他們的上層管理⼈員的90 %的時間都花在“客戶會議”上,這些會 議涉及熱帶島嶼和數百萬美元的“其它費⽤”預算。作為回報,這些上層管理⼈員對他們上級的腐敗視 ⽽不⻅。


上層管理⼈員忽略了那些購買古怪辦公室並給⾃⼰僱⽤三名祕書和⼗⼏名實習⽣的中層管理⼈員,因 為中層管理⼈員⿎勵他們⽣活在華爾街的幻想中。


中層管理⼈員也忽略了這樣⼀個事實,即⽣產線管理層把時間都花在了關於“改進我們的敏捷⽅法”的 PPT演示上,⽽⾮削減成本,因為⽣產線管理層並不抱怨他們的獨裁權⼒幻想。


⽣產線管理層則忽略了團隊負責⼈和架構師談論的“我們使⽤JRPC的系統和使⽤Hibernate和Spring的 微服務之間的下⼀代接⼝”,所以當他們應該⽤不到⼀天的時間來處理那些該死的MySQL查詢。因為 團隊負責⼈似乎沒有注意到他們的上級甚⾄不能正確使⽤Excel,並且僅僅只是隔⼏周來⼀次辦公室。


團隊負責⼈並沒有抱怨他們的開發⼈員,⽽是檢視了前⾯提到的緩慢查詢的解釋,並在那年第⼗次使 ⽤新的JavaScript框架重新設計UI。因為開發⼈員似乎沒有注意到他們的領導除了DOT圖之外沒有真 正編寫過任何程式碼。


這是⼀個解決想象問題的惡性迴圈,從沒有意識到再偷3000萬也不會讓他的⽗親愛上他的CEO,到沒 有意識到使⽤Angular-Material-Bootstrap 19.13.5重新設計“提交”按鈕並不會讓他們以明⽂形式儲存 密碼(並將其作為授權cookie的⼀部分)的事實消失的UE實習⽣。


但是每個⼈都需要繼續解決想象中的問題,因為如果他們停⽌製造和解決這些問題,如果他們開始關 注真正的問題,他們可能會意識到整個系統已經崩潰。他們可能意識到Debra已經坐在那個⻆落⾥, 盯著內部伺服器叢集的正常運⾏時間圖看了10年,儘管該公司五年前搬到了AWS。他們可能意識到他 們99 %的⼯作是讓別⼈的⼯作永垂不朽。這是⼀個難以接受的事實——我敢說,對⼤多數⼈來說是不 可能的。因此,⼤多數⼈找到了⼀種應對的⽅法。


原文:https://medium.com/s/story/imaginary-problems-d4f2921bd1b8


免費領取驗證碼、內容安全、簡訊傳送、直播點播體驗包及雲伺服器等套餐

更多網易技術、產品、運營經驗分享請點選


相關文章:
【推薦】 Spark——為資料分析處理提供更為靈活的賦能
【推薦】 Android優化之記憶體優化倒數計時篇
【推薦】 Spark——為資料分析處理提供更為靈活的賦能


相關文章