- Bài toán: Hồ sơ chào hàng của các đối tác phát triển phần mềm (vendor) toàn đơn giá, số lượng lập trình viên và logo khách lớn — không dòng nào nói về thứ quyết định thành bại dự án.
- Giải pháp: Chấm theo 5 trục — độ trưởng thành BrSE (Kỹ sư cầu nối), quy trình chất lượng có thật, cấu trúc trách nhiệm, độ gắn bó của team, năng lực thiết kế pilot — và sàng lọc bằng 8 tín hiệu nguy hiểm.
- Kết quả: Tránh được bẫy "rẻ hóa đắt"; chặn từ gốc chi phí sửa đi làm lại và cháy dự án — thứ lớn hơn nhiều lần mức chênh 20-30% đơn giá.
Khi chọn đối tác phát triển phần mềm (vendor outsourcing/offshore), đừng quyết định bằng đơn giá và portfolio. Thứ phân định thành bại của dự án là 5 yếu tố không bao giờ xuất hiện trong hồ sơ chào hàng (sales): độ trưởng thành của BrSE (Kỹ sư cầu nối), quy trình chất lượng có thật hay không, cấu trúc trách nhiệm, độ gắn bó của team, và năng lực thiết kế dự án thử nghiệm (pilot).
Chú thích thuật ngữ cho chủ doanh nghiệp:
- Offshore / Outsourcing: Thuê ngoài phát triển phần mềm (có thể thuê công ty công nghệ trong nước hoặc nước ngoài).
- Vendor: Đơn vị cung cấp dịch vụ công nghệ/thiết kế web/phần mềm.
- BrSE (Bridge Software Engineer - Kỹ sư cầu nối): Nhân sự trung gian đứng giữa bạn và đội ngũ kỹ thuật. BrSE chịu trách nhiệm dịch chuyển các yêu cầu kinh doanh của bạn thành đặc tả kỹ thuật chi tiết để lập trình viên hiểu đúng và code chuẩn.
TL;DR (Executive Summary)
- Bài toán: Hồ sơ chào hàng của vendor chỉ có đơn giá, số lập trình viên và logo khách lớn — không đọc ra được ai chịu trách nhiệm và chất lượng được đảm bảo kiểu gì.
- Giải pháp: Chấm điểm theo 5 trục (độ trưởng thành BrSE / quy trình chất lượng có thật / cấu trúc trách nhiệm / độ gắn bó / năng lực pilot) và loại sớm bằng 8 tín hiệu nguy hiểm.
- Kết quả: Tránh bẫy "rẻ hóa đắt" — chi phí làm lại và cháy dự án lớn hơn nhiều lần mức chênh 20–30% đơn giá.
Tôi có 14 năm làm BrSE kiêm Delivery Manager thị trường Nhật – Việt, đứng ở cả hai phía đặt hàng và vendor, trực tiếp đánh giá vendor và giải cứu dự án nhiều lần. Bài này là chính bộ khung tôi dùng ở hiện trường.
Vì sao không thể đánh giá vendor qua hồ sơ sales?
Proposal của vendor gần như luôn xoay quanh ba thứ: "đơn giá rẻ", "số lượng lập trình viên", "logo công ty lớn từng làm". Nhưng cả ba gần như không tương quan với việc dự án của bạn có thành công hay không.
70% dự án outsourcing thất bại vì đứt gãy trách nhiệm chứ không phải kỹ thuật, và phần lớn vấn đề chất lượng là vấn đề truyền đạt chuẩn. Nghĩa là thứ cần đánh giá không phải "họ làm được gì", mà là "thông tin truyền đi thế nào và ai ở trong cấu trúc chịu trách nhiệm".
Scorecard 5 trục đánh giá vendor
| Trục đánh giá | Cách kiểm chứng | Mức đạt |
|---|---|---|
| 1. Độ trưởng thành BrSE (Kỹ sư cầu nối) | Phỏng vấn trực tiếp người sẽ phụ trách chính | Kể được ví dụ thật từng phản biện hoặc từ chối yêu cầu sai của khách |
| 2. Quy trình chất lượng có thật | Yêu cầu xem bản Definition of Done, tiêu chí review thật | Đưa ra được tài liệu thật của dự án cũ |
| 3. Cấu trúc trách nhiệm | Hỏi "thất bại thì ai chịu trách nhiệm" | Trả lời ngay bằng tên người, vai trò cụ thể |
| 4. Độ gắn bó của team | Hỏi thâm niên từng thành viên được đề xuất | Thành viên cốt lõi (core member) ≥ 2 năm |
| 5. Năng lực thiết kế pilot | Đề nghị phương án khởi đầu nhỏ | Dự án thử nghiệm (pilot) có mục tiêu kiểm chứng giao tiếp rõ ràng |
Trục 1: Độ trưởng thành BrSE — "thông dịch" hay "người chịu trách nhiệm"?
Dòng "BrSE 1 người" trong báo giá không nói lên điều gì. Bắt buộc phỏng vấn chính nhân sự làm cầu nối (BrSE) và hỏi: "Lần gần nhất bạn nói Không với yêu cầu của khách là khi nào?". Nếu họ không kể được ví dụ cụ thể nghĩa là họ chỉ làm vai trò "thông dịch viên" truyền đạt thụ động. Cách phân loại chi tiết tôi đã viết trong bài mô hình 4 cấp trưởng thành của BrSE.
Trục 2: Quy trình chất lượng có thật — đừng nghe "có ạ", hãy nói "cho xem"
Câu "bên em quản lý chất lượng chặt chẽ" không có giá trị thông tin. Hãy yêu cầu xem bản thật của Definition of Done (tiêu chí hoàn thành), bảng tiêu chí review code, báo cáo test của dự án cũ (che phần bảo mật cũng được). Công ty có quy trình thật lấy ra trong vài phút. Công ty không lấy ra được thì quy trình của họ chỉ tồn tại trong slide quảng cáo.
Trục 3: Cấu trúc trách nhiệm — "dự án đổ, điện thoại của ai reo?"
Hỏi thẳng: "Nếu dự án này thất bại, bên công ty anh/chị ai là người chịu trách nhiệm?". Câu trả lời "cả team cùng chịu" hay "công ty chịu trách nhiệm" là tín hiệu nguy hiểm. Chỉ công ty trả lời ngay được bằng một cá nhân cụ thể (Single Point of Accountability) mới vận hành nổi khi dự án gặp sự cố.
Trục 4: Độ gắn bó của team — đội hình trong proposal còn đủ sau 3 tháng?
Vòng quay nhảy việc của ngành IT rất nhanh — chuyện nhân sự chủ lực lúc chào hàng đã nghỉ trước khi dự án bắt đầu không hề hiếm. Hãy hỏi thâm niên của từng thành viên được đề xuất và quy tắc bàn giao khi có người rời đi (tài liệu, thời gian bàn giao). Vendor nói được về chống lệ thuộc cá nhân bằng cơ chế là vendor đáng tin.
Trục 5: Năng lực thiết kế pilot — biết bắt đầu nhỏ một cách thông minh?
Đừng ký hợp đồng lớn ngay; đề nghị vendor đề xuất pilot nhỏ 1–2 tháng. Thứ cần nhìn không phải giá pilot mà là chất lượng thiết kế: pilot này để kiểm chứng cái gì (độ chính xác giao tiếp? quy trình chất lượng? độ hiểu nghiệp vụ?). Vendor định nghĩa rõ được mục tiêu kiểm chứng là vendor biết vận hành chuyên nghiệp.
8 tín hiệu nguy hiểm (dính 1 cái là phải đào sâu)
- Trả lời ngay "làm được" với mọi yêu cầu (không một lần phản biện)
- Báo giá rẻ bất thường (chi phí làm lại chưa được tính vào giá)
- Né tránh việc cho phỏng vấn trực tiếp BrSE/Leader phụ trách
- Hẹn "cần thời gian chuẩn bị" khi được hỏi xem quy trình thật
- Hỏi ai chịu trách nhiệm khi thất bại thì đáp "cả team"
- Đội hình trong proposal khác đội hình trong hợp đồng
- Không kể được một thất bại nào trong quá khứ (không ai chưa từng thất bại)
- Chưa ký đã gợi ý tăng thêm người (dấu hiệu kinh doanh nhân ngày công - man-month)
Chọn xong vendor mới là một nửa chặng đường — nửa còn lại là nhận bàn giao cho đúng. Trước khi thanh toán đợt cuối, hãy đối chiếu với checklist nghiệm thu & bàn giao website 22 mục: tên miền đứng tên ai, source code, hosting, các tài khoản — tick xong xuất được biên bản để hai bên cùng ký.
Trước khi đi đến bước so proposal hay phỏng vấn, hãy chuẩn bị sẵn bộ 16+ câu hỏi chất vấn đơn vị thiết kế web/phần mềm để nhanh chóng nhận diện các câu trả lời né tránh trách nhiệm. Công cụ này sẽ giúp bạn lọc ra những vendor thiếu minh bạch ngay từ vòng đầu và in trực tiếp thành phiếu đánh giá mang vào phòng họp.
Trước khi so các proposal, nên tự khung hoá yêu cầu của mình: công cụ ước lượng chi phí phần mềm theo 5 biến số giúp bạn có một bản mô tả đủ chặt để mọi vendor báo giá trên cùng phạm vi. Gặp thuật ngữ lạ (man-month, BrSE, offshore) khi đọc proposal? Tra nhanh trong từ điển thuật ngữ Delivery – Offshore – AI. Nếu anh/chị đang ở khâu chọn vendor mà cảm giác "proposal rất đẹp nhưng không có căn cứ để tin", có thể gửi bài toán cho tôi. Tôi thường phản hồi các case phù hợp với chuyên môn và quỹ thời gian hiện tại.
Câu hỏi thường gặp
Chọn công ty thiết kế/phát triển phần mềm (offshore/outsourcing) như thế nào cho đúng?
Đừng chọn bằng đơn giá và portfolio. Hãy đánh giá theo 5 trục: 1. độ trưởng thành của BrSE (Kỹ sư cầu nối - người chịu trách nhiệm kết quả hay chỉ thông dịch), 2. quy trình chất lượng có thật không (yêu cầu xem bản Definition of Done, tiêu chí review thật), 3. cấu trúc trách nhiệm khi có sự cố, 4. độ gắn bó của team được đề xuất, 5. năng lực thiết kế dự án thử nghiệm (pilot) khởi đầu nhỏ.
Tín hiệu nguy hiểm lớn nhất khi chọn vendor là gì?
Câu trả lời "gì cũng làm được, giá nào cũng rẻ". Vendor thực lực sẽ phân biệt rõ mảng mạnh - mảng yếu và dám phản biện khi yêu cầu mâu thuẫn. Vendor trả lời Yes với tất cả thường cũng sẽ im lặng trước rủi ro trong dự án, và vấn đề chỉ bùng ra sát deadline.
Nên coi trọng đơn giá rẻ tới mức nào?
Hãy quyết định bằng tổng chi phí (gồm cả sửa lại, trễ hạn, làm lại) thay vì đơn giá. Theo kinh nghiệm thực tế, mức chênh 20-30% đơn giá bị đảo ngược chỉ sau một vòng làm lại nếu chọn nhầm vendor không có quy trình chất lượng thật. Đơn giá là tiêu chí so sánh cuối cùng giữa các vendor đã vượt qua 5 trục đánh giá.
Vendor lớn hay vendor nhỏ an toàn hơn?
Quy mô không phải chỉ số an toàn. Vendor lớn có bộ máy ổn định nhưng dự án của bạn dễ thành "khách hạng thường" và nhận team toàn junior. Vendor nhỏ có thể dồn át chủ bài cho bạn nhưng rủi ro nghỉ việc cao hơn. Cả hai trường hợp, cứ chấm đủ 5 trục — đặc biệt là "phỏng vấn đúng người sẽ làm" — thì độ nhiễu do quy mô được triệt tiêu.
Bên tôi không có người đủ chuyên môn kỹ thuật để đánh giá thì làm sao?
Bên đặt hàng không có người đánh giá được kỹ thuật là cấu trúc bất lợi nhất trong chọn vendor. Khi đó, đưa một bên thứ ba độc lập với vendor (người có kinh nghiệm delivery đứng về phía đặt hàng) vào review proposal, phỏng vấn nhân sự key và đánh giá dự án thử nghiệm sẽ xóa được sự bất đối xứng thông tin.
