工程師的 Ego #2：完美架構的代價
「這個 MVP 我覺得不太行，我們應該先把後端架構完整抽象化，再開始寫前端。」
「資料庫 schema 現在先定太早，以後很難改。」
「我想這次試著用 event-driven + microservices，看起來比較有彈性。」
這些話，乍聽之下都合理，甚至很「專業」。但幾個月後，創辦人還在 pitch；PM 還在說「快好了」；而第一批客戶早已流失，因為東西還沒交。
我稱這個現象為：完美架構的陷阱（The Architecture Trap）。它是工程師 ego 的一種高級型態——帶著知識與美學包裝的延遲藉口。
MVP？還是 Enterprise Framework？
新創公司面對最大的風險不是「技術不夠好」，而是「市場不需要」。
MVP（最小可行產品）存在的意義是快速驗證需求、迭代學習。但在許多團隊中，我看到的 MVP 是這樣的：
- 使用 Kubernetes 部署的第一版後台管理系統
- 架設 PostgreSQL + Redis + Kafka + RabbitMQ + Elasticsearch 的微服務
- 前端框架從 React 換到 Vue 又換到 Svelte，因為「想找最順手的」
問題是：
客戶只要能登入看報告。
你卻給了他一套未來可擴充、可 scale 到百萬使用者的「完美架構」。
為什麼會這樣？
因為 ego 喜歡寫「可以被留下來」的東西，討厭「以後要重寫」的感覺。
工程師不是不想快，只是他們太不想之後被笑「當初怎麼會寫成這樣」。
但這正是創業與大公司工程文化的最大分野：
認知差異傳統工程文化新創產品導向文化追求目標永續性、可維護性、技術優雅快速驗證、用戶回饋、營收迭代觀念想一次到位，避免重工假設 → 測試 → 學習 → 調整組織支援有 QA、架構師、技術負責人一人多工，交付優先
當工程師還停留在「這是我作品集的一部分」的心態時，很容易在不知不覺中走進完美架構的迷宮。
真實案例：一間消失的新創
我曾協助一間做 B2B 平台的新創，他們團隊有兩位資深工程師，背景極強，開發前期做了極多 code scaffolding、設計 pattern、分層架構與 CI/CD pipeline 的事。
三個月過去，後台登入功能還在「調整 user auth module 的解耦層」。創辦人急了，我介入詢問，他們回答：
「這套架構只要定好，以後就能快速開發所有功能。」
我說：「但如果你們這三個月沒 onboard 半個客戶，以後根本沒有功能要開發。」
最終，這間公司在 MVP 還沒驗證前資金耗盡。當初的 repo 被視為藝術品，但投資人沒有買單。
如何避免完美架構陷阱？
- 定義「完美」的標準不是技術，而是「能交付」
- 技術不是目的，是工具。
- 引導團隊共識：架構是服務產品，而非產品本身
- 架構不是用來自我實現，而是幫你未來少痛苦。
- 告訴團隊：「先活下來，再重構」才是創業鐵律
- 成功的新創架構都是「先亂做活著，後來才優化」出來的。
結語：寫得出可擴充的架構，不代表能寫出成功的產品
我們都想讓世界知道自己的技術有多厲害。但在創業這個環境裡，真正厲害的，是那種明知道可以寫得更漂亮，但選擇先寫得能上線的人。
工程師的 ego 可以讓產品「漂亮得像沒人用過」；也可以讓團隊「一開始就動起來」。
下一篇，我會談談我常用來說服工程師團隊接受 MVP 做法的技巧與話術，還有怎麼把工程 pride 轉化為產品成果的一部分。
