Mở đầu — vì sao bài này quan trọng
Khi còn làm Sales hoặc BD, bạn đã kể hàng trăm "câu chuyện": khách hàng gặp vấn đề gì, họ làm gì để giải quyết, kết quả ra sao. Một bản pitch giỏi luôn có nhân vật (khách hàng), mục tiêu (điều họ muốn đạt được), và một chuỗi hành động dẫn đến cái kết có hậu. Tin vui là: bạn vừa mô tả gần như chính xác cấu trúc của một use case theo phong cách Alistair Cockburn.
Use case là một trong những công cụ "đặc sản" của BA. Nó là cách bạn kể lại một câu chuyện tương tác giữa người dùng và hệ thống — nhưng kể một cách có kỷ luật, đủ chi tiết để dev code được, đủ rõ ràng để stakeholder ký duyệt, và đủ đầy đủ để tester viết test case. Trong toàn bộ khóa học, đây là bài duy nhất đào sâu vào template Cockburn — một định dạng kinh điển, được dùng rộng rãi trong các dự án enterprise, ngân hàng, bảo hiểm tại Việt Nam, nơi yêu cầu nghiệp vụ phức tạp và cần truy vết chặt chẽ.
Nhiều bạn ex-Sales nhầm use case với user story (bài 17 đã nói tới user story). Hai cái khác nhau về độ chi tiết và mục đích. User story ngắn gọn theo kiểu "Là khách hàng, tôi muốn... để...", dùng trong Agile để mở hội thoại. Use case Cockburn thì dài hơn, mô tả toàn bộ luồng từ đầu đến cuối, bao gồm cả những tình huống rẽ nhánh khi mọi thứ không suôn sẻ. Khi nghiệp vụ có nhiều bước, nhiều điều kiện, nhiều bên liên quan — như một quy trình duyệt vay hay một quy trình bồi thường bảo hiểm — use case là vũ khí phù hợp hơn. Bài này dạy bạn viết nó đúng chuẩn.
Khái niệm cốt lõi
Use case là gì theo Cockburn?
Alistair Cockburn, trong cuốn Writing Effective Use Cases (2000), định nghĩa use case là hợp đồng về hành vi giữa các bên liên quan (stakeholders) thông qua hệ thống. Một use case mô tả tất cả các cách mà một primary actor (tác nhân chính) có thể đạt được — hoặc không đạt được — một mục tiêu khi tương tác với hệ thống.
Điểm cốt lõi cần nhớ: use case không chỉ mô tả "đường đi đẹp" khi mọi thứ thành công, mà còn mô tả tất cả các ngả rẽ khi có lỗi, ngoại lệ, hoặc lựa chọn khác. Đây chính là điểm mạnh của ex-Sales: bạn vốn quen lường trước "khách sẽ phản đối thế nào" (objection handling). Trong use case, objection handling chính là extensions (luồng mở rộng).
Các thành phần của template Cockburn
Cockburn đề xuất một template "fully dressed" (đầy đủ) gồm các trường sau. Hãy xem đây như một biểu mẫu bạn điền vào:
- Use Case Name (Tên): Một động từ + danh từ, thể hiện mục tiêu. Ví dụ: "Nộp hồ sơ vay" (Submit Loan Application), không phải "Màn hình vay".
- Primary Actor (Tác nhân chính): Người/hệ thống khởi xướng use case để đạt mục tiêu. Ví dụ: Khách hàng.
- Stakeholders and Interests (Các bên liên quan và lợi ích): Ai quan tâm tới use case này và họ muốn gì. Đây là phần ex-Sales làm rất tốt vì bạn quen "map" các bên trong một deal.
- Preconditions (Điều kiện tiên quyết): Điều gì phải đúng trước khi use case bắt đầu. Ví dụ: Khách đã đăng nhập, đã được định danh eKYC.
- Success Guarantee / Postconditions (Cam kết thành công): Trạng thái hệ thống sau khi use case kết thúc thành công. Ví dụ: Hồ sơ vay được lưu với trạng thái "Chờ duyệt".
- Minimal Guarantee (Cam kết tối thiểu): Điều gì hệ thống vẫn đảm bảo ngay cả khi use case thất bại. Ví dụ: Dữ liệu khách nhập không bị mất.
- Trigger (Sự kiện kích hoạt): Cái gì bắt đầu use case. Ví dụ: Khách bấm "Đăng ký vay".
- Main Success Scenario (Kịch bản thành công chính): Chuỗi bước đánh số, mô tả luồng lý tưởng khi mọi thứ suôn sẻ.
- Extensions (Luồng mở rộng): Các nhánh rẽ khi có điều kiện khác, lỗi, ngoại lệ — gắn với số bước tương ứng.
Ba cấp độ mục tiêu (Goal Levels)
Cockburn nói mỗi use case có một "độ cao" (altitude). Đây là khái niệm rất hữu ích để bạn không lẫn lộn phạm vi:
- Cloud level (mây — quá cao): Mục tiêu chiến lược, ví dụ "Tăng trưởng dư nợ". Đây không phải use case viết được.
- Sea level (mặt biển — chuẩn nhất): Mục tiêu một người dùng hoàn thành trong một lần ngồi, ví dụ "Nộp hồ sơ vay". 90% use case bạn viết nên ở mức này.
- Fish level (cá — quá thấp): Sub-function, ví dụ "Xác thực OTP". Thường là một bước trong use case mức sea, không nên viết riêng trừ khi nó được dùng lại nhiều nơi.
Tình huống thực tế
Ví dụ 1: Use case "Nộp hồ sơ vay" tại một fintech cho vay tiêu dùng
Bối cảnh: Một công ty fintech cho vay tiêu dùng tại TP.HCM (tạm gọi là VayNhanh) đang xây app cho vay khoản 10–50 triệu đồng. Bạn — BA vừa từ team BD chuyển sang — được giao viết use case cho luồng khách hàng tự nộp hồ sơ. Đây là use case "fully dressed":
> Use Case: Nộp hồ sơ vay > Goal Level: Sea level (mặt biển) > Primary Actor: Khách hàng cá nhân > Stakeholders & Interests: > - Khách hàng: muốn nộp hồ sơ nhanh, biết kết quả sơ bộ ngay. > - Ngân hàng/quỹ tài trợ: muốn dữ liệu đầy đủ, đúng để chấm điểm tín dụng. > - Bộ phận thẩm định (underwriter): muốn hồ sơ có đủ thông tin để ra quyết định. > - Bộ phận tuân thủ (compliance): muốn đảm bảo định danh eKYC hợp lệ, chống rửa tiền. > Preconditions: Khách đã cài app, đã hoàn tất eKYC, đã đăng nhập. > Success Guarantee: Hồ sơ được lưu với trạng thái "Chờ thẩm định"; khách nhận mã hồ sơ; hệ thống gửi yêu cầu chấm điểm tín dụng. > Minimal Guarantee: Mọi thông tin khách đã nhập được lưu nháp; khách có thể quay lại tiếp tục. > Trigger: Khách bấm "Đăng ký vay". > > Main Success Scenario: > 1. Hệ thống hiển thị form chọn số tiền và kỳ hạn vay. > 2. Khách chọn số tiền (10–50 triệu) và kỳ hạn (3–12 tháng). > 3. Hệ thống hiển thị khoản trả góp dự kiến hàng tháng. > 4. Khách xác nhận và nhập thông tin nghề nghiệp, thu nhập. > 5. Hệ thống xác thực dữ liệu định dạng hợp lệ. > 6. Hệ thống gửi yêu cầu chấm điểm tín dụng tới đối tác CIC/credit bureau. > 7. Hệ thống hiển thị kết quả sơ bộ "Đủ điều kiện" và lưu hồ sơ trạng thái "Chờ thẩm định". > 8. Hệ thống gửi thông báo và mã hồ sơ cho khách. > > Extensions: > - 2a. Số tiền nằm ngoài khoảng cho phép: Hệ thống báo lỗi và gợi ý khoảng hợp lệ. > - 5a. Thu nhập kê khai dưới ngưỡng tối thiểu 5 triệu/tháng: Hệ thống từ chối sớm, hiển thị lý do, lưu hồ sơ trạng thái "Không đủ điều kiện". > - 6a. Dịch vụ chấm điểm tín dụng timeout: Hệ thống lưu hồ sơ "Chờ xử lý", thông báo "Chúng tôi sẽ phản hồi trong 24h". > - 6b. Khách có nợ xấu nhóm 3 trở lên: Hệ thống từ chối, hiển thị thông báo lịch sự, ghi log lý do cho compliance.
Diễn giải: Để ý cách các extension được đánh số khớp với bước trong main scenario (5a gắn với bước 5). Đây là quy ước Cockburn giúp dev và tester biết chính xác nhánh rẽ xảy ra ở đâu.
Bài học rút ra: Phần Extensions là nơi giá trị thật của BA nằm. Một junior BA sẽ chỉ viết được 8 bước "đường đẹp". Một BA giỏi — đặc biệt là ex-Sales quen lường tình huống — sẽ nghĩ ra hết các nhánh nợ xấu, timeout, thu nhập thấp. Đó là điều khác biệt giữa một spec sơ sài và một spec mà dev không phải hỏi đi hỏi lại.
Ví dụ 2: Use case "Yêu cầu bồi thường bảo hiểm" tại một công ty bancassurance
Bối cảnh: Một công ty bảo hiểm nhân thọ liên kết ngân hàng (bancassurance) ở Hà Nội số hóa quy trình yêu cầu bồi thường viện phí. Khách hàng chụp ảnh hóa đơn viện phí và nộp qua app. Bạn viết use case này. Điểm thú vị là nó có nhiều stakeholder với lợi ích xung đột — một thứ ex-Sales rất quen vì giống đàm phán nhiều bên.
Phần Stakeholders & Interests bạn viết:
- Khách hàng (người được bảo hiểm): muốn được duyệt nhanh, nhận tiền sớm.
- Giám định viên (claim adjuster): muốn hồ sơ rõ ràng, ảnh hóa đơn đọc được, tránh gian lận.
- Bộ phận tài chính: muốn kiểm soát dòng tiền chi trả.
- Đối tác ngân hàng: muốn trải nghiệm khách hàng tốt để giữ uy tín thương hiệu.
- 4a. Ảnh mờ, không đọc được số tiền: Hệ thống yêu cầu khách chụp lại, tối đa 3 lần; nếu vẫn lỗi, chuyển hồ sơ sang luồng xử lý thủ công và gán cho giám định viên.
Bài học rút ra: Use case phù hợp nhất khi nghiệp vụ có nhiều rẽ nhánh và nhiều bên liên quan. Ngành bảo hiểm và ngân hàng tại Việt Nam là "đất vàng" cho định dạng này. Khi bạn phỏng vấn vào các vị trí BA ở những domain này (bài 49, 51 sẽ đào sâu), khả năng viết use case fully dressed là một điểm cộng lớn.
Ví dụ 3: Sai lầm về goal level tại một startup SaaS
Bối cảnh: Một startup SaaS quản lý bán hàng (giả định tên SellPro) ở Đà Nẵng. Một BA mới — cũng là ex-Sales — được giao "viết use case cho tính năng đăng nhập". Bạn ấy viết hẳn một use case fully dressed dài hai trang cho "Đăng nhập bằng email", một use case khác cho "Đăng nhập bằng Google", một use case nữa cho "Quên mật khẩu"...
Vấn đề: "Đăng nhập" và "Xác thực OTP" là fish level (quá thấp). Viết fully dressed cho chúng vừa tốn thời gian vừa làm tài liệu phình to, khó đọc. Cách đúng là gộp xác thực thành một sub-function ngắn, hoặc đưa "Đăng nhập" thành một precondition của các use case mức sea level như "Tạo đơn hàng".
Diễn giải: Team lead phải ngồi lại chỉnh: chỉ những use case mức sea (Tạo đơn hàng, Xuất báo cáo doanh thu, Quản lý khách hàng) mới viết fully dressed. Đăng nhập viết "casual" (dạng đoạn văn ngắn) là đủ.
Bài học rút ra: Đừng "fully dress" mọi thứ. Cockburn còn có định dạng casual (một đoạn văn kể chuyện) cho use case đơn giản. Biết chọn độ chi tiết phù hợp là dấu hiệu của BA trưởng thành. Hãy hỏi: "Use case này có đáng hai trang giấy không?" Nếu không, viết casual.
Hướng dẫn từng bước
Đây là quy trình tôi khuyên ex-Sales áp dụng để viết một use case Cockburn từ con số không:
Bước 1 — Xác định primary actor và mục tiêu. Hỏi: "Ai là người chính cần đạt được điều gì?" Đặt tên use case bằng động từ + danh từ ở góc nhìn người dùng. "Nộp hồ sơ vay", không phải "Xử lý vay" (đó là góc nhìn hệ thống).
Bước 2 — Kiểm tra goal level. Mục tiêu này có giống "một việc người dùng làm xong trong một lần ngồi" không? Nếu quá cao (chiến lược) hoặc quá thấp (một thao tác nhỏ), điều chỉnh lại phạm vi.
Bước 3 — Liệt kê stakeholders và lợi ích. Dùng kỹ năng map các bên của ex-Sales. Mỗi bên muốn gì? Lợi ích của họ sẽ định hình các bước và các ràng buộc trong use case.
Bước 4 — Viết preconditions và postconditions. "Điều gì phải đúng trước khi bắt đầu?" và "Trạng thái hệ thống ra sao sau khi thành công?" Hai trường này giúp tester viết test rất nhanh.
Bước 5 — Viết Main Success Scenario. Đánh số từng bước. Mỗi bước là một câu khẳng định, chủ ngữ rõ ràng (actor hoặc hệ thống), một hành động. Quy luật vàng của Cockburn: luân phiên "Actor làm gì — Hệ thống phản hồi gì". Giữ ở mức 3–9 bước; nếu dài hơn, có thể bạn đang trộn nhiều use case.
Bước 6 — Rà từng bước để tìm Extensions. Với mỗi bước, tự hỏi: "Điều gì có thể đi sai ở đây? Có lựa chọn nào khác không?" Đánh số extension theo bước (3a, 3b, 5a...). Đây là bước quan trọng nhất và là bước ex-Sales làm xuất sắc.
Bước 7 — Rà soát với stakeholder. Đọc to use case cho một dev và một người nghiệp vụ. Nếu họ hiểu mà không hỏi lại, bạn đã viết tốt. Use case là để giao tiếp, không phải để trưng bày.
Lỗi thường gặp & mẹo
Lỗi 1 — Viết theo góc nhìn giao diện thay vì mục tiêu. Sai: "Khách bấm nút xanh ở góc phải". Đúng: "Khách xác nhận đăng ký vay". Use case mô tả ý định, không mô tả pixel. Wireframe (bài 28) lo phần giao diện.
Lỗi 2 — Quên Extensions hoặc viết quá sơ sài. Một use case chỉ có Main Success Scenario là use case mới làm một nửa. Đa số bug production đến từ các nhánh ngoại lệ không được nghĩ tới. Mẹo: dành 50% thời gian cho phần Extensions.
Lỗi 3 — Fully dress mọi use case. Như ví dụ SellPro, đừng viết hai trang cho "Đăng nhập". Chọn casual cho cái đơn giản, fully dressed cho cái phức tạp.
Lỗi 4 — Trộn nhiều mục tiêu vào một use case. Nếu use case của bạn có "và" trong tên ("Nộp hồ sơ và thanh toán phí"), khả năng cao đó là hai use case. Tách ra.
Lỗi 5 — Đánh số extension không khớp bước. Extension 6a phải là nhánh rẽ tại bước 6. Nếu đánh lung tung, dev và tester sẽ rối.
Mẹo cho ex-Sales: Hãy nghĩ Main Success Scenario là "kịch bản demo hoàn hảo" bạn từng trình bày cho khách, còn Extensions là "danh sách objection" bạn chuẩn bị trước. Bạn đã có sẵn tư duy này từ nghề bán hàng — chỉ cần đóng gói lại theo template.
Mẹo định dạng: Trong các tool như Confluence (bài 26), tạo một template use case sẵn để cả team điền theo cùng một khuôn. Tính nhất quán giúp tài liệu dễ đọc và dễ bảo trì.
Bài tập thực hành
- Viết use case fully dressed. Chọn một nghiệp vụ bạn quen từ thời làm Sales/BD — ví dụ "Gửi báo giá cho khách hàng" hoặc "Tạo hợp đồng bán hàng". Viết đầy đủ 9 trường của template Cockburn, trong đó Main Success Scenario có 5–8 bước và phần Extensions có ít nhất 4 nhánh rẽ.
- Phân loại goal level. Cho danh sách sau, đánh dấu mỗi mục là cloud / sea / fish: (a) Tăng doanh số quý 4; (b) Đặt lịch demo sản phẩm; (c) Gửi OTP qua SMS; (d) Tạo đơn hàng; (e) Kiểm tra mã giảm giá. Giải thích vì sao.
- Tìm Extensions. Lấy lại use case "Nộp hồ sơ vay" ở Ví dụ 1, nghĩ thêm ít nhất 3 extension mới mà tôi chưa liệt kê (gợi ý: nghĩ về mạng yếu, khách bỏ giữa chừng, dữ liệu trùng).
- Chuyển đổi định dạng. Viết use case "Đăng nhập bằng email" ở dạng casual (một đoạn văn 4–6 câu), rồi tự đánh giá: nó có cần fully dressed không? Vì sao?
Tóm tắt
Use case theo template Cockburn là cách BA kể lại câu chuyện tương tác giữa người dùng và hệ thống một cách có kỷ luật. Cấu trúc fully dressed gồm: tên, primary actor, stakeholders & interests, preconditions, postconditions, trigger, main success scenario, và — quan trọng nhất — extensions. Hãy nhớ ba điều: chọn đúng goal level (ưu tiên sea level), đầu tư mạnh vào Extensions (chính là objection handling của nghề bán hàng được hệ thống hóa), và biết khi nào dùng casual thay vì fully dressed để tài liệu gọn gàng.
Với nền tảng Sales/BD, bạn có lợi thế tự nhiên ở hai phần khó nhất: map stakeholders và lường trước các tình huống rẽ nhánh. Đây là kỹ năng phân biệt một BA xoàng với một BA mà cả dev lẫn stakeholder đều tin tưởng. Bài tiếp theo (bài 23) sẽ đưa bạn tới business rule catalog — nơi các ràng buộc nghiệp vụ ẩn trong các extension được tách ra và quản lý tập trung.