過早擴張、未經檢驗的技術，創業公司最易跳入哪些致命陷阱？
對早期的軟體初創公司，請注意避免這些工程錯誤。
2016 年，我為一個初次創業者提供了技術諮詢，幫助他建立一個種子基金資助的食品配送市場。在我看來，他這家公司做出的每一項技術選擇都是錯誤的。
CEO 信奉“將權利賦予工程師”的理念，然後讓他們的第一個工程師進行框架（Scala/Play）選擇，僅僅因為這個架構是工程師要使用的，而不是因為這個架構能對公司、對實用案例或對人才招募有幫助，他們許多早期的技術工作都是外包的。他們的產品路線圖看起來非常樂觀（同時發展網路端和移動端），儘管大多數業務仍然未經驗證，而這就是災難的根源。
創業工程不同於任何其他型別的軟體工程。相對於構建系統的“正確方式”，它需要短期和中期的生產力。它重視那些能夠快速迭代並熟悉黑客程式碼的人。它在技術選擇上注重實用主義，而不是選擇最熱門的或最穩定的技術。
如果你的初創公司尚未找到適合市場的產品，本文有四個常見的工程陷阱需要注意避免。
過早擴張
最常見的創業工程錯誤是過早擴張。
過早擴張意味著當你的公司還很小的時候，就進行大規模地擴張。希望過早地擴張能立即獲得長久的生產效率提高，但事實上從未實現過，也從未獲益過。
初創公司普遍存在過早擴張的問題。在 2010 年代初，人們之所以避開 SQL 資料庫，部分原因是由於人們認為 MongoDB 和 Cassandra 這樣的 NoSQL 資料庫具有無限的可擴充套件性。在微服務的刺激下，單一的創業生產力優勢消失殆盡。多年來，人們一直認為 Ralis 不適合初創公司，因為它比其他框架都要慢得多。
過早擴張會浪費工程資源。在達到產品市場需求之前就進行擴張，對於那些無論資金還是工程師都很匱乏、但功能要求很高且需要不斷迭代的早期初創公司來說不啻為一場毀滅性的打擊。
既然說過早擴張是初創公司的頭號殺手，為什麼還會經常出現過早擴張呢？
首先，擴張真的很有趣。Twitter 的初始版本是一個簡單的單一 CRUD 應用，現在任何一個集訓工程師都可以構建出來。僅僅過了幾年，Twitter 就出現了一系列有趣的問題：需要查詢大量資料，停機成本很高，使用量激增，使用者群龐大。為滿足這些需求，Twitter 引入了規模化的技術，使這項工作對那些加入的員工來說更加令人興奮、更具有吸引力。這種興奮使早期擴張成了工程團隊容易陷入的陷阱。
其次，建立績效體系似乎是合理的需求。一些工程師對黑客系統感到震驚，彷彿它們就是一種道德淪喪的象徵。對於那些為大型科技公司工作的創業工程師來說尤其是個問題，這種可能不太優雅的解決方案令人厭惡，因為在這些公司裡，所有事情都必須規模化完成。“不做規模化的事”是 Y Combinator 公司的一條常見建議，它在工程中的應用，和在業務流程中的應用一樣多。
技術債務導致早期初創公司的夭折比你想象的要少。如果你成功了，你通常會有足夠的資金來彌補你犯下的所有工程錯誤和你採取的捷徑。
再次，工程路線圖和工具是圍繞對未來過於樂觀的觀點而構建的。創業領導者對他們的企業如何發展充滿了理想主義，讓我們面對現實，否則他們是不會創辦這些公司的。即使你到達了產品市場的關鍵里程牌，當工程決策需要重新評估時，危險在於——你高估了你需要的規模水平。
試圖在未來需求出現之前就預測它們，會使你的直接目標，也就是開發人們需要的產品，失去寶貴的資源。
使用未經檢驗的技術
當初創公司過於依賴高大上的或新的技術時，往往會傷害到自己。
高大上的技術是軟體工程師們夢寐以求的技術。高大上的技術通常會讓工程師的生活更加輕鬆愉快，特別是在極短的時間內。但是，依靠最新的技術，往往沒有考慮到在中期內對廣泛的團隊來說最有成效的事情。
比如說，與使用關係型資料庫 SQL 相比，MongoDB 的類似 JavaScript 的 DSL 和 JSON 資料儲存使編寫程式碼對於 JavaScript 開發人員來說更容易。但是，易用性不應該是選擇資料庫的主要指標。
在一次採訪中，有一名軟體工程師告訴我，他永遠不會在一家不使用 CoffeeScript 的公司工作（放在今天，這場辯論應該是關於 Elixir）。如果正確的解決方案與他的偏好不符，他甚至會拒絕考慮其他工具，如此一來，就可能會出現問題。
新技術也有它自身的問題。人們對新工具的故障狀態知之甚少，因此很難預測事情會如何惡化。而新的語言 / 框架，它們沒有庫，也沒有很多可以用它們來編寫程式碼的工程師。這種資源的缺乏增加了開發工作量，並使招聘工作面臨著挑戰。它還意味著，當你專注於創造使用者看重的功能時，卻要把你的初創公司所稀缺的工程資源投入到學習新東西上。
部分問題在於工程師，尤其是非創始人，想要實施的技術，能夠讓他們在市場上顯得舉足輕重。這應該會讓初創公司感到擔憂。在前端工程這樣的領域中，讓工程師追逐當前的炒作週期就可能意味著每過 6~12 個月就要重寫一次堆疊。
開發人員在其職業生涯的早期，特別容易使用新的、高大上的技術，而不是對手頭專案最有意義的工具。他們沒有經歷過幾次炒作週期，也沒有看到所選最新技術的缺點。當他們閱讀黑客新聞或參加黑客馬拉松 / 會議時，可能會錯過他們看到的所有營銷活動。
更槽糕的是，這些開發人員並沒有意識到，僅僅是因為某項技術被大肆炒作，但實際上並不適合在創業工程的環境中使用。在沒有評估這些選擇的適當性的情況下，採用知名創業公司或大公司的技術堆疊並移植其堆疊是一種很常見的做法。當團隊規模還很小時，開發人員並不總是能夠得到經驗豐富的工程師的指導，從而抵消外界媒體對他們施加的影響。
初創公司的開發人員往往喜歡引用 Paul Graham 著名的文章：《The Python Paradox》，作者在這篇文章中提到，與 Java 相比，Python 提高了初創公司的生產力。Graham 那篇文章經常被用來證明實施每一個最新的框架和語言的合理性。然而，Graham 的真正觀點是，軟體工程師應該選擇能夠最大限度提高初創公司生產力的工具，而不是條件反射式地偏愛最新的技術。事實上，在 2013 年看到 Y Combinator 公司的創業團隊後，Graham 被問及理想的語言是什麼。他指出，“我的意思是，我們有一些初創公司在使用 PHP 來編寫程式碼，這讓我有點擔心，但不像其他事情那麼讓我擔心。”
作為一名工程師，加入一家初創公司對你來說就是冒著巨大的風險。你不應該增加炒作的風險，但也不應該新增不必要的技術。
僱傭錯誤的工程師
很多創業工程問題源於僱傭了錯誤的工程師。
初創公司經常尋找“搖滾明星”或“忍者”。他們想要華而不實的學歷證書，以及來自成功公司的“精靈之塵”。在矽谷，初創公司的招聘職位傾向於那些使用新的、高大上的技術的候選人，而不是青睞能夠快速學習必要工具的務實工程師。一旦一家公司從僱傭“搖滾明星”和“忍者”開始，那麼它就為以後的每一次招聘定下了基調。
很少有人教授創業工程。大量的軟體工程師為非初創公司工作。因此，大多數加入初創公司的工程師都沒有接受過創業工程方面的培訓，也沒有在創業環境中獲得成功的技能或態度。因此，初創公司往往必須依賴於那些並不完全適合該專案的工程師。
這些工程師都有自己的創業風險：
-
大型公司的工程師經常接觸到規模龐大的系統，可能對黑客程式碼感到不舒服。他們不太可能接觸到使用者。
-
優秀的電腦科學家 對管道式工程感到厭倦，而這種工程代表了早期創業任務，導致工程過度設計。
-
年輕的工程師往往被初創公司吸引，他們可能會注入太多的新技術，而且他們設計的系統架構設往往很差。
-
開發部門往往傾向於那些能夠讓他們在許多客戶中保持高效的技術。他們沒有為特定客戶學習新工具的動力，也沒有長期參與到早期關鍵技術決策的遊戲中。
相比之下，理想的早期創業工程師應該對公司的使命感到興奮。這確保當公司在產品市場適應的過程中不可避免地遇到挑戰時，他們會留下來。
他們有一個最低可行的產品理念和不斷迭代的舒適感。最好的創業工程師通常有幾年的工作經驗或開源專案經驗，這樣他們就可以學會如何維護系統，而不僅僅是構建系統。
他們不會把特定技術視為靈丹妙藥，而是青睞於滿足組織中期需求的生產工具。偉大的早期創業工程師將技術視為解決問題的一種手段。他們考慮的是問題空間（使用者的需求）以及如何使用軟體來解決問題，而不是去尋找新技術可以解決的問題。
他們需要有一種積極的態度。在面對巨大挑戰的同時，也在緩和（但不是否定）產品所有者的樂觀態度。這些工程師需要對使用者有同理心和直覺，因為他們在迭代時經常扮演產品的角色。
有一個注意事項需要說明的是，即使在創業工程師中，在創業的每個階段獲得的經驗也是截然不同的。一名能夠勝任五個工程師的創業工程師，在他 25 歲的時候表現可能會很槽糕。對於招聘人才的初創公司來說，看到一名成功初創公司中的工程師往往掩蓋了那個人在那裡真正做的事情的細微差別。
初創公司應該著眼於品牌之外的東西，並根據當前專案的需求進行按需招聘。
產品和管理方面的問題
很多初創公司的錯誤都源於產品和管理，而不是工程。
初創公司的創始人非常樂觀。產品路線圖往往會超出他們小團隊的能力。這種樂觀情緒導致了過多的招聘和籌資，最終讓整個公司感到精疲力竭。對於管理層來而言，這個週期開始的時候看起來像“工程師沒有盡職”，實際上這意味著管理層沒有建立一個清晰而聚焦的願景。
儘管商業模式存在不確定性，但創始人始終如一的創業心態也讓工程團隊對如何構建系統產生了錯誤的確定感。更好的心態是支援樂觀的工程師，並培養在內部感到悲觀的商業領袖，雙方共同努力尋找產品與市場的契合點。
新初創公司的另一個問題是，管理層經常在其他成功的初創公司找工程顧問來指導他們的新初創公司。然而，從可能不相關的公司或領域引進的所謂的“專家”會帶來一些問題，因為這些顧問僅僅花了短短几個小時就試圖瞭解這家初創公司，並就把自己過往的經驗移植進去。
最後，管理層需要認識到，工程師是任何重大產品決策的關鍵組成部分。很多時候，公司的工程師經常被視為一個服務組織，當出現重要的商業決策時，這個服務組織被要求強制執行（確保產品和工程之間的良好關係是僱傭合適的工程師的另一個重要原因）。
不要棒打你的初創公司
即使你成功避免了這些創業工程的陷阱，但你仍然會面臨很多挑戰。但是，通過避開這些陷阱，你就不會那麼擔心自己造成的傷害了。
TGO 鯤鵬會 ，是極客邦科技旗下高階技術人聚集和交流的組織，旨在組建全球最具影響力的科技領導者社交網路，線上線下相結合，為會員提供專享服務。目前，TGO 鯤鵬會已在北京、上海、杭州、廣州、深圳、成都、矽谷、臺灣、南京、廈門十個城市設立分會，武漢、蘇州分會即將成立。現在全球擁有在冊會員 800+ 名，60% 為 CTO、技術 VP、技術合夥人。
會員覆蓋了 BATJ 等網際網路巨頭公司技術領導者，同時，阿里巴巴王堅博士、同程藝龍技術委員會主任張海龍、蘇寧易購 IT 總部執行副總裁喬新亮已經受邀，成為 TGO 鯤鵬會榮譽導師。
如果你想和這些優秀的科技領導者們一起前行，歡迎點選「報名表單，申請加入」 。