Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa bàn giao một dự án phần mềm trị giá vài tỷ đồng. Đội phát triển nói "xong rồi". Khách hàng nói "chưa đạt". Và cả hai bên đều... đúng theo cách hiểu của riêng mình. Đây chính là cơn ác mộng kinh điển trong nghề Phân tích nghiệp vụ (Business Analysis), và nó xảy ra khi không ai định nghĩa rõ ràng thế nào là "đạt".
Bài 50 này nói về hai khái niệm mà IIBA xem là một technique riêng trong BABOK Guide v3: Acceptance Criteria (tiêu chí chấp nhận) và Evaluation Criteria (tiêu chí đánh giá). Đây là technique được hỏi khá thường xuyên trong kỳ thi ECBA, vì nó nằm ở giao điểm của nhiều Knowledge Area: nó được dùng trong Requirements Analysis and Design Definition (KA5) để xác nhận yêu cầu, và trong Solution Evaluation (KA6) để đánh giá giải pháp. Nắm vững technique này không chỉ giúp bạn trả lời đúng câu hỏi thi, mà còn cứu bạn khỏi những cuộc tranh cãi "đạt hay không đạt" ngoài đời thực.
Điều quan trọng cần phân biệt ngay từ đầu: Acceptance Criteria mang tính nhị phân (binary) — pass hoặc fail, không có vùng xám. Còn Evaluation Criteria mang tính so sánh, đo lường theo thang đo — cho phép xếp hạng nhiều lựa chọn. Đừng nhầm lẫn hai cái này, vì đề thi ECBA rất thích đánh lừa ở chính điểm phân biệt đó.
Khái niệm cốt lõi
Acceptance Criteria (Tiêu chí chấp nhận)
Theo BABOK Guide v3, Acceptance Criteria là tập hợp các điều kiện tối thiểu mà một giải pháp (solution) hoặc thành phần giải pháp phải đáp ứng để được các bên liên quan chấp nhận. Đặc điểm cốt lõi của nó:
- Tính nhị phân: kết quả chỉ là pass/fail. Một acceptance criterion hoặc được thỏa mãn, hoặc không. Ví dụ: "Người dùng phải đăng nhập được trong vòng 3 giây" — hệ thống hoặc đáp ứng (3 giây trở xuống), hoặc không.
- Thể hiện mức tối thiểu chấp nhận được: đây là ngưỡng phải vượt qua, không phải mục tiêu lý tưởng. Nếu không đạt, giải pháp bị từ chối.
- Thường gắn với một yêu cầu cụ thể: mỗi requirement quan trọng nên có acceptance criteria đi kèm.
Khi nào định nghĩa Acceptance Criteria?
Acceptance Criteria thường được định nghĩa trong KA5 — Requirements Analysis and Design Definition, cụ thể ở task "Specify and Model Requirements". Tuy nhiên chúng được sử dụng xuyên suốt vòng đời: trong contractual situations (tình huống hợp đồng), chúng trở thành căn cứ pháp lý để nghiệm thu; trong môi trường Agile, chúng đi kèm mỗi User Story để Định nghĩa "Done".
Một điểm BABOK nhấn mạnh mà thí sinh hay quên: trong các tình huống có ràng buộc hợp đồng hoặc tuân thủ pháp lý (compliance), acceptance criteria là bắt buộc vì chúng là cơ sở để xác định bên cung cấp đã hoàn thành nghĩa vụ hay chưa.
Evaluation Criteria (Tiêu chí đánh giá)
Evaluation Criteria là tập hợp các tiêu chí dùng để lựa chọn giữa nhiều giải pháp khả thi. Khác biệt then chốt so với Acceptance Criteria:
- Tính so sánh, có thang đo: thay vì pass/fail, chúng cho phép cho điểm (ví dụ thang 1–10), gán trọng số (weighting), rồi xếp hạng các phương án.
- Dùng để ra quyết định lựa chọn: ví dụ khi so sánh ba nhà cung cấp phần mềm ERP, ta dùng evaluation criteria để chấm điểm và chọn ra phương án tốt nhất.
- Thường xuất hiện trong KA4 — Strategy Analysis (khi đánh giá các change strategy) và KA6 — Solution Evaluation (khi đo lường hiệu năng giải pháp).
So sánh nhanh để khỏi nhầm
| Khía cạnh | Acceptance Criteria | Evaluation Criteria |
|---|---|---|
| Bản chất | Nhị phân — pass/fail | So sánh — cho điểm, xếp hạng |
| Mục đích | Quyết định chấp nhận/từ chối một giải pháp | Lựa chọn giữa nhiều giải pháp |
| Ngữ cảnh điển hình | Nghiệm thu, hợp đồng, Agile "Done" | RFP, so sánh phương án, đánh giá hiệu năng |
| KA liên quan chính | KA5 (định nghĩa), KA6 (sử dụng) | KA4, KA6 |
Cách viết Acceptance Criteria tốt
Trong môi trường Agile, format phổ biến nhất là Given-When-Then (mượn từ kỹ thuật Behaviour-Driven Development):
- Given (cho trước một bối cảnh) — ví dụ: "Cho trước người dùng đã đăng nhập và có hàng trong giỏ"
- When (khi một hành động xảy ra) — "Khi người dùng nhấn nút Thanh toán"
- Then (thì kết quả mong đợi) — "Thì hệ thống hiển thị màn hình chọn phương thức thanh toán trong vòng 2 giây"
Tình huống thực tế
Tình huống 1: App đặt đồ ăn của một startup F&B tại TP.HCM
Một startup giao đồ ăn (gọi là FoodNow) thuê đội outsource xây dựng tính năng "Đặt món theo combo". Ban đầu BRD chỉ ghi: "Khách hàng có thể đặt combo và thanh toán nhanh." Đội phát triển làm xong, nhưng khi nghiệm thu thì tranh cãi nổ ra: khách bảo "nhanh" phải dưới 5 giây, đội dev hiểu "nhanh" nghĩa là "ít bước thao tác".
Sau bài học đó, BA của FoodNow viết lại acceptance criteria rõ ràng cho từng yêu cầu:
- "Cho trước giỏ hàng có ít nhất một combo, khi khách nhấn Đặt hàng, thì đơn được tạo và xác nhận hiển thị trong vòng 3 giây với 95% số lần thử."
- "Khách phải hoàn tất thanh toán qua MoMo, ZaloPay hoặc thẻ nội địa Napas mà không cần nhập lại thông tin quá một lần."
Bài học rút ra: Từ ngữ định tính như "nhanh", "dễ dùng", "ổn định" là kẻ thù của acceptance criteria. Hãy luôn dịch chúng thành con số và điều kiện có thể kiểm chứng.
Tình huống 2: Ngân hàng số chọn nhà cung cấp eKYC
Một ngân hàng tại Việt Nam (gọi là VietDigi Bank) cần chọn nhà cung cấp giải pháp định danh điện tử eKYC từ ba ứng viên: nhà cung cấp A, B và C. Đây là tình huống điển hình cần Evaluation Criteria, không phải acceptance criteria, vì mục tiêu là chọn ra phương án tốt nhất chứ không phải chấp nhận/từ chối từng cái.
BA xây dựng bảng evaluation criteria có trọng số:
- Độ chính xác nhận diện khuôn mặt (trọng số 30%)
- Tốc độ xử lý (trọng số 15%)
- Chi phí trên mỗi lượt xác thực (trọng số 25%)
- Khả năng tuân thủ quy định của Ngân hàng Nhà nước (trọng số 20%)
- Chất lượng hỗ trợ kỹ thuật tại Việt Nam (trọng số 10%)
Diễn giải: Lưu ý rằng tiêu chí "tuân thủ quy định Ngân hàng Nhà nước" thực ra mang tính bắt buộc — đáng lẽ nên tách thành một acceptance criterion (nhị phân: tuân thủ hay không). Một số tiêu chí là điều kiện cần (knock-out), số khác là điều kiện so sánh.
Bài học rút ra: Trong thực tế, ta thường kết hợp cả hai. Đầu tiên dùng acceptance criteria để loại các phương án không đạt ngưỡng bắt buộc (ví dụ: không tuân thủ pháp lý thì loại ngay), sau đó dùng evaluation criteria để xếp hạng những phương án còn lại.
Tình huống 3: Dự án nội bộ của một công ty bảo hiểm
Một công ty bảo hiểm ở Hà Nội triển khai hệ thống quản lý hợp đồng mới. Hợp đồng outsource ghi rõ điều khoản nghiệm thu dựa trên acceptance criteria. Một trong các tiêu chí là: "Hệ thống phải xử lý được ít nhất 10.000 hợp đồng đồng thời mà thời gian phản hồi không vượt quá 2 giây."
Khi nghiệm thu (User Acceptance Testing — UAT), đội kiểm thử mô phỏng 10.000 hợp đồng. Thời gian phản hồi đo được là 2,4 giây. Vì acceptance criteria là nhị phân, kết quả là FAIL — dù chỉ chậm hơn 0,4 giây. Nhà cung cấp buộc phải tối ưu lại trước khi được thanh toán đợt cuối.
Bài học rút ra: Chính vì acceptance criteria có tính ràng buộc hợp đồng, việc đặt ngưỡng phải được thương lượng cẩn thận giữa các bên ngay từ đầu. Đặt ngưỡng quá khắt khe gây rủi ro cho nhà cung cấp; đặt quá lỏng thì khách hàng nhận về sản phẩm kém. BA đóng vai trò trung gian giúp đặt ngưỡng hợp lý, đo lường được và công bằng.
Hướng dẫn từng bước
Dưới đây là quy trình thực hành để xây dựng Acceptance và Evaluation Criteria:
Bước 1 — Xác định mục đích: Bạn đang cần chấp nhận một giải pháp hay lựa chọn giữa nhiều giải pháp? Câu trả lời quyết định bạn dùng acceptance criteria (nhị phân) hay evaluation criteria (so sánh). Đây cũng là bước hay bị sai trong đề thi.
Bước 2 — Thu thập đầu vào: Lấy các requirements đã được xác nhận, các ràng buộc (constraints), kỳ vọng của stakeholder, và các quy định pháp lý liên quan. Đây là nguyên liệu để định nghĩa tiêu chí.
Bước 3 — Với Acceptance Criteria: Viết từng tiêu chí dưới dạng điều kiện nhị phân, đo lường được. Ưu tiên format Given-When-Then trong môi trường Agile. Mỗi tiêu chí phải trả lời được câu hỏi: "Làm sao để biết tiêu chí này đạt hay không?"
Bước 4 — Với Evaluation Criteria: Liệt kê các tiêu chí so sánh, gán trọng số phản ánh tầm quan trọng, định nghĩa thang điểm. Đảm bảo tổng trọng số bằng 100% để dễ tính toán.
Bước 5 — Xác nhận với stakeholder: Đưa các tiêu chí cho các bên liên quan duyệt. Đặc biệt trong tình huống hợp đồng, mọi ngưỡng phải được hai bên đồng thuận bằng văn bản.
Bước 6 — Áp dụng và đo lường: Dùng acceptance criteria trong UAT và verification/validation; dùng evaluation criteria để chấm điểm và ra quyết định lựa chọn.
Bước 7 — Cập nhật khi cần: Tiêu chí không bất biến. Khi requirements thay đổi, hãy cập nhật criteria tương ứng và quản lý qua quy trình kiểm soát thay đổi.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm acceptance với evaluation. Đây là cái bẫy số một trong đề ECBA. Nhớ: nếu câu hỏi nói đến pass/fail, chấp nhận/từ chối, nghiệm thu → acceptance criteria. Nếu nói đến so sánh, xếp hạng, chọn lựa giữa nhiều phương án → evaluation criteria.
Lỗi 2 — Viết tiêu chí mơ hồ. "Hệ thống phải nhanh và thân thiện" là vô dụng. Luôn hỏi: tiêu chí này có đo được không? có testable không? Nếu không, viết lại.
Lỗi 3 — Quên rằng acceptance criteria là tối thiểu, không phải lý tưởng. Acceptance criteria xác định ngưỡng phải đạt, không phải mục tiêu mơ ước. Đừng nhồi vào đó những kỳ vọng "có thì tốt".
Lỗi 4 — Bỏ qua tính ràng buộc hợp đồng. Trong tình huống contractual, acceptance criteria là cơ sở pháp lý. Đặt ngưỡng cẩu thả có thể gây thiệt hại tài chính hoặc tranh chấp.
Lỗi 5 — Không gán trọng số cho evaluation criteria. Nếu mọi tiêu chí được coi quan trọng như nhau, kết quả xếp hạng sẽ méo mó. Trọng số phản ánh ưu tiên thực tế của doanh nghiệp.
Mẹo thi ECBA: Khi gặp câu hỏi về technique này, hãy đọc kỹ động từ trong đề. "Determine whether to accept" → acceptance. "Compare and select" hay "rank" → evaluation. Ngoài ra, nhớ rằng acceptance criteria thường được định nghĩa trong KA5 (Specify and Model Requirements) nhưng được dùng để xác nhận trong KA6.
Mẹo thực hành: Trong Agile, mỗi User Story nên có acceptance criteria viết sẵn trước khi sprint bắt đầu. Đây là một phần của "Definition of Done" và giúp đội dev biết chính xác khi nào câu chuyện được xem là hoàn thành.
Bài tập thực hành
Bài 1 — Phân loại. Với mỗi tình huống dưới đây, xác định nên dùng Acceptance Criteria hay Evaluation Criteria:
- (a) Quyết định xem phiên bản app mới có được phát hành lên App Store không.
- (b) Chọn một trong bốn nền tảng CRM cho phòng kinh doanh.
- (c) Nghiệm thu module tính lương theo hợp đồng outsource.
- (d) So sánh ba phương án migration dữ liệu để chọn cái rủi ro thấp nhất.
Bài 3 — Xây bảng evaluation. Bạn cần chọn nhà cung cấp dịch vụ SMS OTP cho một ví điện tử. Hãy đề xuất ít nhất 4 evaluation criteria kèm trọng số (tổng 100%), và giải thích vì sao bạn gán trọng số như vậy.
Bài 4 — Phân tích lỗi. Tiêu chí sau đây sai ở đâu và sửa lại thế nào: "Hệ thống phải có giao diện đẹp và load trang đủ nhanh để người dùng hài lòng."
Tóm tắt
- Acceptance Criteria là tập điều kiện tối thiểu để một giải pháp được chấp nhận; bản chất nhị phân (pass/fail), không có vùng xám. Thường định nghĩa trong KA5, và đặc biệt quan trọng trong tình huống hợp đồng và Agile (Definition of Done).
- Evaluation Criteria là tập tiêu chí so sánh, có thang đo và trọng số, dùng để lựa chọn giữa nhiều giải pháp khả thi. Thường xuất hiện trong KA4 (Strategy Analysis) và KA6 (Solution Evaluation).
- Đừng nhầm hai khái niệm: acceptance là "cánh cửa vào được hay không", evaluation là "bảng xếp hạng ai hơn ai".
- Tiêu chí tốt phải rõ ràng, đo lường được, không mơ hồ, testable. Tránh từ ngữ định tính như "nhanh", "đẹp", "dễ dùng".
- Trong thực tế thường kết hợp cả hai: dùng acceptance criteria để loại phương án không đạt ngưỡng bắt buộc, rồi dùng evaluation criteria để xếp hạng phần còn lại.
- Mẹo thi: đọc động từ trong đề — "accept/reject" → acceptance; "compare/select/rank" → evaluation.