Bạn có bao giờ tự hào mình là một “Dev xịn” vì luôn hoàn thành task đúng hạn, code chuẩn Senior review, hay nắm vững các kỹ thuật phức tạp? Tôi đã từng như vậy, cho đến khi nhận được một câu hỏi từ sếp khiến tôi đứng hình: “Em ơi, vậy thì anh thuê IT để làm cái gì?”,.
1. Cái bẫy của tư duy “Hoàn thành task là đủ”
Trong năm đầu tiên đi làm, tôi luôn tự tin mình là một lập trình viên xuất sắc. Tiêu chuẩn “xịn” của tôi lúc đó rất đơn giản: đọc codebase nhanh, đóng task đúng hạn, code sạch (clean code) và được Senior khen ngợi. Tôi luôn tin rằng: Hiểu code và hoàn thành task đúng hạn là Dev xịn.
Nhưng thực tế đã tát tôi một cú đau điếng. Tôi chỉ là người “tô màu đẹp lên cuốn sách của một người khác” mà không hề nhận ra hệ thống mình đang vận hành có những lỗ hổng chết người trong thiết kế dữ liệu.
2. Khi hệ thống “chạy được” nhưng “vô dụng” với Business
Câu chuyện bắt đầu khi chị kế toán yêu cầu tôi lọc danh sách các đơn hàng khách đã trả tiền.
- Ngày 1: Tôi tự tin dùng một câu query đơn giản
where status = 'paid'. - Ngày 2: Chị quay lại nói dữ liệu sai vì bao gồm cả đơn COD (chưa thực sự có tiền trong tài khoản).
- Ngày 3: Phát hiện ra có những đơn đã hoàn tiền (refund) nhưng trạng thái vẫn là
paidvì Schema không có trạng tháirefund. - Ngày 4: Một thảm họa thực sự khi dữ liệu lệch hàng chục triệu đồng. Có những đơn đã từng
paidnhưng sau đó bịcancel, hệ thống của tôi chỉ lưu trạng thái cuối cùng làcancelnên hoàn toàn mất dấu dòng tiền đã vào trước đó,.
Sếp tôi đã nói một câu chí mạng: “Hệ thống chạy được là chuyện đương nhiên, nhưng hệ thống phải trả lời được câu hỏi của business. Đó mới là lý do anh thuê IT”.
3. “Bức ảnh” tĩnh và “Đoạn phim” chuyển động
Tôi nhận ra sai lầm lớn nhất của mình là chỉ lưu trữ trạng thái cuối cùng (Status) — giống như một bức ảnh chụp tĩnh — trong khi thực tế vận hành của doanh nghiệp là một chuỗi các chuyển động (Transitions) — giống như một đoạn phim,.
Các phòng ban không quan tâm đơn hàng đang ở đâu, họ quan tâm nó đã đi qua những đâu:
- Marketing: Cần biết tỷ lệ chuyển đổi qua từng bước (Conversion funnel). Nếu chỉ lưu trạng thái cuối, bạn sẽ mất hết dữ liệu về hành trình khách hàng.
- Chăm sóc khách hàng: Cần biết lịch sử thanh toán để giải quyết các ca khiếu nại (ví dụ: khách bị trừ tiền 2 lần).
- Ban điều hành (Sếp): Cần phân biệt rõ đơn bị hủy trước khi thanh toán (mất doanh thu tiềm năng) và hủy sau khi thanh toán (mất tiền thật và tốn chi phí vận hành) để đưa ra quyết định đầu tư đúng đắn,.
4. Bài học về Status Transition
Trong thiết kế hệ thống, khái niệm Status Transition (chuyển đổi trạng thái) quan trọng hơn nhiều so với bản thân cái trạng thái đó.
- Status hiện tại chỉ là kết quả của bước chuyển cuối cùng.
- Mỗi lần chuyển trạng thái là một sự kiện quan trọng mà business quan tâm.
Data Model không đơn thuần là kỹ thuật, nó là cách chúng ta nhìn nhận Business như một đoạn phim chuyển động, không phải một bức ảnh tĩnh.
Lời kết
Nếu bạn là một Backend Developer, hãy thử nhìn lại dự án gần nhất của mình: Cột status của bạn có bao nhiêu giá trị? Bạn có thể trả lời được câu hỏi: “Trong tháng này có bao nhiêu đơn đã từng ở trạng thái X nhưng giờ không còn ở đó nữa?”.
Nếu không trả lời được, có lẽ bạn đang đi vào vết xe đổ của tôi. Đừng chỉ là một “người gõ phím”, hãy là một kỹ sư hiểu được dữ liệu của mình phục vụ ai và giải quyết vấn đề gì cho doanh nghiệp.
Tham khảo
https://www.youtube.com/watch?v=S7SQZDe6l2Y
