Dự án offshore Nhật–Việt trễ: Có nên thay vendor?

#Trễ tiến độ là kết quả, chưa phải nguyên nhân

Một kế hoạch đỏ không tự nói được vì sao nó đỏ. Cùng một biểu hiện “trễ hai sprint” có thể đến từ những cơ chế hoàn toàn khác nhau:

• Scope tăng nhưng baseline không được cập nhật.
• Business requirement chưa đủ rõ để chuyển thành acceptance criteria.
• Bên Nhật mất nhiều vòng để chốt quyết định, còn bên Việt Nam vẫn giữ lịch cũ.
• BrSE truyền câu chữ nhưng không làm rõ ý định và điều kiện nghiệm thu.
• Vendor thiếu năng lực kỹ thuật hoặc không đủ người như cam kết.
• Chất lượng thấp tạo ra vòng lặp sửa lỗi, test lại và mở lại issue.
• Kiến trúc hiện tại khiến mỗi thay đổi chạm vào quá nhiều phần của hệ thống.

JUAS IT2026 cho thấy trong 172 dự án không đạt kế hoạch chất lượng, “thiếu năng lực vendor” được chọn ở 59,9%; nhưng “thiếu sót khi lập kế hoạch” và “độ phức tạp nghiệp vụ/hệ thống vượt dự kiến” cũng cùng ở mức 48,8%. Đây không phải số liệu riêng cho offshore Việt Nam, nhưng nó chỉ ra một điều quan trọng: thay nhà cung cấp không tự sửa được lỗi kế hoạch hoặc độ phức tạp mà tổ chức chưa nhìn thấy.

Vì vậy, câu hỏi đầu tiên không phải “vendor này có tệ không?”, mà là:

Nếu thay toàn bộ đội ngày mai, nguyên nhân khiến dự án trễ có đi theo sang đội mới không?

#Kiểm chứng trục 1: Dữ liệu delivery có đáng tin không?

Sponsor không thể ra quyết định từ phần trăm hoàn thành do chính đội thực thi tự ước lượng. “Đã xong 80%” không có nghĩa nếu chưa biết 80% của scope nào, đã qua điều kiện nghiệm thu nào và phần còn lại chứa bao nhiêu rủi ro.

Tôi thường dựng lại một baseline sự thật từ các artifact sau:

Nếu vendor sẵn sàng mở artifact, giải thích được chênh lệch và sửa báo cáo khi phát hiện sai, dự án vẫn còn nền tảng để phục hồi. Nếu mỗi con số chỉ tồn tại trong slide, sponsor chưa có dữ liệu để chọn “giữ” hay “thay”.

#Kiểm chứng trục 2: Đội hiện tại còn khả năng phục hồi không?

Một kế hoạch recovery đáng tin không phải danh sách “tăng OT, tăng người, cố gắng giao đúng hạn”. Nó phải cho thấy đội đã hiểu cơ chế gây trễ và có thể thay đổi cơ chế đó.

Hãy chọn một lát cắt công việc đủ nhỏ nhưng đi xuyên quy trình: làm rõ yêu cầu, thiết kế, code, review, test và demo. Trong một chu kỳ kiểm chứng ngắn, quan sát năm điều:

1. Requirement có được chuyển thành acceptance criteria trước khi code không?
2. Rủi ro có được báo ngay khi phát hiện hay đợi đến cuộc họp định kỳ?
3. Người có quyền quyết định ở hai phía có phản hồi đúng luồng không?
4. Definition of Done có được dùng để chặn sản phẩm chưa đủ chất lượng không?
5. Sau một lỗi, đội có thay đổi cách làm hay chỉ sửa đúng lỗi đó?

Đây là bài test về khả năng học và sửa hệ thống delivery, không phải cuộc thi chạy nhanh một ticket. Đội hiện tại có tri thức nghiệp vụ mà đội mới chưa có; nếu họ chứng minh được khả năng phục hồi, giữ tri thức đó thường ít rủi ro hơn một lần thay toàn bộ.

Ngược lại, việc lặp lại cùng một cam kết mà không đổi cách vận hành là tín hiệu đỏ. Một recovery plan chỉ có ý nghĩa khi artifact và hành vi thay đổi.

#Kiểm chứng trục 3: Bên đặt hàng có kiểm soát tài sản dự án không?

Quyền kiểm soát không có nghĩa bên đặt hàng phải tự vận hành mọi thứ. Nó có nghĩa doanh nghiệp có thể tiếp tục dự án mà không bị một cá nhân hoặc một tài khoản của vendor giữ làm điểm nghẽn duy nhất.

Kiểm tra tối thiểu:

• Repository source code thuộc tổ chức nào, ai có quyền quản trị và lịch sử commit có đầy đủ không?
• Tài khoản cloud, domain, CI/CD, monitoring và dịch vụ bên thứ ba đứng tên ai?
• Có thể dựng môi trường từ tài liệu hiện tại hay chỉ một người biết cách làm?
• Schema dữ liệu, migration và quy trình backup/restore có được kiểm chứng không?
• Backlog, issue, test evidence và decision log có thể export không?
• Quyền sở hữu code, dữ liệu và tài khoản được quy định thế nào trong hợp đồng?

Nếu các tài sản này còn nằm ngoài tầm kiểm soát, việc tuyên bố thay vendor trước khi lập kế hoạch bàn giao có thể làm dự án mất thêm dữ liệu và tri thức. Với dấu hiệu vi phạm bảo mật, chiếm giữ tài sản hoặc tranh chấp quyền sở hữu, cần đưa bộ phận pháp lý và an toàn thông tin vào ngay; một bài blog không thể thay thế việc đọc hợp đồng cụ thể.

#Ma trận quyết định: Không chỉ có “giữ” hoặc “thay”

Sau ba trục kiểm chứng, sponsor có bốn hướng xử lý thực tế.

Điểm quan trọng là thay cả công ty không phải mức can thiệp duy nhất. Nhiều dự án cần thay một vai trò có quyền chịu trách nhiệm end-to-end, hoặc cần một người độc lập đứng về phía đặt hàng để dựng lại baseline và governance.

Tôi mô tả rõ phạm vi trách nhiệm ở trang BrSE Nhật–Việt và Delivery Management. Nếu anh/chị cần phân biệt vai trò này với một người chỉ truyền đạt ngôn ngữ, tôi đã viết riêng về BrSE và bốn cấp trưởng thành. Bài vì sao “chất lượng Nhật” bị mất trong offshore đi sâu hơn vào cách biến tri thức ngầm thành tiêu chí kiểm chứng được.

#Khi nào tôi nghiêng về sửa governance?

Tôi ưu tiên sửa governance trước khi thay vendor nếu phần lớn tín hiệu sau còn đúng:

• Vendor mở được dữ liệu thật, kể cả dữ liệu bất lợi cho họ.
• Key member hiểu nghiệp vụ và hợp tác với việc đánh giá độc lập.
• Lỗi lặp lại chủ yếu đến từ requirement, quyền quyết định hoặc Definition of Done chưa rõ.
• Một lát cắt nhỏ có thể đi từ yêu cầu đến nghiệm thu với cách làm mới.
• Bên đặt hàng cũng chấp nhận sửa phần trách nhiệm của mình.

“Sửa governance” không có nghĩa họp nhiều hơn. Nó thường là giảm số lớp báo cáo, định nghĩa lại ai quyết định gì, tách issue khỏi risk, đưa acceptance criteria lên trước code và khiến chất lượng được nhìn thấy sớm hơn.

#Khi nào tôi nghiêng về thay vendor?

Tôi xem thay vendor là lựa chọn hợp lý khi có một hoặc nhiều điều kiện nghiêm trọng sau:

• Không thể đối chiếu báo cáo với source code, bản build, test result hoặc môi trường chạy thật.
• Vendor liên tục đổi giải thích nhưng không cập nhật baseline hay recovery plan.
• Nhân sự chủ chốt được cam kết không tham gia, và không có người thay thế đủ quyền chịu trách nhiệm.
• Một lát cắt kiểm chứng vẫn lặp lại cùng lỗi requirement, review hoặc chất lượng.
• Việc tiếp cận repository, hạ tầng, tài liệu hoặc dữ liệu tiếp tục bị trì hoãn không có căn cứ.
• Có vi phạm bảo mật, tuân thủ hoặc nghĩa vụ hợp đồng cần escalation chính thức.

Ngay cả khi quyết định thay, mục tiêu vẫn là bảo toàn business continuity, không phải thắng một cuộc tranh luận với vendor cũ.

#Checklist chuyển giao để không mang “món nợ cũ” sang đội mới

Trước khi đội mới nhận scope, cần chốt ít nhất các nhóm artifact sau:

1. Code và build: repository, branch strategy, tag/release, dependency, secret inventory, cách build và deploy.
2. Hạ tầng: sơ đồ môi trường, cloud account, domain, certificate, CI/CD, monitoring, backup và restore.
3. Dữ liệu: schema, migration, data dictionary, integration, quyền truy cập và yêu cầu bảo mật.
4. Sản phẩm: scope đã duyệt, backlog, acceptance criteria, known limitation và các quyết định bị hoãn.
5. Chất lượng: test case, test result gần nhất, defect backlog, lỗi production và phạm vi chưa test.
6. Kiến trúc: system context, dependency, ADR, điểm nợ kỹ thuật và lý do của các trade-off cũ.
7. Vận hành: runbook, alert, incident cũ, SLA/OLA và đầu mối của dịch vụ bên thứ ba.
8. Thương mại/pháp lý: quyền sở hữu, license, hợp đồng phụ, nghĩa vụ bàn giao và dữ liệu cần xóa sau chuyển giao.

Đừng yêu cầu đội mới “estimate lại toàn bộ” từ một thư mục tài liệu chưa xác thực. Hãy cho họ một scope nhỏ để dựng được, chạy được và test được trước. Sau đó mới dùng tốc độ thực tế của đội mới để lập lại kế hoạch.

Với các tài sản web, có thể dùng thêm checklist nghiệm thu và bàn giao 22 mục để kiểm tra domain, hosting, source code và tài khoản. Với dự án phần mềm lớn hơn, cần mở rộng checklist theo kiến trúc, dữ liệu và yêu cầu tuân thủ thực tế.

#Ba câu hỏi sponsor nên hỏi trong cuộc họp tiếp theo

1. “Bản build nào chứng minh tiến độ hiện tại, và phần nào chưa qua acceptance criteria?”
2. “Trong hai tuần tới, cơ chế nào sẽ thay đổi — không chỉ task nào sẽ được làm?”
3. “Nếu phải chuyển giao hôm nay, tài sản hoặc tri thức nào chúng ta chưa tự kiểm soát?”

Ba câu hỏi này buộc cuộc họp quay về evidence, cơ chế và continuity. Nếu câu trả lời rõ dần qua từng lần kiểm chứng, dự án còn khả năng phục hồi. Nếu câu trả lời tiếp tục mơ hồ, sponsor đã có căn cứ tốt hơn để tăng mức can thiệp.

#Câu hỏi thường gặp

#Dự án trễ bao lâu thì nên thay vendor?

Không có một số tuần áp dụng cho mọi dự án. Mức độ trễ phải được đặt cạnh giá trị kinh doanh, critical path, chi phí chuyển giao và khả năng phục hồi đã được kiểm chứng. Một tuần trễ ở luồng pháp lý bắt buộc có thể nghiêm trọng hơn một tháng trễ ở module có thể hoãn.

#Có nên đưa thêm người vào để kéo lại tiến độ không?

Chỉ khi backlog có thể tách, môi trường và tài liệu đủ để onboarding, và bottleneck thực sự là năng lực thực thi. Nếu bottleneck nằm ở requirement hoặc quyền quyết định, thêm người chỉ làm số luồng chờ và chi phí phối hợp tăng lên.

#Bên đặt hàng không có người kỹ thuật thì đánh giá thế nào?

Hãy dùng một bên độc lập đứng về phía sponsor để dựng baseline, kiểm tra artifact và điều phối decision gate. Người này không nên đồng thời bán đội thay thế trong lúc đánh giá, vì như vậy kết luận “đổi vendor” có xung đột lợi ích rõ ràng.

Tôi trực tiếp làm việc ở giao điểm giữa khách Nhật, đội Việt Nam và kiến trúc hệ thống. Nếu dự án đang trễ nhưng chưa rõ nên sửa governance, thay vai trò hay chuẩn bị chuyển giao, anh/chị có thể gửi hiện trạng dự án. Tôi sẽ bắt đầu từ artifact và rủi ro delivery hiện có, không mặc định giải pháp là thay vendor.