Mở đầu — vì sao bài này quan trọng
Trong suốt khóa học, bạn đã được học Waterfall BA và Agile BA như hai thế giới tách biệt: một bên kế hoạch chặt chẽ, ký BRD trước khi code; một bên linh hoạt, ưu tiên backlog và refine liên tục. Nhưng khi bước vào thực tế ở Việt Nam — đặc biệt là ngân hàng, bảo hiểm, y tế, fintech — bạn sẽ nhanh chóng nhận ra một sự thật khó chịu: không dự án nào thuần Agile hay thuần Waterfall cả. Lý do rất đơn giản. Một dự án mở tài khoản online tại ngân hàng vừa phải chạy nhanh để cạnh tranh trải nghiệm (UI/UX, onboarding), vừa phải đảm bảo tuân thủ Thông tư của Ngân hàng Nhà nước về eKYC, AML, lưu trữ chứng từ — những thứ không cho phép "ship trước, sửa sau".
Đây chính là lý do hybrid approach ra đời: kết hợp Waterfall cho phần cần kiểm soát chặt và tuân thủ pháp lý, với Agile cho phần cần thích nghi và tối ưu liên tục. Là BA trong môi trường regulatory, nếu bạn cứng nhắc áp một mô hình duy nhất, bạn sẽ hoặc làm chậm cả dự án (Waterfall hóa phần UX), hoặc tạo rủi ro pháp lý nghiêm trọng (Agile hóa phần compliance). Bài này dạy bạn cách phân loại đâu là phần nào, thiết kế quy trình lai phù hợp, và quan trọng nhất: cách quản lý requirement ở ranh giới giữa hai thế giới — nơi 80% xung đột thực tế xảy ra.
Lưu ý phạm vi: bài này tập trung vào kiến trúc quy trình hybrid cho dự án regulatory, không lặp lại chi tiết về vai trò Agile BA vs Waterfall BA (đã có ở Bài 35) hay viết user story (Bài 36). Ở đây ta nói về cách ghép hai mô hình lại với nhau.
Khái niệm cốt lõi
Hybrid không phải là "nửa nạc nửa mỡ"
Sai lầm phổ biến nhất là nghĩ hybrid nghĩa là "làm Agile nhưng vẫn viết tài liệu nhiều". Không. Hybrid đúng nghĩa là một quyết định kiến trúc quy trình có chủ đích: bạn chia dự án thành các khối (workstream), mỗi khối được vận hành theo mô hình phù hợp với bản chất của nó, rồi định nghĩa rõ điểm giao tiếp giữa chúng.
Có ba cách lai phổ biến mà BA cần phân biệt:
- Hybrid theo pha (sequential hybrid): Pha đầu chạy Waterfall — phân tích, thiết kế kiến trúc, ký các tài liệu compliance, chốt phạm vi pháp lý. Sau đó pha xây dựng chạy Agile theo sprint. Hay gặp ở dự án core banking, nơi kiến trúc và compliance phải khóa trước.
- Hybrid song song (parallel hybrid): Cùng một thời điểm, workstream compliance chạy Waterfall (có cột mốc kiểm toán, ký duyệt), còn workstream sản phẩm/UX chạy Agile (sprint 2 tuần, demo liên tục). Hai luồng đồng bộ tại các milestone chung. Đây là dạng phổ biến nhất trong fintech VN.
- Hybrid theo lớp (layered hybrid): Phân theo tầng kiến trúc — backend/lõi nghiệp vụ và tích hợp với hệ thống pháp lý chạy Waterfall vì cần ổn định và đặc tả chặt; tầng frontend/trải nghiệm chạy Agile vì cần thử nghiệm và điều chỉnh nhanh.
Tiêu chí quyết định: phần nào Waterfall, phần nào Agile
Đây là kỹ năng cốt lõi của bài. Với mỗi nhóm requirement, BA tự hỏi bốn câu:
- Chi phí của việc sai có thể đảo ngược được không? Nếu sai một tính năng giao diện, ta sửa ở sprint sau — chi phí thấp, đảo ngược được → Agile. Nếu sai cách lưu trữ chứng từ giao dịch theo quy định, ta có thể bị phạt và phải khắc phục hồi tố — chi phí cao, khó đảo ngược → Waterfall.
- Requirement có bị ràng buộc bởi văn bản pháp lý cố định không? Thông tư, nghị định, chuẩn ISO/PCI-DSS thường không thay đổi theo sprint. Những gì neo vào văn bản pháp lý → đặc tả trước, ký duyệt, kiểm soát thay đổi nghiêm (Waterfall).
- Có cần audit trail và bằng chứng phê duyệt không? Nếu kiểm toán viên hoặc cơ quan quản lý sẽ hỏi "ai duyệt cái này, khi nào" → cần tài liệu ký chính thức → Waterfall.
- Mức độ chắc chắn về yêu cầu cao hay thấp? Yêu cầu mơ hồ, cần học từ người dùng → Agile để khám phá dần. Yêu cầu đã rõ ràng và bất biến → Waterfall.
Điểm giao tiếp — nơi BA tạo ra giá trị lớn nhất
Phần khó nhất của hybrid không nằm trong từng luồng, mà ở ranh giới giữa hai luồng. Khi đội Agile muốn thay đổi luồng onboarding, thay đổi đó có chạm vào yêu cầu eKYC đã ký Waterfall không? BA phải đóng vai trò "người gác cổng": mọi thay đổi ở luồng Agile chạm tới ràng buộc compliance đều phải đi qua một cơ chế kiểm soát thay đổi nhẹ nhưng có thật. Đây là lý do Requirements Traceability (đã học ở Bài 32) trở nên sống còn trong hybrid — nó là sợi dây nối requirement Agile với ràng buộc pháp lý Waterfall.
Tình huống thực tế
Ví dụ 1 — Ngân hàng số tại VN triển khai mở tài khoản eKYC
Một ngân hàng thương mại cổ phần tại TP.HCM (giả định, gọi là Bank A) triển khai tính năng mở tài khoản online hoàn toàn. Họ đặt mục tiêu ra mắt trong 5 tháng. Ban đầu, đội sản phẩm muốn làm thuần Agile để demo nhanh cho ban lãnh đạo. Nhưng BA trưởng nhận ra: phần eKYC phải tuân thủ Thông tư của NHNN về định danh điện tử — yêu cầu so khớp khuôn mặt, kiểm tra giấy tờ, lưu trữ video định danh, và đặc biệt là các ngưỡng hạn mức giao dịch khác nhau tùy mức độ xác thực.
Họ chọn parallel hybrid. Workstream A (compliance eKYC) chạy Waterfall: BA viết SRS đặc tả đầy đủ luồng định danh, các ngưỡng hạn mức, quy tắc lưu trữ, rồi trình pháp chế và đại diện NHNN duyệt trước khi code. Workstream B (trải nghiệm onboarding: chụp ảnh, hướng dẫn, màn hình chờ) chạy Agile theo sprint 2 tuần, A/B test liên tục tỷ lệ hoàn tất.
Kết quả: nhóm UX tăng tỷ lệ hoàn tất onboarding từ 58% lên 79% qua 6 sprint nhờ thử nghiệm nhanh, trong khi nhóm compliance không phải làm lại lần nào khi kiểm toán nội bộ. Điểm mấu chốt: BA đã đặt một "cổng kiểm soát" — bất kỳ thay đổi UX nào động đến luồng định danh (ví dụ bỏ bớt một bước chụp ảnh) đều phải qua impact analysis với SRS đã ký.
Bài học: Đừng để tốc độ của luồng UX kéo theo việc cắt xén bước pháp lý. Tách luồng và đặt cổng kiểm soát ở ranh giới chính là nghệ thuật hybrid.
Ví dụ 2 — Insurtech triển khai bồi thường sức khỏe số
Một công ty insurtech khu vực Đông Nam Á (giả định, gọi là HealthSure) làm sản phẩm yêu cầu bồi thường bảo hiểm sức khỏe trực tuyến. Phần tính toán quyền lợi, điều khoản loại trừ, và quy trình giám định phải khớp tuyệt đối với hợp đồng bảo hiểm đã được Bộ Tài chính/cơ quan quản lý phê duyệt — sai một điều khoản loại trừ có thể dẫn tới chi trả sai hàng tỷ đồng hoặc khiếu kiện.
Đội chọn layered hybrid. Tầng "rule engine" tính quyền lợi và áp điều khoản chạy Waterfall: mọi quy tắc được đặc tả trong một bảng decision table, đối chiếu từng dòng với hợp đồng, ký duyệt bởi actuary và pháp chế. Tầng "trải nghiệm nộp hồ sơ" (chụp hóa đơn, OCR, theo dõi trạng thái) chạy Agile.
Một tình huống điển hình xảy ra ở sprint 4: đội Agile muốn thêm tính năng cho phép người dùng tự ước tính số tiền được bồi thường trước khi nộp. Nghe đơn giản, nhưng tính năng này cần gọi vào rule engine — phần Waterfall. BA xử lý bằng cách: rule engine phơi ra một API "ước tính" được kiểm soát phiên bản chặt; đội Agile chỉ tiêu thụ API, không tự tính lại logic. Nhờ vậy, logic pháp lý vẫn nằm trong vùng kiểm soát, còn trải nghiệm vẫn linh hoạt.
Bài học: Khi luồng Agile cần dùng logic của luồng Waterfall, đừng để hai bên cùng viết logic. Đóng gói phần pháp lý thành dịch vụ/API có versioning, để đội linh hoạt chỉ "gọi" chứ không "diễn giải lại".
Ví dụ 3 — Khi chọn sai mô hình: dự án thanh toán nội bộ
Một ví dụ thất bại để bạn tránh. Một ví điện tử tại VN (giả định) làm tính năng đối soát giao dịch với ngân hàng đối tác. Đội quyết định làm thuần Agile vì "team quen Scrum rồi". Họ không đặc tả trước quy tắc đối soát và lưu trữ log giao dịch theo chuẩn của đối tác ngân hàng. Sau 3 sprint, khi tích hợp thật, họ phát hiện định dạng file đối soát và yêu cầu lưu trữ 10 năm của ngân hàng buộc phải thay đổi cấu trúc dữ liệu lõi — phải làm lại gần như toàn bộ, trễ 6 tuần.
Vấn đề không phải Agile dở, mà là họ Agile hóa nhầm phần đáng lẽ phải Waterfall: phần có ràng buộc pháp lý cứng, định dạng cố định, yêu cầu lưu trữ dài hạn — đáng lẽ phải đặc tả và chốt trước.
Bài học: Hybrid không phải mặc định Agile rồi vá chỗ nào cần. Phải phân loại workstream NGAY TỪ ĐẦU bằng bốn câu hỏi ở trên.
Hướng dẫn từng bước
Đây là quy trình bạn có thể áp dụng khi nhận một dự án regulatory cần hybrid:
- Lập bản đồ ràng buộc pháp lý (regulatory map). Liệt kê mọi văn bản, chuẩn, hợp đồng chi phối dự án (Thông tư NHNN, nghị định bảo vệ dữ liệu cá nhân, PCI-DSS, hợp đồng đối tác...). Với mỗi cái, ghi rõ nó ràng buộc requirement nào.
- Phân loại workstream. Dùng bốn câu hỏi quyết định để chia requirement thành nhóm Plan-driven (Waterfall) và Change-driven (Agile). Lập bảng phân loại, cho stakeholder chủ chốt duyệt — đây là thỏa thuận nền tảng.
- Chọn dạng hybrid. Dựa trên mức độ phụ thuộc giữa hai nhóm: phụ thuộc tuần tự → sequential; chạy đồng thời → parallel; phân theo tầng kiến trúc → layered.
- Định nghĩa điểm đồng bộ và cổng kiểm soát. Xác định các milestone chung nơi hai luồng phải gặp nhau, và quy tắc: thay đổi nào ở luồng Agile phải qua impact analysis với tài liệu Waterfall đã ký.
- Thiết lập traceability xuyên ranh giới. Mỗi requirement Agile chạm compliance phải có liên kết tới điều khoản pháp lý tương ứng trong RTM. Khi luật thay đổi, bạn truy ngược được mọi tính năng bị ảnh hưởng.
- Thiết kế cadence tài liệu khác nhau. Luồng Waterfall: tài liệu ký chính thức, kiểm soát phiên bản nghiêm. Luồng Agile: tài liệu nhẹ (user story, acceptance criteria), nhưng vẫn đủ dấu vết để kiểm toán.
- Thống nhất Definition of Done có yếu tố compliance. Với story nào chạm vùng pháp lý, DoD phải gồm bước xác nhận tuân thủ — không chỉ "code chạy được".
- Vận hành và rà soát ranh giới định kỳ. Mỗi vài sprint, BA rà lại xem có thay đổi nào ở luồng Agile âm thầm vi phạm ràng buộc Waterfall không.
Lỗi thường gặp & mẹo
Lỗi 1 — Mặc định một mô hình rồi mới vá. Nhiều team chọn Agile vì quen tay, rồi gặp compliance mới chữa cháy. Hãy phân loại trước, chọn mô hình sau.
Lỗi 2 — Coi compliance là "việc của pháp chế, không phải của BA". Sai. BA là người dịch ràng buộc pháp lý thành requirement và giữ traceability. Nếu bạn buông phần này, không ai nối được luật với tính năng.
Lỗi 3 — Cổng kiểm soát quá nặng, biến Agile thành Waterfall trá hình. Đừng bắt mọi story đều phải ký duyệt pháp chế. Chỉ những story chạm vùng ràng buộc mới đi qua cổng. Phần còn lại để đội linh hoạt chạy tự do.
Lỗi 4 — Hai luồng dùng hai "ngôn ngữ" requirement khác nhau mà không có cầu nối. Waterfall nói "điều khoản 3.2.1", Agile nói "as a user, I want...". BA phải có RTM làm cầu nối, nếu không ranh giới sẽ vỡ.
Mẹo 1: Đóng gói logic pháp lý thành service/API có versioning (như ví dụ HealthSure) để đội Agile tiêu thụ mà không diễn giải lại — đây là cách giảm rủi ro hiệu quả nhất.
Mẹo 2: Dùng "compliance checklist" gắn vào Definition of Ready và Definition of Done cho các story vùng biên, để compliance được kiểm tra tự nhiên trong nhịp Agile thay vì kiểm tra dồn cuối dự án.
Mẹo 3: Khi văn bản pháp lý có khả năng thay đổi (ví dụ NHNN đang dự thảo thông tư mới), hãy đánh dấu requirement đó là "regulatory-volatile" và thiết kế kiến trúc cho phép thay đổi rule mà không phá vỡ hệ thống — đặt rule vào config/decision table thay vì hardcode.
Bài tập thực hành
Bài 1 — Phân loại workstream. Cho dự án "BNPL — Mua trước trả sau" cho một sàn thương mại điện tử VN. Hãy liệt kê ít nhất 8 nhóm requirement (ví dụ: chấm điểm tín dụng, giao diện chọn kỳ hạn, tích hợp CIC, lưu trữ hợp đồng điện tử, nhắc nợ, trải nghiệm thanh toán...). Với mỗi nhóm, dùng bốn câu hỏi quyết định để gán nhãn Waterfall hay Agile, kèm lý do một dòng.
Bài 2 — Thiết kế cổng kiểm soát. Với dự án ở Bài 1, viết một quy tắc kiểm soát thay đổi: loại thay đổi nào ở luồng Agile bắt buộc phải qua impact analysis với tài liệu Waterfall đã ký? Cho 2 ví dụ thay đổi phải qua cổng và 2 ví dụ không cần.
Bài 3 — Truy vết xuyên ranh giới. Giả sử CIC (Trung tâm Thông tin Tín dụng) thay đổi quy tắc cung cấp dữ liệu. Mô tả cách bạn dùng RTM để xác định trong vòng một giờ tất cả tính năng (cả Waterfall lẫn Agile) bị ảnh hưởng. Liệt kê các cột tối thiểu mà RTM của bạn cần có.
Tóm tắt
Hybrid approach không phải sự thỏa hiệp nửa vời, mà là một quyết định kiến trúc quy trình có chủ đích cho các dự án regulatory — nơi vừa cần Agile để thích nghi (UI/UX, sản phẩm) vừa cần Waterfall để tuân thủ (compliance, pháp lý, audit). Là BA, công việc cốt lõi của bạn gồm ba phần: (1) phân loại workstream ngay từ đầu bằng bốn câu hỏi về khả năng đảo ngược, ràng buộc pháp lý, audit trail và độ chắc chắn; (2) chọn đúng dạng hybrid — tuần tự, song song hay theo tầng; và (3) quản lý ranh giới giữa hai luồng bằng cổng kiểm soát có chọn lọc và traceability xuyên suốt. Ba ví dụ — ngân hàng eKYC, insurtech bồi thường, và ví điện tử đối soát — cho thấy cùng một nguyên tắc: tách phần cứng (pháp lý) khỏi phần mềm (trải nghiệm), đóng gói logic pháp lý thành dịch vụ có kiểm soát, và đừng bao giờ để tốc độ của luồng linh hoạt làm xói mòn ràng buộc tuân thủ. Nắm vững điều này, bạn trở thành BA mà mọi dự án ngân hàng, bảo hiểm, fintech ở Việt Nam đều cần.