DataOps 2 — Agile & cộng tác cho nhóm dữ liệu

Vì sao Agile "sách giáo khoa" gãy khi gặp công việc dữ liệu

Agile ra đời trong thế giới phát triển phần mềm: yêu cầu tương đối rõ, đầu ra là tính năng đã định hình, và đội có thể chia nhỏ thành các user story ước lượng được. Nhóm dữ liệu áp nguyên xi khung đó thường thấy nó "kêu cọt kẹt" — không phải vì Agile sai, mà vì bản chất công việc khác đủ nhiều để cần điều chỉnh.

Khác biệt cốt lõi nằm ở mức độ bất định. Một task phần mềm điển hình — "thêm nút xuất PDF" — có phạm vi rõ ngay từ đầu. Còn một task dữ liệu — "phân tích vì sao tỷ lệ nợ xấu nhóm thẻ tín dụng tăng quý này" — là một cuộc khám phá: bạn không biết trước dữ liệu có sạch không, có tồn tại biến giải thích không, hay câu trả lời có tồn tại trong dữ liệu bạn có hay không. Ước lượng "task này 3 điểm" gần như vô nghĩa khi 40% khả năng là bạn phát hiện dữ liệu nguồn thiếu cột cần thiết và phải quay lại thương lượng phạm vi.

Bốn đặc thù khiến công việc dữ liệu chống lại Agile cứng nhắc:

• Bất định khám phá (discovery uncertainty): nhiều task là câu hỏi mở, không phải yêu cầu đóng. Kết quả có thể là "không có tín hiệu trong dữ liệu" — vẫn là kết quả hợp lệ nhưng không ra "tính năng".
• Phụ thuộc dữ liệu ngoài tầm kiểm soát: pipeline phụ thuộc nguồn Core Banking, T24, CDC từ Oracle. Nguồn đổi schema, trễ dữ liệu, hay sai bản chất — đội dữ liệu lãnh hậu quả nhưng không sở hữu nguồn.
• Yêu cầu mơ hồ từ nghiệp vụ: "cho tôi báo cáo khách hàng tiềm năng" có thể nghĩa mười thứ khác nhau. Làm rõ yêu cầu chiếm phần lớn công sức thực tế.
• Ad-hoc xen kẽ liên tục: giữa sprint, phòng Tuân thủ cần một truy vấn gấp cho báo cáo NHNN, phòng Rủi ro cần trích danh sách giao dịch nghi ngờ. Việc này không chờ được đến sprint sau.

Bài này (bài 1 series dựng khung DataOps tổng thể) đi sâu vào cách tổ chức và cộng tác để nhóm dữ liệu vừa giao được việc dự án dài hạn, vừa hấp thụ được dòng ad-hoc không dứt của một ngân hàng.

Scrum, Kanban hay Scrumban cho data team

Ba khung phổ biến, và lựa chọn phụ thuộc vào tỷ lệ việc dự đoán được so với việc đến bất chợt.

Vì sao Kanban thường hợp nhóm dữ liệu hơn. Scrum giả định bạn có thể cam kết một khối việc trong 2 tuần và bảo vệ đội khỏi gián đoạn. Nhóm dữ liệu ngân hàng gần như không bao giờ có được sự yên tĩnh đó: chỉ cần một yêu cầu tuân thủ khẩn hay một pipeline hỏng lúc 6 giờ sáng là cam kết sprint vỡ. Kanban chấp nhận luồng công việc liên tục, cho phép kéo (pull) việc mới khi có năng lực, giới hạn việc đang làm (WIP), và tối ưu thời gian chảy qua (cycle time) thay vì tốc độ giao trọn sprint.

Scrumban — lai giữa hai — là điểm ngọt cho nhiều đội: dùng bảng Kanban và WIP limit để quản luồng, nhưng giữ lại vài nghi thức Scrum có giá trị (planning ngắn hàng tuần, retro hai tuần một lần). Đội chạy dự án dài (ví dụ xây data mart mới) theo nhịp planning, đồng thời có làn (lane) riêng hấp thụ ad-hoc theo Kanban.

Khuyến nghị thực tế: nếu hơn ~30% năng lực của đội bị tiêu vào ad-hoc và vận hành, đừng ép Scrum thuần — chọn Kanban hoặc Scrumban.

Bảng Kanban cho luồng công việc dữ liệu

Sơ đồ dưới minh hoạ một bảng Kanban điển hình của nhóm dữ liệu ngân hàng, tách rõ làn dự án và làn ad-hoc/vận hành, với WIP limit trên mỗi cột:

Ba tín hiệu quản trị mà bảng này cung cấp: cột ứ đọng (nhiều thẻ dồn ở Review = thiếu người review), thẻ già (thẻ nằm quá lâu = bị kẹt phụ thuộc), và làn ad-hoc phình to (dấu hiệu đội bị kéo khỏi việc dự án). Việc "Spike" quay ngược về Backlog thể hiện đúng bản chất khám phá: kết quả của nó là thông tin để lập kế hoạch tiếp, không phải sản phẩm giao ngay.

Quản lý backlog và ưu tiên đa nguồn

Nhóm dữ liệu ngân hàng nhận yêu cầu từ khắp nơi: Rủi ro, Tuân thủ, Kinh doanh, Marketing, Ban điều hành, và cả nội bộ (nợ kỹ thuật, giám sát). Không có một "product owner" duy nhất kiểm soát dòng vào. Nếu để mỗi phòng tự đẩy việc vào theo kênh riêng, đội chết chìm.

Phân loại việc trước khi ưu tiên. Ba nhóm bản chất khác nhau, không nên xếp chung một hàng:

Khung ưu tiên giá trị/nỗ lực. Với backlog dự án, dùng một khung nhẹ để tránh tranh cãi cảm tính. Ma trận Value–Effort (2x2) là điểm khởi đầu tốt: việc giá trị cao – nỗ lực thấp làm trước (quick win), giá trị cao – nỗ lực cao lập kế hoạch kỹ, giá trị thấp – nỗ lực thấp nhét vào khe trống, giá trị thấp – nỗ lực cao từ chối. Với đội trưởng thành hơn, dùng WSJF (Weighted Shortest Job First) = (giá trị nghiệp vụ + tính cấp thời + giảm rủi ro) / kích cỡ công việc, để so sánh việc từ nhiều phòng trên cùng thang.

Điểm mấu chốt về mặt tổ chức: ưu tiên phải minh bạch và tập trung. Lập một backlog chung, một người/hội đồng điều phối (intake), và một nhịp rà soát ưu tiên định kỳ (ví dụ mỗi thứ Hai). Khi phòng Marketing thấy việc của họ xếp sau báo cáo tuân thủ và hiểu lý do, mâu thuẫn giảm hẳn.

User story và Definition of Done cho sản phẩm dữ liệu

Mẫu user story kinh điển vẫn dùng được, nhưng phải chỉnh cho analytics — trọng tâm là quyết định mà dữ liệu phục vụ, không phải chức năng phần mềm:

Là cán bộ thẩm định tín dụng, tôi cần báo cáo tỷ lệ nợ quá hạn theo phân khúc khách hàng cập nhật hàng ngày, để quyết định điều chỉnh khẩu vị rủi ro cho nhóm vay tiêu dùng.

Cấu trúc "Là vai trò, tôi cần dữ liệu/báo cáo, để quyết định". Vế "để" là quan trọng nhất: nó ép người yêu cầu nói rõ họ sẽ làm gì với con số, nhờ đó đội biết độ chính xác, độ trễ và mức chi tiết thực sự cần. Một báo cáo để "tham khảo tổng quan" và một báo cáo để "gửi NHNN" có yêu cầu chất lượng hoàn toàn khác nhau.

Kèm theo là tiêu chí chấp nhận (acceptance criteria) cụ thể: nguồn dữ liệu nào, độ trễ tối đa bao lâu, cách xử lý giá trị thiếu, định nghĩa "nợ quá hạn" chính xác (bao nhiêu ngày DPD).

Definition of Done (DoD) cho sản phẩm dữ liệu phải khắt khe hơn phần mềm, vì đầu ra sai lệch âm thầm còn nguy hiểm hơn app crash — không ai biết con số sai cho đến khi ra quyết định sai. Một DoD tối thiểu:

• Đã test: kiểm thử dữ liệu (không null ở khoá, không trùng, hàng tổng khớp nguồn, khoảng giá trị hợp lý) — xem chi tiết ở bài kiểm thử & chất lượng và dbt tests/docs.
• Đã đối chiếu (reconciled): số liệu khớp nguồn chân lý (ví dụ tổng dư nợ khớp Core Banking) trong ngưỡng chấp nhận.
• Có tài liệu: định nghĩa cột, nguồn, logic biến đổi, người sở hữu — vào catalog (xem tài liệu & catalog).
• Đã deploy có kiểm soát: qua Git + CI/CD, không sửa tay trên production (version & Git, CI/CD).
• Có giám sát: có cảnh báo nếu pipeline hỏng hoặc số lệch bất thường (observability & incident).

Ước lượng việc bất định: Spike và khám phá

Ước lượng thời gian cho một task khám phá là bài toán không có lời giải chính xác. Thay vì ép đội cam kết "3 ngày cho phân tích này", dùng hai công cụ.

Spike — một task được đóng hộp thời gian (time-boxed) với mục tiêu học, không phải giao. "Dành 1 ngày điều tra xem dữ liệu giao dịch ATM có đủ để dựng mô hình gian lận không." Đầu ra của spike là một quyết định: khả thi/không, cần dữ liệu gì thêm, ước lượng thô cho việc thật. Spike biến bất định thành thông tin trước khi cam kết công sức lớn.

Ước lượng theo dải, không theo điểm. Với việc còn mờ, cho ước lượng dạng "3–8 ngày" và ghi rõ các giả định phá vỡ dải này ("nếu dữ liệu nguồn thiếu cột X thì +5 ngày"). Đội nên tách rạch ròi hai loại: việc đã hiểu (kỹ thuật, ước lượng được, ví dụ "dựng bảng aggregate") và việc chưa hiểu (khám phá, dùng spike). Trộn lẫn hai loại là nguyên nhân số một khiến kế hoạch dữ liệu luôn trễ.

WIP limit và cân bằng việc mới với nợ kỹ thuật

WIP limit (giới hạn việc đang làm) là công cụ mạnh nhất mà nhóm dữ liệu thường bỏ quên. Trực giác sai lầm phổ biến: nhận thêm việc = làm được nhiều hơn. Thực tế, mỗi task đang mở dở là một "chi phí chuyển ngữ cảnh" — chuyển giữa xây pipeline và trả lời ad-hoc khiến cả hai chậm và dễ lỗi. Giới hạn ví dụ "mỗi người tối đa 3 việc đang làm" ép đội hoàn thành trước khi bắt cái mới, kéo cycle time xuống và làm lộ điểm nghẽn (bottleneck) — thường là khâu review hoặc phụ thuộc dữ liệu.

Cân bằng việc mới với bảo trì và nợ kỹ thuật. Nợ kỹ thuật trong dữ liệu tích tụ âm thầm: pipeline chắp vá, bảng trùng lặp không ai dám xoá, logic biến đổi copy-paste khắp nơi. Nếu 100% năng lực đổ vào tính năng mới, một ngày nào đó đội mất nửa thời gian dập lỗi. Nguyên tắc thực dụng: dành sẵn một tỷ lệ năng lực cố định cho bảo trì/nợ kỹ thuật — ví dụ 20% mỗi sprint — như một khoản đầu tư bắt buộc, không phải phần dư thừa cắt được khi bận. Đặt WIP limit riêng cho làn nợ kỹ thuật để nó không bị việc "sáng bóng" hơn chèn ép hoàn toàn.

Cộng tác với stakeholder nghiệp vụ

Thất bại kinh điển của dự án dữ liệu không phải lỗi kỹ thuật, mà là "ném yêu cầu qua tường" (throw over the wall): nghiệp vụ viết một yêu cầu, quăng cho đội dữ liệu, biến mất, rồi ba tuần sau nhận về một báo cáo đúng như đã viết nhưng không phải điều họ cần. Nguyên nhân: yêu cầu ban đầu luôn mơ hồ, và chỉ khi thấy kết quả cụ thể người ta mới biết mình thực sự muốn gì.

Lời giải là mô hình phân tích lặp (iterative): giao sớm một bản nháp thô — dù chỉ là bảng số liệu chưa đẹp — cho stakeholder xem trong 2–3 ngày thay vì 3 tuần. Vòng phản hồi ngắn giúp bắt hiểu lầm khi chi phí sửa còn thấp. Kèm theo là quản lý kỳ vọng rõ ràng ngay từ đầu về độ trễ dữ liệu, độ chính xác, và những gì dữ liệu không thể trả lời.

Cộng tác thực chất với nghiệp vụ gồm ba việc:

• Thu thập yêu cầu chủ động: ngồi cùng nghiệp vụ hỏi vế "để làm gì", không chỉ nhận đơn đặt hàng. Vẽ phác kết quả mong muốn (mock-up) trước khi code.
• Ngôn ngữ chung: thống nhất định nghĩa nghiệp vụ ("khách hàng hoạt động" = giao dịch trong 90 ngày?) trước, tránh mỗi phòng hiểu một kiểu.
• Đóng vòng phản hồi: demo định kỳ, để nghiệp vụ chỉnh hướng giữa chừng.

Làm việc với nhiều nhóm. Trong ngân hàng, một sản phẩm dữ liệu thường chạm bốn phía: nguồn (IT Core Banking, hạ tầng CDC) cấp dữ liệu; nghiệp vụ đặt yêu cầu; Rủi ro/Tuân thủ ràng buộc dữ liệu nào được dùng, che dữ liệu cá nhân (PII) thế nào (privacy & compliance); và Ban điều hành cấp ưu tiên. Đội dữ liệu là điểm giao — vai trò không chỉ là kỹ thuật mà là điều phối phụ thuộc. Nhận diện sớm các phụ thuộc chặn (blocking dependency), đặc biệt từ nguồn và từ khâu phê duyệt tuân thủ, là kỹ năng sống còn.

Nghi thức Agile thích ứng và chống quá tải ad-hoc

Daily standup cho nhóm dữ liệu nên xoay quanh dòng chảy và điểm nghẽn, không phải báo cáo tiến độ hình thức. Ba câu hữu ích hơn "hôm qua tôi làm gì": việc nào đang kẹt và vì sao? phụ thuộc nào cần gỡ? có ad-hoc gấp nào cần điều tiết lại không? Retro nên soi cả quy trình lẫn nguồn gốc ad-hoc: nếu tháng nào cũng có mười yêu cầu trích cùng một loại danh sách, đó là tín hiệu cần tự động hoá hoặc làm self-service.

Chống quá tải ad-hoc là bài toán sinh tồn của nhóm dữ liệu ngân hàng. Hai đòn bẩy:

• SLA cho yêu cầu ad-hoc: phân hạng và cam kết thời gian phản hồi công khai. Ví dụ: khẩn (báo cáo NHNN, sự cố) xử lý trong ngày; thường 3–5 ngày làm việc; thấp đưa vào backlog. SLA vừa bảo vệ đội (không phải cái gì cũng "gấp"), vừa cho stakeholder kỳ vọng rõ. Kèm một kênh intake duy nhất (form/ticket) thay vì tin nhắn trực tiếp tứ phía.
• Self-service giảm tải: mọi ad-hoc lặp lại là ứng viên để "sản phẩm hoá". Cung cấp dashboard tham số hoá, bảng semantic layer, hay data mart để nghiệp vụ tự truy vấn phần lớn câu hỏi thường gặp, chỉ đẩy lên đội những câu thật sự mới. Đây là cách duy nhất để nhu cầu tăng tuyến tính mà đội không phải tăng người tuyến tính.

Use case thực tế

Bối cảnh. Nhóm Data Analytics của NCB (8 người) phục vụ 6 phòng ban. Trước cải tổ, đội chạy Scrum 2 tuần nhưng mỗi sprint hoàn thành đúng ~50% cam kết vì ad-hoc liên tục phá vỡ — trung bình 22 yêu cầu ad-hoc/tháng đến qua email, Zalo và gõ cửa trực tiếp, không ai đo được. Việc bảo trì pipeline bị dồn đến khi hỏng mới sửa.

Can thiệp (áp dụng đúng bài này).

1. Chuyển sang Scrumban: bảng Kanban với ba làn — Dự án, Vận hành, Ad-hoc — WIP limit 3 việc/người, giữ retro hai tuần một lần.
2. Lập một kênh intake duy nhất (ticket) và SLA ad-hoc: khẩn trong ngày, thường 4 ngày làm việc, thấp vào backlog. Cắt hoàn toàn đường "gõ cửa trực tiếp".
3. Ưu tiên backlog dự án bằng WSJF, rà soát mỗi thứ Hai với đại diện các phòng.
4. Dành cứng 20% năng lực cho nợ kỹ thuật, và biến 3 loại ad-hoc lặp nhiều nhất thành dashboard self-service tham số hoá.

Kết quả sau một quý (số minh hoạ). Ad-hoc "gấp" giảm từ 22 xuống 9/tháng do self-service hấp thụ phần lặp; tỷ lệ hoàn thành việc dự án theo kế hoạch tăng từ ~50% lên ~80%; cycle time trung bình một yêu cầu ad-hoc giảm từ 9 ngày xuống 4 ngày; và lần đầu tiên đội có số liệu để nói với Ban điều hành rằng cần thêm người ở đâu, thay vì chỉ kêu "quá tải".

Một truy vấn minh hoạ kiểu ad-hoc lặp lại được đưa vào self-service — thống kê phân bố số dư theo loại tiền, đúng loại câu hỏi nghiệp vụ tự trả lời được thay vì gửi đội:

-- ▶ Chạy được
SELECT currency,
       COUNT(*)        AS so_tai_khoan,
       SUM(balance)    AS tong_du,
       ROUND(AVG(balance), 2) AS du_binh_quan
FROM accounts
GROUP BY currency
ORDER BY tong_du DESC;

Ghi nhớ

• Công việc dữ liệu khác phần mềm ở bất định khám phá, phụ thuộc nguồn, yêu cầu mơ hồ và ad-hoc xen kẽ — Agile phải điều chỉnh, đừng áp cứng.
• Kanban/Scrumban thường hợp hơn Scrum thuần vì luồng liên tục và nhiều ad-hoc; chọn Scrum thuần chỉ khi việc dự đoán được và ít gián đoạn.
• Tách dự án / vận hành / ad-hoc thành các làn riêng; ưu tiên minh bạch qua Value–Effort hoặc WSJF trên một backlog chung, một kênh intake.
• User story analytics xoay quanh quyết định ("Là… tôi cần… để…"); vế "để" định ra yêu cầu chất lượng thật.
• DoD sản phẩm dữ liệu = đã test + đối chiếu nguồn + có tài liệu/catalog + deploy qua Git-CI/CD + có giám sát.
• Dùng spike time-boxed và ước lượng theo dải cho việc khám phá; tách việc đã hiểu khỏi việc chưa hiểu.
• WIP limit giảm chuyển ngữ cảnh và lộ điểm nghẽn; dành cứng ~20% năng lực cho nợ kỹ thuật.
• Cộng tác nghiệp vụ theo vòng lặp ngắn, tránh "ném yêu cầu qua tường"; đội dữ liệu là điểm điều phối phụ thuộc giữa nguồn, nghiệp vụ và Rủi ro/Tuân thủ.
• Chống quá tải bằng SLA ad-hoc công khai và self-service để nhu cầu tăng mà không phải tăng người tương ứng.