Agile Deliberation: bài học làm rõ vùng xám trong yêu cầu
Google Research đề xuất Agile Deliberation để tinh chỉnh các khái niệm chủ quan cho bộ phân loại hình ảnh. Với BA và PO, đây là gợi ý hữu ích để đưa ca biên, ngoại lệ và các quyết định còn mở vào quá trình làm rõ yêu cầu.
Một yêu cầu như “chỉ xử lý trường hợp hợp lệ” nghe có vẻ rõ ràng — cho đến khi đội dự án gặp một trường hợp gần đúng.
“Đủ điều kiện” là đủ giấy tờ, dữ liệu khớp, hay còn bao gồm các ngoại lệ? Khi những ranh giới này chưa được nói rõ, chúng thường chỉ lộ ra ở UAT hoặc khi vận hành thực tế.
Google Research gọi cách tiếp cận để làm rõ các vùng xám như vậy là Agile Deliberation. Nghiên cứu tập trung vào việc xây dựng bộ phân loại hình ảnh cho các khái niệm chủ quan, nhưng cách tổ chức quá trình suy nghĩ của họ cũng gợi ý một bài học hữu ích cho BA và PO: đừng cố chốt mọi định nghĩa ngay từ đầu; hãy chủ động đưa các ca biên ra để stakeholder cùng quyết định.
Khi định nghĩa thay đổi lúc nhìn vào ví dụ thật
Các mô hình học máy thường dựa vào dữ liệu do con người gắn nhãn. Cách làm này thuận lợi với những đối tượng có ranh giới rõ, chẳng hạn biển báo dừng hoặc chó Golden Retriever.
Nhưng nhiều khái niệm trong thực tế mang tính chủ quan và phụ thuộc bối cảnh. Google Research nêu các ví dụ như “thực phẩm lành mạnh”, “tác phẩm truyền cảm hứng” hoặc những khái niệm liên quan đến kiểm duyệt nội dung.
Với các khái niệm này, con người không phải lúc nào cũng có một định nghĩa hoàn chỉnh ngay từ đầu. Họ có thể chỉ nhận ra ngoại lệ, giới hạn và sắc thái của khái niệm khi đối diện với ví dụ cụ thể.
Agile Deliberation coi việc xây dựng bộ phân loại là một quá trình trao đổi lặp lại giữa người dùng và hệ thống AI, thay vì yêu cầu người dùng đóng vai trò người gắn nhãn với các quy tắc cố định từ đầu.
Hai giai đoạn: khoanh vùng và lặp qua ca biên
Khung Agile Deliberation gồm hai giai đoạn: concept scoping và concept iteration.
1. Concept scoping: khoanh vùng khái niệm
Ở bước đầu, một khái niệm rộng được tách thành các nhóm cụ thể hơn, gồm:
Những trường hợp thuộc phạm vi mà bộ phân loại cần nhận diện.
Những trường hợp ngoài phạm vi mà hệ thống không nên gắn nhãn.
Ví dụ với “thực phẩm lành mạnh”, nghiên cứu minh họa các nhóm tích cực như salad, món ngũ cốc và protein nạc; đồng thời nêu các loại trừ như thực phẩm chế biến hoặc nguyên liệu thô chưa chế biến.
Với BA và PO, tư duy tương tự có thể được dùng khi làm rõ một thuật ngữ nghiệp vụ. Thay vì chỉ ghi một nhãn rộng, nhóm có thể tách rõ:
Điều kiện thuộc phạm vi.
Điều kiện loại trừ.
Những ca chưa đủ rõ để quyết định.
Danh sách thứ ba không đồng nghĩa với requirement kém chất lượng. Đây là phần việc cần được làm rõ có chủ đích.
2. Concept iteration: lặp lại với các tình huống sát ranh giới
Sau khi có cấu trúc ban đầu, hệ thống tiếp tục đưa ra các hình ảnh mơ hồ về mặt ngữ nghĩa để người dùng đánh giá.
Nghiên cứu sử dụng mô hình thị giác-ngôn ngữ (vision-language model — VLM) để tìm những hình ảnh sát với ranh giới của định nghĩa hiện có. Chẳng hạn, một ly sinh tố trái cây có thể được xem là lành mạnh vì có trái cây tươi, nhưng cũng có thể bị loại nếu người dùng xem hàm lượng đường là yếu tố quyết định.
Phản hồi của người dùng được đưa vào vòng lặp tối ưu prompt để điều chỉnh ranh giới của bộ phân loại.
Khác với active learning truyền thống, cách tiếp cận này không chỉ tìm ví dụ khiến mô hình thiếu chắc chắn. Mục tiêu là đưa ra những ví dụ có thể khiến con người xem xét lại giả định ban đầu của mình.
Bài học cho BA và PO: biến ca biên thành nội dung workshop
Nghiên cứu không đánh giá công việc phân tích yêu cầu. Tuy vậy, nguyên tắc của Agile Deliberation có thể được xem là một phép so sánh hữu ích cho các buổi discovery hoặc refinement.
Thay vì chỉ hỏi stakeholder “định nghĩa này là gì?”, BA có thể tập trung đưa ra các tình huống gần ranh giới để yêu cầu quyết định nghiệp vụ. Ví dụ:
Trường hợp đáp ứng phần lớn điều kiện nhưng thiếu một thông tin quan trọng.
Hai nguồn dữ liệu đưa ra thông tin không nhất quán.
Có ngoại lệ được xử lý thủ công.
Chính sách thay đổi trong khi một hồ sơ hoặc giao dịch đang được xử lý.
Nhiều tín hiệu nhỏ xuất hiện đồng thời nhưng không có tín hiệu nào đủ mạnh khi xét riêng lẻ.
Vai trò của AI, nếu được sử dụng trong hoạt động phân tích, nên là hỗ trợ phát hiện câu hỏi và tình huống cần làm rõ. AI không thay thế Product Owner, bộ phận nghiệp vụ hay các bên có thẩm quyền trong việc chốt chính sách.
Từ vùng xám đến artefact phân tích
Một quy trình làm việc phù hợp với tinh thần của Agile Deliberation có thể gồm ba bước.
Khoanh vùng trước khi viết quy tắc chi tiết
Bắt đầu bằng việc ghi rõ:
Mục tiêu nghiệp vụ.
Nhóm trường hợp thuộc phạm vi.
Nhóm trường hợp ngoài phạm vi.
Các giả định đang được ngầm hiểu.
Những điểm cần chủ nghiệp vụ xác nhận.
Cách làm này giúp phân biệt giữa điều đã được quyết định và điều mới chỉ là diễn giải của đội dự án.
Đưa ca biên vào refinement
Thay vì chỉ rà happy path, hãy dùng các tình huống sát ranh giới để kiểm tra xem các stakeholder có cùng cách hiểu hay không.
Mỗi ca biên nên dẫn đến một trong ba kết quả:
Có quyết định nghiệp vụ rõ ràng.
Được ghi nhận là ngoại lệ cần xử lý.
Trở thành một câu hỏi còn mở, có người chịu trách nhiệm trả lời.
Chuyển quyết định đã xác nhận thành AC và luồng xử lý
Chỉ sau khi quyết định nghiệp vụ đã được xác nhận, nhóm mới nên chuyển chúng thành:
User story.
Acceptance criteria.
Luồng chính và luồng ngoại lệ trong BPMN.
Điểm cần xử lý thủ công.
Yêu cầu về lưu vết hoặc cấu hình, nếu có.
Một acceptance criterion không nên biến điều chưa được thống nhất thành một quy tắc có vẻ chắc chắn. Nếu tiêu chuẩn vẫn chưa được chốt, đó nên là một open point hoặc backlog item, không phải một giả định bị giấu trong AC.
Cách kiểm tra bản nháp do AI hỗ trợ tạo ra
Nếu dùng AI để hỗ trợ chuẩn bị workshop, tóm tắt ghi chú hoặc gợi ý ca kiểm thử, BA vẫn cần review đầu ra trước khi đưa vào Jira hoặc Confluence.
Bốn nhóm câu hỏi hữu ích là:
Thiếu gì? Có vai trò, ngoại lệ, nhánh lỗi, hủy, sửa hay xử lý thủ công nào chưa xuất hiện?
Mơ hồ ở đâu? Các từ như “hợp lệ”, “bất thường”, “kịp thời” hoặc “đủ rõ” đã gắn với quyết định cụ thể chưa?
Có mâu thuẫn không? Một điều kiện có vừa là lý do cho phép đi tiếp, vừa là lý do chặn ở phần khác không?
Có nội dung không có căn cứ không? Bản nháp có tự thêm ngưỡng, vai trò phê duyệt, quy định hoặc chính sách không?
Kết quả nghiên cứu nói gì?
Google Research đánh giá Agile Deliberation thông qua 18 phiên trực tiếp, mỗi phiên kéo dài 1,5 giờ, thay vì chỉ dựa vào tập dữ liệu đã gán nhãn sẵn.
Theo nhóm nghiên cứu, người tham gia sử dụng quy trình deliberation có mức độ nhất quán cao hơn theo thời gian. Nhóm cũng báo cáo rằng bộ phân loại tạo ra bằng cách tiếp cận này đạt kết quả tốt hơn các phương pháp so sánh trong các miền được thử nghiệm, đồng thời cải thiện trải nghiệm người dùng như giảm mệt mỏi và lo lắng.
Tuy nhiên, các kết quả này thuộc phạm vi nghiên cứu về bộ phân loại hình ảnh cho những khái niệm chủ quan. Chúng không phải bằng chứng trực tiếp rằng mọi quy trình phân tích yêu cầu sẽ đạt kết quả tương tự.
Checklist trước khi kết thúc refinement
[ ] Khái niệm đã có phần thuộc phạm vi và ngoài phạm vi.
[ ] Nhóm đã thảo luận các ca biên, không chỉ happy path.
[ ] Mỗi quyết định có người chịu trách nhiệm xác nhận.
[ ] Acceptance criteria phản ánh quyết định đã chốt, không phải suy đoán.
[ ] Luồng ngoại lệ và điểm xử lý thủ công đã được xem xét.
[ ] Các nội dung chưa chốt được ghi thành open question hoặc backlog item.
Điểm đáng học từ Agile Deliberation không phải là để AI định nghĩa đúng thay con người. Đó là đưa việc phát hiện vùng xám trở thành một phần có cấu trúc của quá trình làm rõ — trước khi vùng xám trở thành lỗi triển khai.