Chào cả Trạm❣️
Hôm nay mình muốn kể một câu chuyện rất “thực tế” mà chắc hẳn bất cứ bạn Comtor hoặc BrSE nontech nào cũng từng trải qua ít nhất một lần:

Dev viết QA, mình đọc đi đọc lại 10 lần vẫn không hiểu bạn ấy đang nói gì và muốn hỏi gì.
Nhưng lúc đó mới dô ngành nên tính cách còn rụt rè và nhút nhát, hỏi lại thì sợ bị nói là "chậm tiêu, kém hiểu" rồi dễ bị quy chụp là "đúng kiểu dân nontech, có vậy mà cũng không hiểu", thế là mình bê nguyên nội dung sang confirm với khách.
Kết quả là bị khách claim cho một trận nhớ đời. Mà Khách này khá là nai sừ (nice), thay vì nhắn mình là ông không hiểu nội dung confirm,

ông lại đi escalate trực tiếp lên anh PM người nhật ^^.

Đấy, rõ ràng vấn đề bắt nguồn từ tiếng việt của dev khó hiểu, cuối cùng mình bị khách chửi, bị sếp claim, rồi bị chính dev bảo là "không hiểu saoo không hỏi lại rồi để bị claim" ^^.

Vậy nên hôm nay mình viết bài này để chia sẻ cách mình xử lý "ngôn ngữ của dev" trước khi truyền đạt sang site khách hàng.

 

🔹 Khi dev gửi nội dung tiếng việt, nhưng đọc chẳng hiểu gì sấc

 

Lấy ví dụ dev gửi nội dung confirm sample như dưới đây:

1 bác sĩ trực thuộc 1 clinic, 1 clinic sử dụng nhiều service.
Clinic dùng service A với gói tối đa 4 người dùng trả phí.
Khi Service B ra đời, có thể:

  1. Quota Service B riêng biệt (ví dụ cũng 4 user trả phí)

  2. Hoặc dùng chung quota với Service A (tổng cộng 4 user trả phí cho cả A + B)
    Notes:
    • Danh sách User — Điều chỉnh: Thêm column vào DB để đánh dấu client của service tương ứng; chỉnh lại query filter để lấy đúng dữ liệu theo service.
    • Tạo mới user — Điều chỉnh: Lưu thêm client thuộc service nào.

Lúc đọc xong, mình kiểu: Ơ quota là gì? DB là gì? Query filter là sao nữa ????
Nếu mình không hỏi kỹ mà bê nguyên nội dung này gửi khách confirm, thì chắc chắn khách nontech cũng sẽ không hiểu luôn.
→ Rơi vào vòng lặp “không hiểu → hỏi sai → khách không hiểu → khách claim mình → dev claim mình” 🌀

 

🔹 Vậy cần làm gì? → Hiểu bản chất dev đang nói gì trước đã

Trước khi gửi QA sang cho khách, hãy ngồi đọc kỹ từng dòng dev viết và tự hỏi ngược lại bản thân:

  • Câu này mình thực sự hiểu chưa?

  • Trong nội dung này, có chỗ nào mình cảm thấy lấn cấn, cảm thấy đọc thấy sai sai, không đúng không?

  • Với nội dung như thế này, nếu đặt mình là khách mình có bắt bẻ ngược lại ở những chỗ nào không?

Nếu chưa đáp ứng các câu hỏi trên thì phải confirm lại với dev ngay, chứ đừng nghĩ rằng team đặt QA thì lo đâm đầu vào dịch rồi gửi khách ngay là xem như toang chính mình luôn ấy.

Như trong ví dụ trên, ta cần làm rõ những điểm sau:

1️⃣ “Quota” là gì vậy?

Hỏi dev:

“Ở đây ‘quota’ đang nói tới cái gì trong hệ thống?”

Confirm lại với dev mới hiểu
👉 “Quota” chính là số lượng user tối đa có thể được tạo trong mỗi service.

Ví dụ:

  • Service A có thể có tối đa 4 user trả phí.

  • Khi hệ thống sinh ra thêm 1 service mới, gọi là Service B, khi đó sẽ sinh ra bài toán với 2 lựa chọn như sau:

    1. Nếu muốn từng service tính toán theo quota riêng → Servicce A đã đăng ký gói dùng 4 users, Service B cũng sẽ có tối đa 4 user riêng biệt.

    2. Nếu muốn từng service dùng chung quote với service đã có sẵn (cụ thể là service A) → Tổng user trả phí của cả service A + service B vẫn phải là 4.

➡ Khi hiểu được bản chất của vấn đề như trên, bạn có thể viết lại QA một tách tường minh hơn, mà người đọc cũng sẽ dễ hình dung vấn đề đang đề cập ở đây là gì.

 

2️⃣ “Điều chỉnh DB, thêm cột, chỉnh query filter” là làm gì?

Dev viết vậy nghe đơn giản, nhưng nếu không phải là dân technical, bạn sẽ không hình dung được dev đang muốn làm gì.

Vậy nên khi hỏi lại dev cụ thể hơn:

  • Điều chỉnh DB ở đây nghĩa là sao?

  • Đánh dấu client của service tương ứng là làm gì?

  • Chỉnh query filter tức là chỉnh đoạn nào, dùng để làm gì?

Khi hỏi kỹ, bạn sẽ hiểu được:

👉 “Điều chỉnh DB” tức là thay đổi cấu trúc database hiện tại để hệ thống có thể quản lý user theo từng service.
Cụ thể:

  • Thêm cột service_type trong DB để đánh dấu user thuộc service nào.
    (Ví dụ: user X thuộc service A, user Y thuộc service B.)

  • Chỉnh lại câu lệnh SQL (query) – đây là đoạn lệnh dùng để lấy danh sách user.
    Vì trước đây hệ thống chỉ có 1 service, nên query chỉ cần get toàn bộ user.
    Nhưng bây giờ có 2 service, nên phải chỉnh lại để có thể get user theo từng service tương ứng.

➡ Nhờ hiểu được logic này, bạn có thể viết lại mô tả cho khách bằng ngôn ngữ dễ hiểu mà không gây hoang mang cho khách hàng.

 

3️⃣ “Tạo mới client: lưu thêm client thuộc service nào” tức là gì?

Nếu không hỏi lại dev thì câu này đọc cực kỳ trừu tượng.
Nhưng khi confirm kỹ, bạn sẽ hiểu:

👉 Khi user tạo mới client trên màn hình giao diện, hệ thống sẽ lưu thông tin đó vào DB.
Hiện tại, vì có nhiều service, dev cần chỉnh lại logic lưu dữ liệu, sao cho:

  • User được tạo trong Service A thì được lưu đúng vào Service A.

  • User được tạo trong Service B thì được lưu vào Service B.

➡ Hiểu được vậy thì khi confirm với khách, bạn có thể viết lại thành một câu tiếng nhật dễ hiểu hơn.

 

🥀 Đúc kết lại

Là Comtor hay BrSE nontech, bạn đều đóng vai trò là cây cầu giữa dev và khách, chứ không phải là một cái máy photocopy.
Khi đọc QA mà chưa hiểu: đừng copy-paste, đừng dựa hoàn toàn vào ChatGPT. Dành 5–10 phút đọc lại, take note những chỗ lấn cấn, rồi hỏi dev.

Thà hỏi nhiều lần cho sáng tỏ - còn hơn để khách đọc -> không hiểu và claim ngược lại rồi mọi người cùng vạ lây.

Nhớ nhé:

“Hiểu dev trước đã, rồi mới nói chuyện với khách.”
Bởi vì hiểu sai 1 dòng QA, có thể làm lệch cả hướng phát triển của dự án đấy 😅.