殺死初創科技公司的四大工程陷阱

作者 | Nemil Dalal

譯者 | 無明

2016 年，我為一位首次創業的企業家提供技術建議。在我看來，這家公司做出的每一項技術決策都是錯誤的。

公司的 CEO 認為應該給工程師「放權」。他們讓第一個工程師選擇框架（Scala/Play），因為這剛好是這位工程師想要使用的框架，而不是因為它對公司、他們的使用場景或招聘有任何意義。他們很多早期的技術工作都是外包出去的。他們的產品路線圖非常樂觀（Web 和移動同時鋪開），儘管大多數業務仍然未經過驗證。

初創公司的工程與其他類型的軟體工程不同。相比「正規」的構建系統，它們需要的是中短期的生產力。它們更加重視那些能夠進行快速迭代的人，它們更傾向於實用的技術選型，而不是選擇被炒作過度或穩定的技術。

如果你的初創公司還沒有找到可以打入產場的產品，那麼就需要避開以下四個常見的工程陷阱。

過早擴大規模

初創公司最常見的工程錯誤是過早擴大規模。

過早擴大規模是指當公司還很小的時候就構建大規模的系統。過早擴大規模是用眼前的生產力換取未來可能永遠無法兌現的好處。

過早擴大規模這個問題在初創公司中非常常見。在 2010 年代早期，因為 NoSQL 資料庫（如 MongoDB 和 Cassandra）的無限可伸縮性，人們在一定程度上開始避免使用 SQL 資料庫。在微服務的大潮中，初創公司單體系統的生產力優勢消失殆盡。多年來，Rails 一直被認為不適合初創公司，因為它比其他框架慢。

過早擴大規模會浪費工程資源。對於早期的初創公司來說，在產品進入市場之前就進行規模擴張很可能是毀滅性的，因為這些公司並沒有多少錢，也沒有多少工程師，但功能需求巨大，需要不斷進行迭代。

如果說過早擴大規模是創業公司的頭號殺手，那為什麼它會如此頻繁地發生呢？

首先，擴大規模是一件很有趣的事情。Twitter 最初只是一個簡單的單體 CRUD 應用程序，任何一個剛參加完訓練營的工程師都可以搞定它。短短几年，Twitter 就出現了一系列有趣的問題：查詢大量數據、停機成本巨大、資源使用高峰期、用戶群龐大。為解決這些問題而加入可擴展的技術是一件很令人感到興奮的事情，但這種興奮卻是工程團隊在早期容易掉進去的一個陷阱。

其次，構建高性能的系統似乎是非常合理的。一些工程師對「hack」系統感到很震驚，好像在他們看來這是一種道德淪喪。對於那些曾經在大型科技公司工作過的創業公司的工程師來說，這種對可能不優雅的解決方案的厭惡尤其是個大問題。 「做不可擴展的事情」是 Y Combinator 的一條常規信條，它不僅適用於業務流程，也適用於工程領域。

技術債務扼殺初創公司的可能性比你想像的要小得多。如果你成功了，就有足夠的錢來彌補之前犯下的工程錯誤和走過的捷徑。

第三，在建立工程路線圖和工具時，他們對未來充滿了樂觀的情緒。創業公司的領導者對業務的增長太過理想化，否則他們就不會創辦公司了。即使你的產品契合市場——一個需要重新評估工程決策的關鍵里程碑——但你仍然可能會高估必要的規模水平，這是很危險的。

在未來的需求出現之前就對其進行預測，會佔用當前目標（開發人們需要的產品）的寶貴資源。

使用未經測試的技術

當初創公司過分依賴那些閃亮的新技術時，他們會傷害到自己。

閃亮的新技術正是軟體工程師迫切需要的。新技術往往會讓工程師的生活在極短的時間內變得更輕鬆、更愉快。但是，因為過度依賴新技術，往往會錯過在中期內對團隊來說最有成效的東西。

例如，對於 JavaScript 開發人員來說，與使用關係型 SQL 資料庫相比，MongoDB 的 DSL 和 JSON 數據存儲讓編寫代碼變得更容易。但是，易用性不應該是選擇資料庫的主要標準。

在一次面試中，一位軟體工程師告訴我，他不會在一家不使用 CoffeeScript 的公司工作。如果正確的解決方案與他的偏好不一致，他會拒絕考慮使用其他工具，這可是一個大問題。

新技術有其自身的問題。人們對新工具可能會發生的故障知之甚少，因此很難預測會發生怎樣的問題。新的語言或框架沒有太多的可用庫，也沒有太多可以熟練使用它們的工程師。缺乏這些資源會增加開發工作量，並讓招聘工作面臨挑戰。況且，你還需要讓稀缺的工程資源去學習新的東西，而他們本應專註於創建對用戶來說有用的功能。

部分問題在於工程師（尤其是非創始人）總是希望實現那些讓自己看起來與市場與時俱進的技術。這是創業公司最需要擔心的事情。在前端工程等領域，如果工程師要追趕技術炒作周期，可能每 6 到 12 個月就要重寫一次系統。

開發人員在其職業生涯早期傾向於使用閃亮的新技術，而不是那些對手頭的項目來說最有意義的工具。他們沒有經歷過什麼技術炒作周期，也看不到新技術存在的不足。

更糟糕的是，這些開發人員並沒有意識到，被炒作的技術並不一定適合被用在初創公司中。一種很常見的情況是，在還沒有做出適用性評估的情況下，直接生搬硬套知名創業公司或大公司的技術棧。當團隊規模很小時，開發人員並不總能得到經驗豐富的工程師的指導，以抵消外部媒體對他們的「侵襲」。

初創公司的開發人員經常引用 Paul Graham 的「Python 悖論」。這個悖論是說，與 Java 相比，Python 更能提高初創公司的生產力。Graham 的文章通常被用來證明每一個新框架或每一門新語言的實現是否正確。但實際上，Graham 的真正觀點是，軟體工程師應該選擇能夠最大限度提高初創公司生產力的工具，而不是本能地偏好最新的技術。事實上，2013 年在 Y Combinator 與初創團隊見面時，Graham 被問及他心中理想的語言是什麼。他說：「我的意思是，有些初創公司還在使用 PHP，這讓我感到有點擔心，但它並沒有其他事情那麼讓我感到擔心」。

作為一名工程師，加入初創公司實際上已經冒了巨大的風險。你不應該再把採用被過度炒作但不必要的技術的風險也帶進來。

招錯了人

很多初創公司的工程問題源於招錯了工程師。

初創公司通常喜歡找「搖滾明星」或「忍者」這樣的人。他們想要華麗的學歷證書或者從大公司出來的小精靈。在矽谷，初創公司偏愛使用閃亮新技術的候選人，而不是那些能夠快速學會怎麼使用工具的務實工程師。一旦公司以「忍者」和「搖滾明星」作為標準，就為後面招聘的每一位員工奠定了基調。

初創公司的大部分軟體工程師最初都是在非初創公司工作。因此，大多數加入創業公司的工程師都沒有受過創業工程方面的培訓，也不具備在創業環境中取得成功的技能和心智。因此，初創公司往往不得不依賴這些並不完全合適的工程師。

這些工程師存在以下這些風險：

大型公司的工程師經常接觸大規模的系統，並且可能不習慣於「hack」代碼。他們也不太可能會接觸到他們的用戶。

優秀的計算機科學家會對管道式工程感到厭倦，這類工程是初創公司早期階段的典型代表，會導致過度工程化。

被初創公司吸引的初級工程師可能會注入太多的新技術，但卻很難架構好他們的系統。

開發團隊往往傾向於使用能夠讓他們在跨多個客戶時仍然能夠保持高效的技術。這些團隊沒有動力為特定客戶學習新工具，他們也不具備足夠的動力做出關鍵的早期技術決策。

相比之下，理想的初創公司工程師應該對公司的使命保持認同感。這樣可以確保他們在公司不可避免地遇到挑戰時仍然不會離開公司。

他們擁有最小可行性產品的概念，並能夠適應不斷迭代的流程。最優秀的初創公司工程師通常都具備幾年的工作經驗或開源項目經驗，因此他們已經學會了如何維護系統，而不僅僅是開發系統。

他們不把特定的技術看作是靈丹妙藥，而是喜歡選擇那些能夠滿足公司中期需求的生產力工具。偉大的初創公司工程師將技術視為解決問題的手段。他們經常考慮的是問題空間（用戶的需求）以及如何使用軟體來解決這些問題，而不是把關注點放在新技術可以解決那些的問題上。

他們需要有一種「我能行」的態度。他們面臨著巨大的挑戰，同時要緩和產品所有者的樂觀情緒，而不是去反對他們。這些工程師需要具備用戶同理心和直覺，因為他們在產品迭代過程中經常扮演產品人的角色。

需要注意的是，初創公司的工程師在每個階段獲得的經驗也可能完全不同。在一個 5 人初創團隊中表現優異的工程師在 25 人的團隊中可能表現得很糟糕。初創公司在招聘人才時，看到一位從成功的初創公司出來的工程師，但其實表面的光鮮往往會掩蓋這個人之前的實際工作表現。

初創公司應該看透表面的光鮮，最重要的是要根據當前項目的實際需要來招聘人才。

產品和管理方面的問題

有很多初創公司的錯誤源於產品和管理，而不是工程。

初創公司的創始人總是過於樂觀，產品路線圖通常會超出團隊的能力。這種樂觀情緒導致了過多的招聘、過多的融資，最終精疲力盡。在管理層看來，這似乎是因為「工程師表現不佳」，但實際上是因為管理層沒有設定好清晰的願景。

初創公司的另一個問題是，管理層經常會找工程顧問——其他成功初創公司的工程師——來指導自己的公司。當這些顧問把在他們公司學到的東西生搬硬套到一個他們只花了幾個小時去了解的新公司時，相當於從可能不相關的公司或領域引進所謂的「專家」，這可能是個大問題。

最後，管理層需要認識到，工程師是重大產品決策的關鍵組成部分。很多時候，工程師被看作是一個服務組織，當出現重要的商業決策時，他們就會被壓垮。因此，為了確保有一個健康的產品和工程關係，招聘合適的工程師是十分必要的。

不要搬石頭砸自己的腳

即使你避開了這些初創公司的工程陷阱，仍然會面臨其他挑戰。但避開這些陷阱起碼可以讓你不那麼擔心給自己造成傷害。

英文原文

https://hackernoon.com/four-startup-engineering-killers-1fb5c498391d

如果你想跟 InfoQ 的編輯、運營小哥建立聯繫，聊聊學習資料、程序人生、科技資訊、脫單秘訣，可以添加微信 ryantz，備註：InfoQ 來意。期待與更多用戶成為好朋友。

點個在看少個 bug

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！