Vì sao "chất lượng Nhật" không tự tái hiện ở team offshore Việt Nam?

Lý do lớn nhất khiến "chất lượng Nhật" không tự tái hiện ở team offshore Việt Nam không phải là năng lực kỹ thuật, mà là việc những chuẩn chất lượng phía Nhật coi là hiển nhiên — tri thức ngầm (暗黙知) — đã biến mất ngay tại thời điểm vượt biển. Một chuẩn chưa từng được truyền đạt thì đội giỏi đến mấy cũng không thể làm đúng.

TL;DR (Executive Summary)

  • Bài toán: Sản phẩm offshore "chạy đúng spec nhưng vẫn bị chê chất lượng" vì phần lớn chuẩn chất lượng của phía Nhật là tri thức ngầm chưa bao giờ được viết ra.
  • Giải pháp: Nhận diện 3 khoảng trống — spec viết kiểu "tự hiểu", chuẩn review nằm trong đầu reviewer, lệch nhịp báo cáo — và lấp bằng bộ 4 công cụ: Definition of Done, spec kèm ví dụ mẫu, bảng tiêu chí review, luật escalation.
  • Kết quả: Chất lượng trở thành thứ tái hiện được bằng quy trình thay vì "ý thức cá nhân"; vòng lặp chỉnh sửa sau review giảm hẳn.

Tôi đứng giữa bên đặt hàng Nhật và hiện trường phát triển Việt Nam suốt 14 năm, với vai trò Delivery Manager kiêm BrSE thị trường Nhật – Việt. Sau 4 năm trực tiếp delivery một SaaS Nhật phục vụ hơn 90.000 cửa hàng, điều tôi có thể khẳng định: phần lớn thứ bị gọi là "vấn đề chất lượng" thực ra là "vấn đề truyền đạt".

"Chất lượng" — hai nước định nghĩa khác nhau ngay từ đầu

Nhìn từ hiện trường delivery, chữ "chất lượng" ở Nhật và ở Việt Nam đang chỉ hai phạm vi khác nhau.

Khía cạnh Định nghĩa ngầm phía Nhật Định nghĩa mặc định phía Việt
Chuẩn hoàn thành Spec + "sự chu đáo" (edge case, trải nghiệm dùng) Chạy đúng những gì spec viết
Xử lý lỗi Thông báo tử tế, người dùng không bị lạc Lỗi được bắt, hệ thống không sập
Báo biểu / UI Căn cột, ngắt dòng, thẩm mỹ cũng là chất lượng Dữ liệu hiển thị đúng
"Xong rồi ạ" nghĩa là Đã test + đã soát cả phần trình bày Các case chính đã chạy

Điểm quan trọng: không bên nào sai. Định nghĩa của phía Việt là chuẩn phổ biến của ngành phần mềm toàn cầu. Vấn đề nằm ở chỗ phía Nhật đặt hàng theo cột phải nhưng nghiệm thu theo cột trái. Với người bị nghiệm thu bằng những chuẩn chưa từng được viết ra, điều đó không khác gì "đổi spec sau khi giao hàng".

3 khoảng trống tri thức ngầm làm chất lượng bốc hơi

Khoảng trống 1: Spec viết trên giả định "người đọc tự hiểu"

Spec Nhật được viết với giả định người đọc cùng văn hóa sẽ tự lấp đầy phần giữa các dòng chữ. "Xử lý phù hợp", "hiển thị cho đẹp", "theo flow nghiệp vụ thông thường" — với đồng nghiệp người Nhật thì đủ hiểu, nhưng với một team không chia sẻ ngữ cảnh văn hóa, đó là những dòng chữ mang lượng thông tin bằng không.

Không phải team Việt không biết đọc giữa các dòng. Mà là thứ nằm giữa các dòng vốn không tồn tại bên ngoài nền văn hóa đó.

Khoảng trống 2: Chuẩn review nằm trong đầu reviewer

Tôi hay nhận được câu hỏi: "Có code review đều đặn mà chất lượng vẫn không lên". Nhìn vào thực tế thì các góp ý của reviewer phía Nhật lặp đi lặp lại: "đặt tên khó hiểu", "thiếu log", "trình bày thế này không nhận được".

Đó là dấu hiệu cho thấy những điều được góp ý lẻ tẻ trong review chưa hề tồn tại dưới dạng văn bản chuẩn. Chuẩn không được viết ra thì dev mỗi lần đều phải đoán xem trong đầu reviewer có gì, và cùng một góp ý cứ thế tái sinh vô hạn.

Khoảng trống 3: Lệch nhịp "hou-ren-sou" (báo cáo – liên lạc – bàn bạc)

Ở hiện trường Nhật, "tin xấu phải báo sớm nhất" là lẽ thường. Ở hiện trường Việt, tự xử lý xong vấn đề rồi mới báo cáo mới là có trách nhiệm — đó là cách thể hiện sự tận tâm. Engineer im lặng gồng vì tinh thần trách nhiệm, nhưng trong mắt phía Nhật lại thành "giấu vấn đề". Sự bất đối xứng này chính là nguồn gốc của câu "thật ra là chưa chạy được ạ" ngay sát deadline.

Đây không phải vấn đề đạo đức nghề nghiệp, mà là vấn đề luật chơi "khi nào – báo gì – cho ai" đang ở dạng ngầm định. (Cấu trúc này nối thẳng với "sự đứt gãy trách nhiệm" tôi đã viết trong bài vì sao 70% dự án IT outsourcing thất bại.)

Giải pháp: Bộ 4 công cụ chuyển tri thức ngầm thành tường minh

Khi vào gỡ một dự án Việt – Nhật, trong 2 tuần đầu tôi luôn dựng đủ 4 thứ sau:

  1. Definition of Done (định nghĩa hoàn thành) — Checklist hóa các điều kiện chất lượng nằm sau câu "chạy đúng spec", gắn vào điều kiện nghiệm thu từng task: log, hành vi khi có ngoại lệ, chuẩn trình bày UI.
  2. Spec dẫn bằng ví dụ mẫu — Thay vì viết "xử lý phù hợp", đặt 3 cặp input → output kỳ vọng: 1 case thường, 1 case biên, 1 case lỗi. Ví dụ luôn hùng hồn hơn tính từ.
  3. Bảng tiêu chí review — Mỗi góp ý review được bổ sung ngay vào bảng tiêu chí, chuyển dần từ "người review" sang "chuẩn review". Duy trì 3 tháng là có bộ chuẩn chất lượng riêng của chính công ty đó.
  4. Luật escalation — Văn bản hóa "tra cứu 15 phút không ra thì hỏi", "phát hiện rủi ro thì báo trước khi tự xử lý", và tuyên bố rõ báo sớm được đánh giá cao. Không thành luật thì mặc định văn hóa sẽ thắng.

Mấu chốt: cả 4 công cụ đều theo hướng "đưa vào cơ chế" thay vì "thay đổi ý thức". Kỳ vọng vào ý thức không vượt được bức tường văn hóa — nhưng checklist thì có.

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

Năng lực kỹ thuật của engineer Việt Nam có thật sự ổn không?

Năng lực kỹ thuật lõi hoàn toàn đủ, tốc độ học của lớp engineer trẻ không thua kém Nhật. Khác biệt nằm ở tri thức nghiệp vụ (thương quán Nhật, văn hóa báo biểu, flow nghiệp vụ) và độ chia sẻ chuẩn chất lượng. Hai thứ này không giải quyết được bằng tuyển dụng — chỉ giải quyết được bằng quy trình.

Viết spec chi tiết toàn bộ thì chi phí có quá cao không?

Không cần chi tiết hóa mọi thứ. Chỉ đáng đầu tư vào những chỗ chứa tri thức ngầm văn hóa: spec CRUD một dòng là đủ, nhưng format báo biểu, thông báo lỗi, ngoại lệ nghiệp vụ thì phải viết kèm ví dụ. Chính khả năng phán đoán độ đậm nhạt này là giá trị của người hiểu hiện trường cả hai phía — BrSE hay Delivery Manager.

Nếu anh/chị đang ở trạng thái "nói bao nhiêu lần chất lượng vẫn không đều" với team offshore, xác suất cao vấn đề không nằm ở năng lực team mà ở khâu truyền đạt chuẩn. Muốn gỡ rối hiện trạng, anh/chị 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.