過度設(shè)計(jì)會(huì)扼殺你的產(chǎn)品

作者 | Simón Mu oz

譯者 | Sambodhi

策劃 | 辛?xí)粤?/p>

本文不只針對產(chǎn)品經(jīng)理。創(chuàng)始人、投資者，或者任何其他在任何數(shù)字產(chǎn)品或服務(wù)方面有足夠關(guān)系的人都可以利用本文的觀點(diǎn)。

我相信這一點(diǎn)，因?yàn)槲覀儗⒂懻搫?chuàng)建產(chǎn)品時(shí)最普遍的問題之一：過度設(shè)計(jì)產(chǎn)品。依我看，過度設(shè)計(jì)要比缺乏良好的開發(fā)實(shí)踐扼殺更多的產(chǎn)品。

在討論詳細(xì)情況之前，讓我來介紹一下我的背景。當(dāng)上產(chǎn)品經(jīng)理之前，我是個(gè)工程師。實(shí)際上，我受過計(jì)算機(jī)科學(xué)的正規(guī)訓(xùn)練。盡管在我的職業(yè)生涯中，我總是更接近業(yè)務(wù)，而不是自己編寫代碼，但我創(chuàng)建、擴(kuò)展并管理了工程和產(chǎn)品團(tuán)隊(duì)，而且規(guī)模相當(dāng)。

所以，我并不是從外表來談?wù)撨^度設(shè)計(jì)的問題。對于自己造成的這一切，我感到內(nèi)疚，并且承受了這一切。由于這個(gè)原因，我知道了解它的重要性，知道它的代價(jià)，以及如何防止它。

什么是過度設(shè)計(jì)？

如果我們按照維基百科的嚴(yán)格定義來看，過度設(shè)計(jì)指的是以超過必要的更復(fù)雜方式設(shè)計(jì)產(chǎn)品的事實(shí)：

過度設(shè)計(jì)（或過度工程化，或性能過剩）指的是以過于復(fù)雜的方式設(shè)計(jì)產(chǎn)品或提供問題的解決方案的行為，而在這種情況下，可以證明存在一種更簡單的解決方案，其效率和效果與原始設(shè)計(jì)相同。

就軟件而言，我喜歡 Pawe G ogowski 的這個(gè)定義：

解決你所沒有的問題的代碼或設(shè)計(jì)。

如今，你會(huì)想，誰會(huì)設(shè)計(jì)或編程來解決一個(gè)他 / 她所沒有的問題呢？這似乎很荒謬，是吧？嗯，請坐穩(wěn)椅子，因?yàn)樵诮?jīng)歷了二十年的職業(yè)生涯之后，我可以向你保證，過度設(shè)計(jì)并非例外：這是常態(tài)。

過度設(shè)計(jì)的原因

誰也不是出于惡意這么做的。很多時(shí)候，過度設(shè)計(jì)發(fā)生的原因是我們試圖預(yù)測未來，對未知的事物做好準(zhǔn)備。

在編寫一個(gè)功能時(shí)，很容易想到，只要我們投入更多的時(shí)間，就能“以防萬一”，使其經(jīng)得住未來的考驗(yàn)。

而現(xiàn)實(shí)是，十有八九，這個(gè)“以防萬一”永遠(yuǎn)也不會(huì)到來。但是，在這個(gè)過程中，我們浪費(fèi)了寶貴的時(shí)間，增加了項(xiàng)目的復(fù)雜性，這一點(diǎn)我們將貫穿項(xiàng)目的整個(gè)生命周期。

一般問題

過度設(shè)計(jì)的另一個(gè)原因往往是缺乏經(jīng)驗(yàn)。一般而言，你的資歷越深，就越不容易過度設(shè)計(jì)，因?yàn)槟阋呀?jīng)經(jīng)歷過大量的人為復(fù)雜性的情況。

關(guān)于工程師經(jīng)驗(yàn)的學(xué)習(xí)曲線通常遵循與此非常相似的模式：

你從一個(gè)簡單的方式開始編程。

你找到了像面向?qū)ο筮@樣的范例，并與潮流相結(jié)合。

你閱讀了有關(guān)設(shè)計(jì)模式的文章，并在各種情況下尋找實(shí)現(xiàn)它們的機(jī)會(huì)。

經(jīng)過數(shù)年不必要的復(fù)雜性之后，你又回到了編寫簡單的代碼。

代碼復(fù)雜性與經(jīng)驗(yàn)

界定寬松的需求也會(huì)加劇這一問題。假如一個(gè)工程師沒有一個(gè)明確界定的問題，他就會(huì)傾向于過度設(shè)計(jì)來避免不確定性。

無聊同樣也會(huì)導(dǎo)致過度設(shè)計(jì)。假如一個(gè)工程師沒有激動(dòng)人心的挑戰(zhàn)要面對，他很可能只是嘗試了一些新事物，最終使問題復(fù)雜化。

過度設(shè)計(jì)的后果

在文章一開始，我就提到過度設(shè)計(jì)將扼殺初創(chuàng)公司，我并不是在開玩笑。對于任何系統(tǒng)，它有兩種特別的反常影響。

一方面，這會(huì)增加開發(fā)成本。假如我們的工程師不選擇最簡單的解決方案來解決一個(gè)問題，我們的時(shí)間和金錢成本將會(huì)增加，讓我們無法更快地完成迭代。請觀看 Lisa Vigar 的 MTP Hamburg 演講《語音產(chǎn)品的迭代》（Iterating Your Voice Product）。

另一方面，這也會(huì)增加維護(hù)成本。簡單的代碼更易于編程、測試和修改。隨著復(fù)雜度的增加，復(fù)雜性會(huì)以指數(shù)級(jí)增長，影響迭代速度。

因此，我重申了自己的論點(diǎn)，過度設(shè)計(jì)將扼殺產(chǎn)品。遠(yuǎn)不止缺乏良好的工程實(shí)踐。之所以如此，這是因?yàn)橐獜牧己玫膶?shí)踐中獲益，你需要有產(chǎn)品與市場的契合度，而過度設(shè)計(jì)會(huì)使你首先無法得到它。

過度設(shè)計(jì)的例子

第一個(gè)想到的是基于微服務(wù)的架構(gòu)。在幾年前，它們像浪潮一樣涌來，它們應(yīng)該比它們所集成的項(xiàng)目還要多。

我把它們作為過度設(shè)計(jì)的一個(gè)例子，因?yàn)樗鼈冊?99% 的情況下都是沒有必要的，特別是對于那些必須找到市場契合點(diǎn)的初創(chuàng)公司來說，更直接地使用諸如“雄偉的”單體架構(gòu)模式會(huì)帶來很多好處。

假如你成功地找到了市場契合點(diǎn)，結(jié)果發(fā)現(xiàn)，由于規(guī)模問題，你最終需要切換到微服務(wù)，哦，天吶，這是個(gè)好問題。

過早的優(yōu)化往往是另一個(gè)過度設(shè)計(jì)的典型例子。一個(gè)常見的情況是，當(dāng)你還沒有用戶時(shí)，就準(zhǔn)備在一個(gè)過于復(fù)雜的基礎(chǔ)設(shè)施設(shè)置中吸收大量流量的系統(tǒng)。多數(shù)情況下，你只需要在單一服務(wù)器上運(yùn)行單體應(yīng)用，就可以驗(yàn)證你的業(yè)務(wù)模式。

過早優(yōu)化的一個(gè)最糟糕的例子就是，我們花費(fèi)了大量的時(shí)間來設(shè)計(jì)一個(gè)系統(tǒng)，以避免將來重復(fù)自己的工作，而放棄已完成的部分工作。

如果你以前因?yàn)槠飘a(chǎn)而從來沒有看到過它的工作，那么你的設(shè)計(jì)或?qū)崿F(xiàn)有多么完美，都無關(guān)緊要了。即使是這個(gè)星球上最糟糕的代碼，幫助你驗(yàn)證一個(gè)假設(shè)，總好過因?yàn)楹ε虏恢貜?fù)自己的工作而停滯不前。

和上面提到的一樣，軟件重寫是一個(gè)明顯的過度設(shè)計(jì)的例子。通常情況下，工程師并不喜歡在遺留的代碼庫上工作。他們的自然傾向是一切從頭做開始。但是，就像 20 多年前 Joel Spolski 在《你永遠(yuǎn)不應(yīng)該做的事》(Things you should never do) 中寫道，重寫很少能達(dá)到目的，甚至?xí)Z走你的生意。

顯然，這是顯而易見的，但是你的客戶并不關(guān)心你的系統(tǒng)在內(nèi)部有多好。你的客戶關(guān)心的是，你是否幫助他解決了問題。沒有給予他們價(jià)值而投入的每一分鐘都是浪費(fèi)的一分鐘。

如何避免過度設(shè)計(jì)

在我看來，避免過度設(shè)計(jì)的最好方法是讓你的工程師成為真正的產(chǎn)品工程師。

為了實(shí)現(xiàn)這一目標(biāo)，我們可以讓他們參與日常業(yè)務(wù)，在每項(xiàng)舉措之后解釋為什么，并將其與對組織及其愿景重要的指標(biāo)聯(lián)系起來。

觀看 MTP 小組討論，以進(jìn)一步了解定義重要指標(biāo)的重要性。

我們需要讓他們和用戶更緊密地聯(lián)系在一起，邀請他們與我們的用戶進(jìn)行訪談和發(fā)現(xiàn)會(huì)議。你希望你的團(tuán)隊(duì)能夠與你的用戶的問題產(chǎn)生緊密的共鳴，從而使他們能夠迅速地放棄那些不能最有效解決問題的工程措施。

假如你只是把工程團(tuán)隊(duì)看作是一個(gè)生產(chǎn)鏈資源，它唯一的任務(wù)就是從積壓的工作中實(shí)現(xiàn)用戶描述，那么就不要指望他們能有動(dòng)力避免復(fù)雜性。他們需要了解每一個(gè)決策背后的原因。

與此相關(guān)，正確定義問題來減少模糊性。工程師需要知道原因，但是他們也需要知道預(yù)期的是什么。你越能縮小問題的范圍，他們保護(hù)自己不受過度設(shè)計(jì)解決方案影響的理由就越少。定義一個(gè)系統(tǒng)的期望的好方法是通過使用 SLI 和 SLO 的服務(wù)目標(biāo)。

在任何公司里，工程師都是最有創(chuàng)造性的人。當(dāng)你的團(tuán)隊(duì)相信你的標(biāo)準(zhǔn)時(shí)，他們的日常想法或主動(dòng)性就會(huì)顯現(xiàn)出來，這可能表明他們是在考慮將來的“假設(shè)”場景。如果你有這樣的直覺，問問自己：這對解決當(dāng)前用戶的問題有什么幫助？要是我們現(xiàn)在不干呢？他們的回答會(huì)幫助你辨別這是否是一種過度設(shè)計(jì)的情況。

最后，更多的是面向創(chuàng)始人，優(yōu)先聘用已經(jīng)在產(chǎn)品公司有一定經(jīng)驗(yàn)的高級(jí)工程師。尋找“戰(zhàn)爭創(chuàng)傷”的面試。詢問他們最痛苦的經(jīng)歷以及他們是如何應(yīng)對的。堅(jiān)持聘用那些把用戶和簡單性放在簡單的技術(shù)解決方案之前的人。

避免過度設(shè)計(jì)的心智模式

YAGNI

在業(yè)界中，過度設(shè)計(jì)的問題很普遍，工程師們自己就用了一個(gè)術(shù)語來指代添加代碼“以防萬一”的情況：YAGNI，就是“你不會(huì)需要它”（You are not going to need it）的首字母縮寫。

YAGNI 試圖阻止你添加任何在解決你所面臨的問題上并非絕對必要的內(nèi)容，因?yàn)槭聦?shí)是，最有可能的是，“你不會(huì)需要它”。

KISS

KISS 一詞，也就是“保持簡單直白”（Keep it simple stupid）的首字母縮寫，是指更加易于對簡單系統(tǒng)進(jìn)行修復(fù)、開發(fā)和維護(hù)。所以，簡單性應(yīng)該成為任何設(shè)計(jì)的目標(biāo)之一，避免任何不必要的復(fù)雜性。

更糟就是更好

“更糟就是更好”，我們要強(qiáng)調(diào)的是，擁有更少的選擇比擁有更多的選擇更可取。之所以這樣，是因?yàn)樗梢院喕覀儺a(chǎn)品的使用，使其在更廣闊的市場范圍內(nèi)具有吸引力。

換句話說，它鼓勵(lì)我們保持產(chǎn)品的最低限度的基本功能，避免增加“脂肪”，以免增加產(chǎn)品的復(fù)雜性。

總 結(jié)

總結(jié)一下，過度設(shè)計(jì)有可能摧毀你的初創(chuàng)公司，它可能：

增加不必要的復(fù)雜性。

增加開發(fā)和維護(hù)成本。

降低你的迭代速度。

使你無法適應(yīng)市場。

遺憾的是，過度設(shè)計(jì)并非例外；它是常態(tài)。出于這個(gè)原因，了解其中所包含的內(nèi)容非常重要，并且努力避免這種情況的發(fā)生，首先要讓你的工程師參與進(jìn)來，解決客戶的實(shí)際問題。

在沒有解決客戶實(shí)際問題的開發(fā)中，我們投入的每一分鐘都是一種浪費(fèi)。不要掉進(jìn)““以防萬一”的陷阱。

墓地里充斥了設(shè)計(jì)精巧的初創(chuàng)公司和產(chǎn)品，可以擴(kuò)展到數(shù)以百萬計(jì)的用戶，而這些用戶從來沒有得到過一丁點(diǎn)兒的關(guān)注。別成為他們中的一員。

作者介紹：

Simón Mu oz，一位西班牙富有激情的產(chǎn)品經(jīng)理，擁有創(chuàng)業(yè)背景和軟件工程教育背景，并曾在多家技術(shù)公司工作 20 多年，積累了豐富的管理經(jīng)驗(yàn)?，F(xiàn)在在 VoiceMod 工作，開始執(zhí)行一項(xiàng)為每個(gè)人提供 Sonic 身份的任務(wù)。

https://www.mindtheproduct.com/overengineering-can-kill-your-product/

關(guān)鍵詞： 過度設(shè)計(jì)會(huì)扼殺你的產(chǎn)品 產(chǎn)品經(jīng)理