發表日期 3/5/2022, 10:19:57 AM
作者 | Simón Mu oz
譯者 | Sambodhi
策劃 | 辛曉亮
本文不隻針對産品經理。創始人、投資者,或者任何其他在任何數字産品或服務方麵有足夠關係的人都可以利用本文的觀點。
我相信這一點,因為我們將討論創建産品時最普遍的問題之一: 過度設計産品。依我看,過度設計要比缺乏良好的開發實踐扼殺更多的産品。
在討論詳細情況之前,讓我來介紹一下我的背景。當上産品經理之前,我是個工程師。實際上,我受過計算機科學的正規訓練。盡管在我的職業生涯中,我總是更接近業務,而不是自己編寫代碼,但我創建、擴展並管理瞭工程和産品團隊,而且規模相當。
所以,我並不是從外錶來談論過度設計的問題。對於自己造成的這一切,我感到內疚,並且承受瞭這一切。由於這個原因,我知道瞭解它的重要性,知道它的代價,以及如何防止它。
什麼是過度設計?
如果我們按照維基百科的嚴格定義來看,過度設計指的是以超過必要的更復雜方式設計産品的事實:
過度設計 (或 過度工程化 ,或 性能過剩 )指的是以過於復雜的方式設計産品或提供問題的解決方案的行為,而在這種情況下,可以證明存在一種更簡單的解決方案,其效率和效果與原始設計相同。
就軟件而言,我喜歡 Pawe G ogowski 的這個定義:
解決你所沒有的問題的代碼或設計。
如今,你會想,誰會設計或編程來解決一個他 / 她所沒有的問題呢?這似乎很荒謬,是吧?嗯,請坐穩椅子,因為在經曆瞭二十年的職業生涯之後,我可以嚮你保證,過度設計並非例外:這是常態。
過度設計的原因
誰也不是齣於惡意這麼做的。很多時候,過度設計發生的原因是 我們試圖預測未來 ,對未知的事物做好準備。
在編寫一個功能時,很容易想到,隻要我們投入更多的時間,就能“以防萬一”,使其經得住未來的考驗。
而現實是,十有八九,這個“以防萬一”永遠也不會到來。但是,在這個過程中,我們浪費瞭寶貴的時間,增加瞭項目的復雜性,這一點我們將貫穿項目的整個生命周期。
一般問題
過度設計的另一個原因往往是 缺乏經驗 。一般而言,你的資曆越深,就越不容易過度設計,因為你已經經曆過大量的人為復雜性的情況。
關於工程師經驗的學習麯綫通常遵循與此非常相似的模式:
你從一個簡單的方式開始編程。
你找到瞭像麵嚮對象這樣的範例,並與潮流相結閤。
你閱讀瞭有關設計模式的文章,並在各種情況下尋找實現它們的機會。
經過數年不必要的復雜性之後,你又迴到瞭編寫簡單的代碼。
代碼復雜性與經驗
界定寬鬆的需求 也會加劇這一問題。假如一個工程師沒有一個明確界定的問題,他就會傾嚮於過度設計來避免不確定性。
無聊 同樣也會導緻過度設計。假如一個工程師沒有激動人心的挑戰要麵對,他很可能隻是嘗試瞭一些新事物,最終使問題復雜化。
過度設計的後果
在文章一開始,我就提到過度設計將扼殺初創公司,我並不是在開玩笑。對於任何係統,它有兩種特彆的反常影響。
一方麵, 這會增加開發成本 。假如我們的工程師不選擇最簡單的解決方案來解決一個問題,我們的時間和金錢成本將會增加,讓我們無法更快地完成迭代。請觀看 Lisa Vigar 的 MTP Hamburg 演講《語音産品的迭代》(Iterating Your Voice Product)。
另一方麵,這也 會增加維護成本 。簡單的代碼更易於編程、測試和修改。隨著復雜度的增加,復雜性會以指數級增長,影響迭代速度。
因此,我重申瞭自己的論點,過度設計將扼殺産品。遠不止缺乏良好的工程實踐。之所以如此,這是因為要從良好的實踐中獲益,你需要有産品與市場的契閤度,而過度設計會使你首先無法得到它。
過度設計的例子
第一個想到的是 基於微服務的架構 。在幾年前,它們像浪潮一樣湧來,它們應該比它們所集成的項目還要多。
我把它們作為過度設計的一個例子,因為它們在 99% 的情況下都是沒有必要的,特彆是對於那些必須找到市場契閤點的初創公司來說,更直接地使用諸如“雄偉的”單體架構模式會帶來很多好處。
假如你成功地找到瞭市場契閤點,結果發現,由於規模問題,你最終需要切換到微服務,哦,天呐,這是個好問題。
過早的優化 往往是另一個過度設計的典型例子。一個常見的情況是,當你還沒有用戶時,就準備在一個過於復雜的基礎設施設置中吸收大量流量的係統。多數情況下,你隻需要在單一服務器上運行單體應用,就可以驗證你的業務模式。
過早優化的一個最糟糕的例子就是,我們花費瞭大量的時間來設計一個係統,以避免將來重復自己的工作,而放棄已完成的部分工作。
如果你以前因為破産而從來沒有看到過它的工作,那麼你的設計或實現有多麼完美,都無關緊要瞭。即使是這個星球上最糟糕的代碼,幫助你驗證一個假設,總好過因為害怕不重復自己的工作而停滯不前。
和上麵提到的一樣,軟件重寫是一個明顯的過度設計的例子。通常情況下,工程師並不喜歡在遺留的代碼庫上工作。他們的自然傾嚮是一切從頭做開始。但是,就像 20 多年前 Joel Spolski 在《你永遠不應該做的事》(Things you should never do) 中寫道,重寫很少能達到目的,甚至會奪走你的生意。
顯然,這是顯而易見的,但是你的客戶並不關心你的係統在內部有多好。你的客戶關心的是,你是否幫助他解決瞭問題。沒有給予他們價值而投入的每一分鍾都是浪費的一分鍾。
如何避免過度設計
在我看來,避免過度設計的最好方法是 讓你的工程師成為真正的産品工程師 。
為瞭實現這一目標,我們可以讓他們參與日常業務,在每項舉措之後解釋為什麼,並將其與對組織及其願景重要的指標聯係起來。
觀看 MTP 小組討論,以進一步瞭解定義重要指標的重要性。
我們需要讓他們和用戶更緊密地聯係在一起,邀請他們與我們的用戶進行訪談和發現會議。你希望你的團隊能夠與你的用戶的問題産生緊密的共鳴,從而使他們能夠迅速地放棄那些不能最有效解決問題的工程措施。
假如你隻是把工程團隊看作是一個生産鏈資源,它唯一的任務就是從積壓的工作中實現用戶描述,那麼就不要指望他們能有動力避免復雜性。他們需要瞭解每一個決策背後的原因。
與此相關, 正確定義問題來減少模糊性 。工程師需要知道原因,但是他們也需要知道預期的是什麼。你越能縮小問題的範圍,他們保護自己不受過度設計解決方案影響的理由就越少。定義一個係統的期望的好方法是通過使用 SLI 和 SLO 的服務目標。
在任何公司裏,工程師都是最有創造性的人。當你的團隊相信你的標準時,他們的日常想法或主動性就會顯現齣來,這可能錶明他們是在考慮將來的“假設”場景。如果你有這樣的直覺, 問問自己:這對解決當前用戶的問題有什麼幫助?要是我們現在不乾呢? 他們的迴答會幫助你辨彆這是否是一種過度設計的情況。
最後,更多的是麵嚮創始人,優先聘用已經在産品公司有一定經驗的高級工程師。尋找“戰爭創傷”的麵試。詢問他們最痛苦的經曆以及他們是如何應對的。堅持聘用那些把用戶和簡單性放在簡單的技術解決方案之前的人。
避免過度設計的心智模式
YAGNI
在業界中,過度設計的問題很普遍,工程師們自己就用瞭一個術語來指代添加代碼“以防萬一”的情況: YAGNI ,就是“你不會需要它”(You are not going to need it)的首字母縮寫。
YAGNI 試圖阻止你添加任何在解決你所麵臨的問題上並非絕對必要的內容,因為事實是,最有可能的是,“你不會需要它”。
KISS
KISS 一詞,也就是“保持簡單直白”(Keep it simple stupid)的首字母縮寫,是指更加易於對簡單係統進行修復、開發和維護。所以,簡單性應該成為任何設計的目標之一,避免任何不必要的復雜性。
更糟就是更好
“更糟就是更好”,我們要強調的是,擁有更少的選擇比擁有更多的選擇更可取。之所以這樣,是因為它可以簡化我們産品的使用,使其在更廣闊的市場範圍內具有吸引力。
換句話說,它鼓勵我們保持産品的最低限度的基本功能,避免增加“脂肪”,以免增加産品的復雜性。
總 結
總結一下,過度設計有可能摧毀你的初創公司,它可能:
增加不必要的復雜性。
增加開發和維護成本。
降低你的迭代速度。
使你無法適應市場。
遺憾的是,過度設計並非例外;它是常態。齣於這個原因,瞭解其中所包含的內容非常重要,並且努力避免這種情況的發生,首先要讓你的工程師參與進來,解決客戶的實際問題。
在沒有解決客戶實際問題的開發中,我們投入的每一分鍾都是一種浪費。不要掉進““以防萬一”的陷阱。
墓地裏充斥瞭設計精巧的初創公司和産品,可以擴展到數以百萬計的用戶,而這些用戶從來沒有得到過一丁點兒的關注。彆成為他們中的一員。
作者介紹:
Simón Mu oz,一位西班牙富有激情的産品經理,擁有創業背景和軟件工程教育背景,並曾在多傢技術公司工作 20 多年,積纍瞭豐富的管理經驗。現在在 VoiceMod 工作,開始執行一項為每個人提供 Sonic 身份的任務。
https://www.mindtheproduct.com/overengineering-can-kill-your-product/