Chi phí cơ hội của thời gian kỹ sư: tự làm hay mua sẵn

Quyết định tự xây hay mua sẵn thường được tranh luận bằng một phép so sánh sai ngay từ đầu: một bên là hoá đơn dịch vụ hằng tháng, bên kia là con số không, vì tự viết thì "chỉ tốn thời gian của đội". Thời gian đó chính là khoản đắt nhất trong bảng. Nó chỉ không xuất hiện ở đâu cả vì không ai gửi hoá đơn cho nó.

Bài này thử làm một việc đơn giản: đặt giá cho thời gian ấy, dựng một mô hình năm năm với giả định ghi rõ ràng, rồi xem con số nói gì. Mô hình nào cũng sai ở đâu đó, nhưng một mô hình sai mà nhìn thấy được vẫn hơn một trực giác sai mà không kiểm được.

Trước hết, một giờ kỹ sư giá bao nhiêu

Không phải lương chia cho số giờ. Chi phí thật của một giờ kỹ sư gồm lương, bảo hiểm, thiết bị, chỗ ngồi, phần mềm, tuyển dụng, quản lý — và quan trọng nhất, thời gian không sinh ra mã: họp, phỏng vấn, nghỉ phép, đọc tài liệu, chờ review. Quy đổi thông thường là 1,5 đến 2 lần lương gộp, chia cho số giờ thật sự làm việc chứ không phải số giờ có mặt.

Con số cụ thể tuỳ nơi, và tôi sẽ không đoán thay bạn. Từ đây trở đi mọi thứ tính bằng giờ kỹ sư. Bạn tự nhân với đơn giá của mình ở bước cuối.

Một mô hình năm năm

Giả sử có một hệ thống mà ước lượng ban đầu là "hai tuần là xong" — 80 giờ. Đặt cạnh nó một dịch vụ mua sẵn làm cùng việc. Đây là các giả định:

Con số 360 giờ không phải bịa ra để dìm phương án tự làm; phần sau sẽ tách nó ra từng khoản. Còn 72 giờ bảo trì mỗi năm là 20% công sức ban đầu — mức thường gặp với phần mềm nội bộ còn sống.

Điểm hoà vốn, và nó nhạy tới đâu

Khoảng cách giữa hai đường là 496 giờ trong 60 tháng, tức khoảng 8 giờ kỹ sư mỗi tháng. Đó là mức giá thuê hoà vốn: dịch vụ nào rẻ hơn 8 giờ kỹ sư một tháng thì mua rẻ hơn tự làm, dưới đúng bộ giả định trên.

Với phần lớn công cụ hạ tầng phổ biến, 8 giờ kỹ sư mỗi tháng là một khoản rộng rãi. Đó là lý do vì sao trực giác "tự viết cho rẻ" sai thường xuyên đến thế.

Nhưng mô hình chỉ đáng tin khi biết nó gãy ở đâu. Thử đổi từng giả định:

Dòng cuối đáng chú ý nhất. Mô hình trên giả định giá thuê cố định. Rất nhiều dịch vụ tính theo lượng dùng, và cái giá bạn ký ở năm đầu không phải cái giá bạn trả ở năm thứ tư.

Vì sao "hai tuần" lại thành 360 giờ

Ước lượng "hai tuần là xong" hầu như luôn đúng cho bản chạy được: thứ demo được, đi đúng luồng thuận, dữ liệu sạch. Nó không sai — nó trả lời một câu hỏi khác với câu bạn đang hỏi.

Phần chênh lệch nằm ở những thứ không ai nhắc trong cuộc họp ước lượng: dữ liệu bẩn, người dùng bấm nút hai lần, kẻ xấu thử lạm dụng, phân quyền, nhật ký đủ để tìm ra chuyện gì đã xảy ra lúc ba giờ sáng, và tài liệu để người thứ hai dám động vào. Không phần nào trong đó thú vị, và cũng chính vì thế mà không phần nào được đưa vào ước lượng.

Cách sửa thô nhưng dùng được: nhân ước lượng ban đầu với ba. Không phải vì kỹ sư kém ước lượng, mà vì câu hỏi được hiểu nhầm một cách có hệ thống.

Bốn khoản mô hình trên chưa tính

Chi phí chờ. Chín tháng tự xây là chín tháng tính năng kia chưa ra mắt. Nếu thứ bạn đang xây chắn đường một nguồn doanh thu, chi phí thật không phải 360 giờ mà là 360 giờ cộng chín tháng doanh thu bị lùi lại.

Chi phí phối hợp. Mã tự viết cần review, cần người trực, cần có mặt trong cuộc họp kiến trúc, cần ai đó nhớ nó tồn tại khi nâng cấp thư viện. Chi phí này tăng theo số người trong đội chứ không theo số dòng mã.

Bề mặt bảo mật và tuân thủ. Hệ thống xác thực tự viết là một hệ thống xác thực bạn phải tự vá. Nếu công việc có dính tới tiêu chuẩn nào đó, bạn cũng tự chứng minh luôn.

Chi phí rút lui. Khoản này đứng ở cả hai phía và hay bị quên nhất. Rời một dịch vụ mua sẵn tốn bao nhiêu? Bỏ hệ thống tự viết đã cắm rễ vào mười chỗ khác tốn bao nhiêu? Câu hỏi này quan trọng đến mức nó xứng đáng thành một trục riêng.

Khung quyết định: hai trục, không phải một

Lời khuyên quen thuộc là hỏi "thứ này có phải điều khiến khách hàng chọn chúng ta không". Câu hỏi đó tốt, nhưng chỉ là một nửa. Nửa còn lại: nếu ba năm nữa quyết định này sai, gỡ ra tốn bao nhiêu?

Ô nguy hiểm nhất là góc trên bên phải: những thứ không tạo khác biệt nhưng lại khoá bạn rất chặt. Thanh toán, xác thực, kho dữ liệu. Rất dễ tặc lưỡi mua vì "có phải lõi đâu", rồi ba năm sau phát hiện nửa hệ thống nói tiếng của nhà cung cấp đó và không gỡ ra nổi. Ở ô này, mua vẫn thường đúng — nhưng phải đặt một lớp giao diện của mình ở giữa ngay từ đầu, lúc còn rẻ.

Khi "mua sẵn" là quyết định sai

Bốn kiểu thất bại hay gặp, xếp theo mức độ thường xuyên:

• Giá đổi khi bạn đã cắm rễ. Bạn không thương lượng ở vị thế của người có thể bỏ đi.
• Quy mô lật ngược phép tính. Mô hình giá của dịch vụ được thiết kế cho người dùng cỡ trung bình. Vượt xa mức đó thì bạn đang trả tiền cho một sự tiện lợi mà mình không còn cần.
• Nhà cung cấp đổi hướng hoặc biến mất. Sản phẩm bị mua lại, bị khai tử, hoặc xoay sang tập khách hàng khác.
• Cái bạn cần lệch dần khỏi cái họ bán. Rồi bạn viết mã để lách sản phẩm — và tự làm mất cái lợi ban đầu.

Khi tự làm đúng, dù không phải lõi

Hai ví dụ công khai, đều ở quy mô mà phép tính đảo chiều.

Dropbox chuyển phần lớn dữ liệu người dùng khỏi Amazon S3 về hạ tầng tự dựng trong hai năm 2015–2016. Hồ sơ IPO của họ công bố khoản tiết kiệm khoảng 75 triệu đô la trong hai năm sau đó. Lưu trữ không phải thứ khách hàng chọn Dropbox vì nó — nhưng ở quy mô đó, chênh lệch vài phần trăm trên mỗi terabyte thành một con số lớn hơn cả chi phí xây đội.

37signals rời điện toán đám mây trong hai năm 2022–2023 và công bố mức tiết kiệm khoảng hai triệu đô la mỗi năm. Họ cũng nói rõ điều kiện: tải khá ổn định, đội vận hành nhỏ nhưng giỏi, và không cần co giãn đột ngột.

Điểm chung không phải "tự làm rẻ hơn". Điểm chung là cả hai đều đã chạy phương án mua sẵn đủ lâu để biết chính xác mình cần gì, rồi mới xây. Đó là thứ tự đúng, và nó ngược với cách phần lớn quyết định tự xây được đưa ra — tức là xây trước, hiểu sau.

Lối thứ ba mà câu hỏi nhị phân bỏ sót

• Tự vận hành mã nguồn mở. Không phải mua, cũng không phải viết. Được kiểm soát và không bị khoá, đổi lại phải tự lo vận hành. Thường là ô trống mà cuộc tranh luận "mua hay làm" quên mất.
• Mua rồi bọc lại. Dùng dịch vụ, nhưng chỉ gọi nó qua một lớp giao diện của mình. Tốn thêm vài ngày lúc đầu, và biến "chi phí rút lui" từ một dự án thành một tuần làm việc.
• Mua trước, làm sau. Dùng hàng có sẵn cho tới khi hiểu rõ nhu cầu thật, rồi mới quyết định có xây không. Đây chính là điều Dropbox và 37signals đã làm.
• Xây một lớp mỏng trên nền mua sẵn. Phần tạo khác biệt là của bạn, phần nhàm chán để người khác lo.

Quy mô đội đổi phép tính

Với một người làm một mình, chi phí cơ hội gần như là tất cả: mọi giờ dành cho hệ thống phụ là giờ không dành cho sản phẩm, và không có ai khác gánh phần bảo trì. Ngưỡng nên mua thấp hơn nhiều so với cảm giác.

Với đội vài chục người, chi phí phối hợp và rủi ro người rời đi nổi lên: hệ thống tự viết mà chỉ một người hiểu là một khoản nợ có ngày đáo hạn.

Với tổ chức lớn, quy mô bắt đầu lật ngược mọi thứ — và cũng chỉ ở mức đó thì việc lập hẳn một đội để nuôi hệ thống nội bộ mới có nghĩa.

Biến nó thành quyết định xem lại được

Phần lớn quyết định mua-hay-làm được đưa ra một lần rồi không ai nhìn lại, trong khi mọi giả định của nó đều sẽ đổi. Ba việc rẻ tiền giúp sửa chuyện đó:

• Ghi lại giả định lúc quyết định — ước lượng bao nhiêu giờ, giá thuê bao nhiêu, dự kiến sống mấy năm. Một đoạn văn là đủ.
• Đo giờ bảo trì thật. Nếu không đo, bạn sẽ không bao giờ biết con số 20% kia đúng hay sai với mình.
• Đặt lịch xem lại sau 12 tháng. Không phải để đổi, mà để so giả định với thực tế — đó là cách duy nhất để lần ước lượng sau khá hơn lần này.

Tóm lại

Tự viết không miễn phí, nó chỉ không có hoá đơn. Khi quy ra giờ kỹ sư và kéo dài qua năm năm, mức giá thuê hoà vốn thường cao hơn nhiều so với trực giác — trong mô hình ở trên là khoảng 8 giờ kỹ sư mỗi tháng.

Nhưng con số ấy không quan trọng bằng thói quen tạo ra nó. Đặt giá cho thời gian, ghi rõ giả định, thêm trục chi phí rút lui bên cạnh trục khác biệt, và hẹn ngày xem lại. Quyết định vẫn có thể sai — nhưng nó sẽ sai theo cách bạn phát hiện được, thay vì âm thầm đắt lên suốt năm năm.