Bạn đưa ra các quyết định build-vs-buy ở quy mô tổ chức như thế nào?

Question

Accepted Answer

Nguyên tắc cốt lõi rất đơn giản: **xây những gì tạo ra sự khác biệt cho bạn, mua mọi thứ còn lại.** Ở quy mô tổ chức, quyết định ít liên quan đến một công cụ đơn lẻ mà liên quan nhiều hơn đến việc bạn chọn dồn năng lực kỹ thuật khan hiếm của mình vào đâu.

## Một khung quyết định

```text
BUILD khi:
- Nó là cốt lõi cho lợi thế cạnh tranh của bạn
- Không có giải pháp nào đủ tốt, hoặc giải pháp của bạn phải vượt trội đáng kể
- Năng lực này phải liên tục tiến hóa cùng sản phẩm của bạn

BUY khi:
- Nó là một thứ phổ thông (auth, payments, email, observability)
- Đã có giải pháp của vendor trưởng thành và đủ phù hợp
- Time-to-market quan trọng hơn quyền kiểm soát
```

Cân nhắc **tổng chi phí sở hữu (total cost of ownership)**, không chỉ giá license: tích hợp, bảo trì, tuyển dụng, và chi phí cơ hội của những kỹ sư không làm việc trên sản phẩm của bạn.

## Ví dụ cụ thể

Một công ty xây dựng recommendation engine của riêng mình (trái tim của sản phẩm) nhưng mua CRM, xử lý thanh toán, và logging stack. Tự xây những thứ đó sẽ đốt cháy kỹ sư vào công việc không tạo ra sự khác biệt.

## Đánh đổi và cạm bẫy

- **Cạm bẫy:** hội chứng "not invented here", tự xây lại những thứ phổ thông vì cái tôi hoặc vì vui.
- **Cạm bẫy:** mua cho một năng lực cốt lõi rồi không thể tạo ra sự khác biệt.
- Mua tạo ra sự phụ thuộc vào vendor; xây tạo ra nợ bảo trì. Hãy chọn món nợ của mình một cách có chủ đích.

## Tại sao điều này quan trọng

Năng lực kỹ thuật là nguồn lực khan hiếm nhất ở hầu hết các công ty.

Dồn nó vào những thứ phổ thông thay vì những thứ tạo khác biệt là cách phổ biến nhất khiến các đội giỏi bị tụt lại phía sau.

Build-vs-buy có kỷ luật là cách một CTO định hướng năng lực đó về phía những gì thực sự giúp giành chiến thắng.