Mở đầu — vì sao bài này quan trọng
Có một sự thật mà ít người mới làm Technical PM nhận ra: một phần lớn "sản phẩm" mà bạn xây dựng thực ra không do đội của bạn viết ra. Nó là cổng thanh toán bạn tích hợp, là dịch vụ gửi email bạn thuê, là cơ sở dữ liệu được quản lý trên đám mây bạn trả tiền hằng tháng, là công cụ phân tích dữ liệu, là API bản đồ, là nền tảng gửi SMS OTP. Mỗi quyết định "dùng cái nào của ai" là một quyết định kiến trúc dài hạn — và thường khó đảo ngược hơn cả quyết định viết bằng ngôn ngữ nào.
Khi bạn chọn sai vendor (nhà cung cấp), hậu quả không hiện ra ngay. Nó âm ỉ: chi phí phình to khi bạn scale, downtime của họ kéo theo downtime của bạn, một điều khoản trong hợp đồng khiến bạn không thể xuất dữ liệu ra, hay một quyết định ngừng dịch vụ của họ buộc bạn phải làm lại từ đầu trong hoảng loạn. Ngược lại, chọn đúng vendor có thể giúp một startup ba người làm được việc mà bình thường cần cả đội mười người.
Đây chính là lý do "Build vs Buy" (Bài 53) và "Vendor Selection" là hai mặt của cùng một đồng xu. Bài 53 trả lời câu hỏi "có nên mua không". Bài 58 này trả lời câu hỏi tiếp theo — và khó hơn nhiều: "mua thì mua của ai, đánh giá thế nào, ràng buộc ra sao". Là Technical PM, bạn là người chủ trì quá trình đó. Engineer cho bạn góc nhìn kỹ thuật, procurement (mua sắm) lo hợp đồng, legal lo pháp lý — nhưng người ráp tất cả lại thành một quyết định có cơ sở chính là bạn.
Khái niệm cốt lõi
Vendor selection, hiểu đơn giản, là một quy trình có cấu trúc để đi từ "chúng ta cần một thứ gì đó" đến "chúng ta đã ký hợp đồng với nhà cung cấp X một cách có lý do rõ ràng". Nó không phải việc Google vài cái tên rồi chọn cái rẻ nhất hay cái nổi tiếng nhất.
Functional vs Non-functional requirements
Trái tim của vendor selection là tách bạch hai loại yêu cầu.
Functional requirements (yêu cầu chức năng) là "vendor này làm được gì". Ví dụ với một cổng thanh toán: hỗ trợ thẻ nội địa Napas không, có ví MoMo/ZaloPay không, có cho thanh toán định kỳ (recurring) không, có hoàn tiền một phần không.
Non-functional requirements (yêu cầu phi chức năng) là "vendor này làm tốt đến mức nào" — và đây mới là phần phân biệt một Technical PM giỏi với người chỉ đọc bảng tính năng. Bao gồm:
- Latency (độ trễ): API trả về trong bao lâu? Một cổng thanh toán phản hồi trung bình 200ms khác hẳn một cổng phản hồi 2 giây ở giờ cao điểm.
- Uptime / availability (độ sẵn sàng): cam kết bao nhiêu phần trăm? 99.9% nghĩa là được phép sập khoảng 43 phút mỗi tháng; 99.99% chỉ cho phép 4 phút. Sự khác biệt này phải khớp với mức độ quan trọng của tính năng.
- Scale (khả năng mở rộng): họ chịu được bao nhiêu request mỗi giây? Có rate limit cứng nào không? Khi bạn tăng trưởng 10 lần thì sao?
- Data residency (nơi lưu dữ liệu): dữ liệu lưu ở server nào, quốc gia nào — chuyện này rất quan trọng với Nghị định 13 ở Việt Nam (xem Bài 32).
Compliance và Security
Một vendor chạm vào dữ liệu nhạy cảm thì các chứng chỉ tuân thủ không còn là "điểm cộng" mà là điều kiện loại trừ. Cổng thanh toán bắt buộc phải có PCI DSS. Vendor lưu dữ liệu doanh nghiệp lớn thường cần SOC 2 Type II hoặc ISO 27001 (xem Bài 43). Nếu vendor không có chứng chỉ phù hợp, bạn loại ngay từ vòng đầu, bất kể tính năng có hấp dẫn đến đâu — vì rủi ro pháp lý và rủi ro audit của khách hàng bạn không gánh nổi.
Tổng chi phí sở hữu (TCO) và Vendor lock-in
Giá niêm yết chỉ là phần nổi. Bạn phải nhìn Total Cost of Ownership: phí theo lượng dùng (per-API-call, per-GB), phí vượt hạn mức, chi phí kỹ sư để tích hợp và bảo trì, chi phí đào tạo, và đặc biệt là chi phí rời đi.
Vendor lock-in (bị khóa vào nhà cung cấp) là rủi ro lớn nhất và bị xem nhẹ nhất. Nếu dữ liệu của bạn nằm trong một định dạng độc quyền, nếu code của bạn gọi API theo cách không chuẩn hóa, thì một ngày vendor tăng giá gấp ba lần, bạn vẫn phải trả vì rời đi quá đắt. Câu hỏi vàng cần đặt từ đầu: "Nếu sáu tháng nữa muốn bỏ vendor này, chúng ta mất bao lâu và bao nhiêu tiền?"
Sức khỏe của vendor
Cuối cùng, bạn đang cưới chứ không phải hẹn hò một đêm. Vendor này còn tồn tại sau ba năm không? Họ có được rót vốn ổn định không, có cộng đồng và tài liệu tốt không, support phản hồi nhanh không? Một startup vendor giá rẻ nhưng có nguy cơ phá sản là một quả bom hẹn giờ trong kiến trúc của bạn.
Tình huống thực tế
Ví dụ 1 — Chọn cổng thanh toán cho một sàn TMĐT Việt Nam
Một startup thương mại điện tử ở TP.HCM, tạm gọi là ShopViet, cần tích hợp thanh toán. Đội kỹ thuật thích Stripe vì tài liệu đẹp và DX (developer experience) tuyệt vời. Nhưng Technical PM lập một bảng so sánh và phát hiện vấn đề: Stripe lúc đó chưa hỗ trợ chính thức pháp nhân Việt Nam, không kết nối thẳng Napas, MoMo, ZaloPay — những phương thức chiếm hơn 60% lượng thanh toán của người dùng Việt.
Họ đặt lên bàn cân ba ứng viên: VNPAY, Payoo, và Stripe. Functional requirement quyết định: phải hỗ trợ thẻ nội địa và ví điện tử phổ biến. Stripe rớt ngay ở yêu cầu này dù điểm DX cao nhất. Giữa VNPAY và Payoo, Technical PM chấm theo trọng số: phủ phương thức thanh toán (40%), phí giao dịch (25%), chất lượng API/tài liệu (20%), chất lượng support tiếng Việt (15%). VNPAY thắng nhờ độ phủ rộng và mạng lưới ngân hàng lớn.
Bài học: DX tuyệt vời không cứu được một vendor không đáp ứng functional requirement cốt lõi của thị trường bạn. Luôn bắt đầu từ nhu cầu thật của người dùng cuối, không phải sở thích kỹ thuật của đội.
Ví dụ 2 — Cú sốc hóa đơn từ một dịch vụ "miễn phí khi nhỏ"
Một startup SaaS ở Singapore chọn Firebase của Google làm backend vì khởi đầu gần như miễn phí và dựng prototype cực nhanh. Sản phẩm thành công, lượng người dùng tăng từ 5.000 lên 200.000 trong một năm. Rồi hóa đơn Firestore nhảy từ vài trăm đô lên hơn 9.000 USD mỗi tháng, chủ yếu vì mô hình tính phí theo số lượt đọc tài liệu — mỗi lần load màn hình dashboard kích hoạt hàng chục nghìn lượt đọc.
Tệ hơn, dữ liệu đã bị khóa chặt vào mô hình NoSQL độc quyền của Firestore. Migrate sang Postgres tự quản lý mất ba tháng kỹ sư và phải viết lại tầng truy vấn — một dạng vendor lock-in điển hình mà không ai dự liệu khi ký.
Bài học: Khi đánh giá vendor tính phí theo usage, hãy mô phỏng hóa đơn ở quy mô 10x và 100x ngay từ đầu, chứ không phải ở quy mô hiện tại. Và luôn hỏi: "Đường thoát ra sao?" trước khi cắm rễ quá sâu.
Ví dụ 3 — Vendor email và yêu cầu deliverability
Một công ty fintech cần gửi email giao dịch (OTP, biên lai). Đội rút xuống còn SendGrid và Amazon SES. SES rẻ hơn nhiều — chênh khoảng 80% chi phí. Nhưng Technical PM hỏi đúng câu non-functional then chốt: deliverability (tỷ lệ email vào hộp thư chính thay vì spam) và tốc độ làm nóng IP (IP warming).
SES rẻ nhưng đẩy phần lớn việc quản lý uy tín IP, xử lý bounce và compliance sang phía khách hàng. Với email OTP fintech, một email OTP rơi vào spam đồng nghĩa người dùng không đăng nhập được — thiệt hại trải nghiệm lớn hơn nhiều khoản chênh chi phí. Đội chọn SendGrid cho giai đoạn đầu vì tooling deliverability có sẵn, đồng thời ghi vào tài liệu một kế hoạch chuyển sang SES khi đủ năng lực vận hành.
Bài học: Vendor rẻ nhất thường rẻ vì đẩy gánh nặng vận hành sang bạn. Hãy quy đổi gánh nặng đó thành chi phí kỹ sư và rủi ro trải nghiệm, rồi mới so sánh giá.
Hướng dẫn từng bước
Đây là quy trình bạn có thể áp dụng trực tiếp cho lần lựa chọn vendor tiếp theo.
Bước 1 — Định nghĩa nhu cầu (Define need). Trước khi nhìn bất kỳ vendor nào, viết ra một tài liệu yêu cầu ngắn. Gồm bốn phần: (a) functional requirements — danh sách những gì bắt buộc phải làm được, tách rõ "must-have" và "nice-to-have"; (b) non-functional requirements — latency, uptime mục tiêu, quy mô dự kiến (kèm con số 10x); (c) compliance — chứng chỉ và yêu cầu data residency bắt buộc; (d) budget — ngân sách trần và mô hình chi phí chấp nhận được. Tài liệu này là "thước đo" cố định để bạn không bị marketing của vendor dẫn dắt.
Bước 2 — Long-list (lập danh sách dài). Quét thị trường, gom 5–8 ứng viên. Đừng tự giới hạn quá sớm. Hỏi đồng nghiệp, đọc đánh giá độc lập, xem ai đang dùng vendor đó.
Bước 3 — Sàng lọc thành short-list. Áp các yêu cầu "must-have" và compliance như bộ lọc cứng. Bất kỳ vendor nào trượt một must-have hoặc thiếu chứng chỉ bắt buộc đều bị loại, không tranh cãi. Thường bạn còn lại 2–4 ứng viên.
Bước 4 — Đánh giá sâu bằng ma trận có trọng số. Lập bảng tiêu chí, gán trọng số cho mỗi tiêu chí (tổng 100%), chấm điểm từng vendor. Ví dụ: chức năng 30%, độ tin cậy/uptime 20%, chi phí/TCO 20%, bảo mật & compliance 15%, DX & tài liệu 10%, sức khỏe vendor 5%. Trọng số phải phản ánh thực tế bài toán của bạn, không sao chép máy móc.
Bước 5 — Proof of Concept (PoC). Đừng tin slide bán hàng. Cho engineer tích hợp thử trong 2–5 ngày với vendor dẫn đầu. Đo latency thật, thử kịch bản lỗi (vendor sập thì sao?), kiểm tra chất lượng tài liệu và tốc độ phản hồi của support. PoC thường lật ngược kết quả trên giấy.
Bước 6 — Đàm phán và rà soát hợp đồng. Đọc kỹ SLA (Service Level Agreement — cam kết dịch vụ): uptime cam kết bao nhiêu, đền bù ra sao khi vi phạm, support phản hồi trong bao lâu. Kiểm tra điều khoản tăng giá, điều khoản chấm dứt, và quyền xuất dữ liệu (data portability). Đây là lúc kéo procurement và legal vào.
Bước 7 — Quyết định và ghi lại lý do. Viết một quyết định kèm lý do — kiểu một ADR (Architecture Decision Record) ngắn. Sáu tháng sau khi có người hỏi "tại sao chọn vendor này", bạn có câu trả lời, và nếu bối cảnh đổi thì biết giả định nào đã thay đổi.
Lỗi thường gặp & mẹo
Lỗi 1 — Chọn theo cảm tính hoặc thương hiệu. "Công ty lớn ai cũng dùng AWS nên chúng ta cũng dùng" không phải một lý do. Bối cảnh của bạn khác họ.
Lỗi 2 — Bỏ qua chi phí rời đi. Tập trung hết vào lúc cắm vào mà quên hỏi lúc rút ra. Luôn đánh giá vendor lock-in và data portability ngay từ đầu.
Lỗi 3 — Mô phỏng chi phí ở quy mô hiện tại. Như ví dụ Firebase, hóa đơn ở 5.000 user nói rất ít về hóa đơn ở 200.000 user. Luôn tính kịch bản 10x.
Lỗi 4 — Bỏ qua PoC. Tin vào tài liệu marketing mà không kiểm chứng thực tế. Một PoC năm ngày tiết kiệm cho bạn năm tháng hối hận.
Lỗi 5 — Single point of failure (điểm hỏng đơn lẻ). Với dịch vụ sống còn (thanh toán, gửi SMS OTP), cân nhắc thiết kế cho phép có vendor dự phòng, để một vendor sập không kéo cả sản phẩm xuống.
Mẹo: Tách rõ "must-have" và "nice-to-have" ngay từ Bước 1. Phần lớn tranh cãi trong đội nổ ra vì mọi người ngầm coi sở thích cá nhân là yêu cầu bắt buộc.
Mẹo: Đừng đàm phán giá vào cuối quý của chính bạn — hãy đàm phán vào cuối quý của vendor, khi đội sales của họ đang chạy đua chỉ tiêu doanh số và sẵn lòng giảm giá nhất.
Mẹo: Bọc vendor sau một lớp abstraction (interface trừu tượng) trong code. Nếu sau này phải đổi vendor, bạn chỉ thay phần implementation thay vì sửa khắp nơi — giảm mạnh chi phí lock-in.
Bài tập thực hành
- Lập tài liệu yêu cầu. Chọn một dịch vụ thật mà sản phẩm bạn (hoặc một sản phẩm bạn biết) đang cần — ví dụ gửi SMS OTP. Viết tài liệu nhu cầu đầy đủ bốn phần: functional, non-functional (kèm con số uptime và scale cụ thể), compliance, budget. Đánh dấu rõ must-have và nice-to-have.
- Xây ma trận đánh giá có trọng số. Với cùng dịch vụ trên, chọn 3 vendor thật (ví dụ Twilio, Vonage, và một nhà cung cấp SMS nội địa Việt Nam như eSMS hoặc Stringee). Tự gán trọng số tiêu chí, chấm điểm và tính tổng. Viết một đoạn giải thích vì sao trọng số của bạn lại như vậy.
- Phân tích lock-in và chi phí 10x. Với vendor dẫn đầu trong bài 2, trả lời hai câu: (a) nếu muốn rời đi sau một năm, bạn mất gì và bao lâu? (b) ước tính hóa đơn ở quy mô gấp 10 lần hiện tại. Nếu không tìm được số, hãy ghi rõ những giả định bạn dùng.
Tóm tắt
Vendor selection là một trong những quyết định kiến trúc có tác động dài hạn nhất mà Technical PM chủ trì — và là phần mở rộng tự nhiên của quyết định Build vs Buy. Bí quyết không nằm ở việc tìm vendor "tốt nhất" một cách trừu tượng, mà ở chỗ chạy một quy trình có cấu trúc: định nghĩa nhu cầu rõ ràng (functional, non-functional, compliance, budget) trước khi nhìn bất kỳ ai, sàng lọc bằng must-have và chứng chỉ bắt buộc, đánh giá sâu bằng ma trận có trọng số, kiểm chứng bằng PoC thật, rồi rà soát SLA và đường thoát trước khi ký.
Ba cái bẫy phải khắc cốt: đừng chọn theo thương hiệu, đừng quên chi phí rời đi (vendor lock-in), và đừng mô phỏng chi phí ở quy mô hiện tại. Ba ví dụ — cổng thanh toán ShopViet, cú sốc hóa đơn Firebase, và bài toán deliverability email — đều cho thấy cùng một điều: vendor "tốt nhất trên giấy" thường không phải vendor đúng cho bối cảnh cụ thể của bạn. Việc của bạn là biến "bối cảnh cụ thể" đó thành một quy trình tường minh, để mỗi quyết định mua đều có lý do bạn có thể bảo vệ trước cả đội kỹ thuật lẫn ban lãnh đạo.