Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa hoàn thành buổi workshop với khách hàng. Trên bảng là 87 yêu cầu (requirements) được dán kín bằng giấy note. Ai cũng gật gù: "Tất cả đều quan trọng, làm hết đi em." Nhưng team chỉ có 4 lập trình viên, ngân sách cho 3 tháng, và ngày go-live đã được CEO hứa với hội đồng quản trị. Bạn không thể làm hết 87 thứ. Vậy làm cái nào trước?
Đây chính là khoảnh khắc mà giá trị thật của một Business Analyst lộ ra. Viết được requirement thì nhiều người làm được. Nhưng quyết định thứ tự làm — cái nào ship trước, cái nào để sau, cái nào dũng cảm bỏ đi — mới là kỹ năng tách biệt một BA giỏi khỏi một người chỉ biết ghi chép. Prioritization không phải là việc "sắp xếp cho gọn". Nó là cách bạn biến nguồn lực hữu hạn thành giá trị tối đa cho doanh nghiệp.
Trong bài này, tôi sẽ trang bị cho bạn một bộ công cụ thực chiến: các framework để ưu tiên yêu cầu một cách có hệ thống, có thể bảo vệ trước stakeholder, và quan trọng nhất — dựa trên dữ liệu thay vì cảm tính hay "ai nói to hơn thì thắng".
Khái niệm cốt lõi
Vì sao prioritization là bắt buộc, không phải tùy chọn
Có ba thực tế khiến không một dự án nào thoát khỏi việc ưu tiên:
- Nguồn lực luôn hữu hạn: thời gian, tiền bạc, con người. Bạn không bao giờ có đủ cả ba cùng lúc.
- Stakeholder luôn muốn mọi thứ "ASAP": với họ, mọi yêu cầu đều khẩn cấp và quan trọng — bởi vì họ chỉ nhìn từ góc của mình.
- Giá trị phân bố không đều: theo nguyên lý Pareto, thường khoảng 20% yêu cầu tạo ra 80% giá trị. Việc của BA là tìm ra 20% đó.
Các tiêu chí ưu tiên phổ biến
Trước khi vào framework cụ thể, bạn cần biết người ta thường cân nhắc những trục nào:
- Business value — giá trị kinh doanh: doanh thu, tiết kiệm chi phí, sự hài lòng khách hàng.
- Cost / Effort — công sức triển khai: thường ước lượng bằng story point hoặc man-day.
- Risk — rủi ro: kỹ thuật, pháp lý, vận hành nếu không làm hoặc nếu làm sai.
- Time sensitivity / Urgency — tính cấp thiết theo thời gian: cơ hội thị trường, deadline pháp lý.
- Dependencies — phụ thuộc: yêu cầu A có phải nền móng cho B, C, D không.
MoSCoW — phân nhóm nhanh, dễ giao tiếp
MoSCoW chia yêu cầu thành 4 nhóm:
- Must have — bắt buộc. Không có nó thì sản phẩm coi như thất bại hoặc không hợp pháp. Đây là "đường biên không thể thương lượng".
- Should have — nên có. Quan trọng nhưng không sống còn; có cách xử lý tạm thời (workaround) nếu thiếu.
- Could have — có thì tốt. Mong muốn, làm nếu còn dư thời gian/nguồn lực. Đây chính là vùng đệm để bạn cắt khi tiến độ căng.
- Won't have (this time) — sẽ không làm lần này. Được ghi nhận rõ ràng để stakeholder biết nó không bị quên, chỉ là không nằm trong phạm vi hiện tại.
Kano Model — nhìn yêu cầu qua lăng kính sự hài lòng khách hàng
Kano (do Noriaki Kano phát triển) không hỏi "cái này quan trọng cỡ nào" mà hỏi "cái này ảnh hưởng đến cảm xúc khách hàng ra sao". Có ba loại chính:
- Must-be (Basic): có thì khách không khen, nhưng thiếu thì khách giận. Ví dụ: app ngân hàng phải đăng nhập được. Không ai khen "app đăng nhập tốt quá", nhưng nếu lỗi đăng nhập thì bão một sao.
- Performance (One-dimensional): càng nhiều càng hài lòng, theo tỉ lệ tuyến tính. Ví dụ: tốc độ chuyển khoản, càng nhanh càng thích.
- Delighter (Excitement): khách không kỳ vọng, nhưng có thì sướng bất ngờ. Ví dụ: tính năng "quét hóa đơn để tự điền thông tin chuyển khoản". Thiếu không sao, có thì khách kể cho bạn bè.
Value vs Effort & WSJF — định lượng để xếp hạng
Ma trận Value vs Effort đặt yêu cầu lên lưới 2x2: trục tung là giá trị, trục hoành là công sức. Bốn góc:
- Quick Wins (giá trị cao, công sức thấp): làm ngay.
- Big Bets (giá trị cao, công sức cao): lên kế hoạch kỹ.
- Fill-ins (giá trị thấp, công sức thấp): làm khi rảnh.
- Money Pits / Time Sinks (giá trị thấp, công sức cao): tránh xa.
> WSJF = Cost of Delay / Job Size
Trong đó Cost of Delay = Business Value + Time Criticality + Risk Reduction/Opportunity Enablement. Mỗi yếu tố chấm theo thang Fibonacci tương đối (1, 2, 3, 5, 8, 13...). Yêu cầu nào có WSJF cao nhất thì làm trước. Ý tưởng cốt lõi rất kinh tế: ưu tiên việc tạo nhiều giá trị mà tốn ít công nhất, vì như vậy ta "giải phóng" giá trị nhanh nhất.
Tình huống thực tế
Ví dụ 1 — Ví điện tử MoMo: dùng MoSCoW cho tính năng "Túi Thần Tài" dịp Tết
Giả sử đội sản phẩm của một ví điện tử như MoMo chuẩn bị tính năng lì xì online cho mùa Tết, deadline cứng là 28 Tết — không thể dời vì qua Tết thì vô nghĩa. Workshop sinh ra 40 yêu cầu. BA điều phối phiên MoSCoW:
- Must have: tạo bao lì xì, nạp tiền vào bao, gửi qua link/số điện thoại, người nhận rút về ví. Thiếu bất kỳ cái nào thì tính năng không tồn tại.
- Should have: chọn mẫu bao lì xì theo con giáp, lời chúc soạn sẵn. Quan trọng cho trải nghiệm Tết nhưng nếu kẹt thì có thể ra sau bằng bản cập nhật.
- Could have: hiệu ứng pháo hoa khi mở bao, bảng xếp hạng "ai lì xì nhiều nhất".
- Won't have (this Tết): lì xì theo nhóm chat, tích hợp với mạng xã hội bên thứ ba.
Bài học: MoSCoW phát huy sức mạnh nhất khi deadline cứng. Vùng Could/Should chính là "van xả áp" để bạn bảo vệ ngày go-live mà không hy sinh phần lõi.
Ví dụ 2 — Tiki dùng Kano để quyết định đầu tư cho trang chi tiết sản phẩm
Một sàn thương mại điện tử như Tiki khảo sát 500 khách hàng về các tính năng của trang chi tiết sản phẩm, dùng bộ câu hỏi Kano (hỏi cặp: "Bạn cảm thấy thế nào nếu CÓ tính năng này?" và "nếu KHÔNG có?").
- Kết quả phân loại "hiển thị đúng giá và tình trạng còn hàng" là Must-be — đương nhiên phải có, đầu tư thêm không tăng điểm hài lòng.
- "Đánh giá có hình ảnh thật từ người mua" là Performance — càng nhiều review chất lượng, điểm hài lòng càng tăng tuyến tính. Đáng để đầu tư liên tục.
- "Xem sản phẩm bằng AR (đặt thử nội thất vào phòng qua camera)" là Delighter — chỉ 8% khách kỳ vọng, nhưng nhóm này wow rất mạnh.
Bài học: Kano ngăn bạn rơi vào bẫy "tính năng hào nhoáng". Đừng đổ tiền vào Delighter khi phần Performance còn chưa tới ngưỡng — và đừng quên rằng kỳ vọng khách hàng trôi theo thời gian: Delighter hôm nay (camera kép trên điện thoại) trở thành Must-be ngày mai.
Ví dụ 3 — Một startup Fintech dùng WSJF khi backlog quá tải
Một startup cho vay tiêu dùng có backlog 60 hạng mục và đội kỹ sư chỉ làm được khoảng 5 hạng mục mỗi sprint. Stakeholder ai cũng đòi ưu tiên việc của mình. BA đề xuất chấm WSJF cho top 12 hạng mục đang tranh chấp. Lấy ba ví dụ:
| Hạng mục | Business Value | Time Criticality | Risk/Opp | Job Size | WSJF |
|---|---|---|---|---|---|
| Tích hợp eKYC với CIC | 8 | 13 | 8 | 5 | 5.8 |
| Dashboard báo cáo cho sếp | 5 | 2 | 2 | 8 | 1.1 |
| Nhắc nợ tự động qua SMS | 8 | 5 | 5 | 3 | 6.0 |
Bài học: WSJF biến cuộc tranh luận chính trị thành cuộc thảo luận trên con số. Nó đặc biệt hữu ích khi bạn phải nói "không/chưa" với người có quyền lực cao hơn mình.
Hướng dẫn từng bước
Đây là quy trình tôi khuyên bạn áp dụng cho mọi phiên prioritization:
- Chuẩn bị danh sách yêu cầu rõ ràng: mỗi yêu cầu phải ở cùng "độ hạt" (granularity). Đừng so một epic lớn với một tinh chỉnh nhỏ — như cân voi với chuột.
- Chọn framework phù hợp với bối cảnh:
- Xác định tiêu chí và trọng số cùng stakeholder trước khi chấm điểm. Thống nhất luật chơi trước để tránh cãi nhau giữa trận.
- Chấm điểm tương đối, không tuyệt đối: dùng thang Fibonacci và so sánh cặp. "Cái này gấp đôi cái kia không?" dễ trả lời hơn "cái này đáng 7 hay 8 điểm?".
- Tổng hợp và sắp xếp: tính kết quả, xếp hạng. Với MoSCoW, kiểm tra tỉ lệ Must không vượt 60% effort.
- Kiểm tra dependency và "sanity check": thứ tự WSJF có thể bị phá vỡ bởi phụ thuộc kỹ thuật. Nếu A là nền móng của B, A phải lên trước dù điểm thấp hơn.
- Trình bày, đối thoại, chốt: prioritization là quyết định tập thể có cấu trúc, không phải BA tự quyết một mình. Ghi lại lý do (rationale) để sau này truy vết được.
- Coi đây là việc lặp lại (re-prioritize): mỗi sprint hoặc mỗi cột mốc, đánh giá lại. Thị trường đổi, đối thủ ra tính năng mới — thứ tự cũng phải đổi theo.
Lỗi thường gặp & mẹo
- "Mọi thứ đều là Must have": lỗi phổ biến nhất. Khi mọi yêu cầu đều ưu tiên cao nghĩa là không có gì được ưu tiên. Mẹo: ép giới hạn ngân sách Must ≤ 60% effort, buộc stakeholder phải lựa chọn thật.
- Để "ai nói to nhất thắng" (HiPPO — Highest Paid Person's Opinion): quyết định theo người có chức cao nhất thay vì dữ liệu. Mẹo: dùng framework định lượng (WSJF) để trung hòa quyền lực; con số nói thay bạn.
- So sánh các yêu cầu khác độ hạt: đặt một epic 3 tháng cạnh một nút bấm. Mẹo: chuẩn hóa độ hạt trước, hoặc tách epic ra trước khi chấm.
- Chỉ nhìn value, quên effort và risk: chọn toàn tính năng "đắt giá" nhưng ngốn cả quý. Mẹo: luôn chấm cả hai trục; ưu tiên Quick Wins để tạo đà sớm.
- Prioritize một lần rồi đóng băng: backlog là vật sống. Mẹo: lên lịch re-prioritize định kỳ, coi nó như một nghi thức của team.
- Bỏ qua Cost of Delay: chỉ hỏi "việc này lớn cỡ nào" mà quên "trì hoãn nó tốn gì". Mẹo: với mỗi yêu cầu, hỏi thêm "nếu lùi 3 tháng thì mất gì?".
- Quên dependency: WSJF xếp B lên trước A nhưng B cần A mới chạy được. Mẹo: vẽ sơ đồ phụ thuộc trước khi chốt thứ tự cuối.
Bài tập thực hành
Bối cảnh giả định: bạn là BA cho một app đặt đồ ăn mới ở Việt Nam (kiểu ShopeeFood/GrabFood). Đội có 4 dev, mục tiêu ra mắt MVP sau 10 tuần. Backlog gồm 10 yêu cầu:
- Đăng ký/đăng nhập bằng số điện thoại + OTP
- Tìm nhà hàng theo vị trí GPS
- Thanh toán qua ví điện tử (MoMo/ZaloPay)
- Theo dõi shipper realtime trên bản đồ
- Đánh giá món ăn bằng sao + ảnh
- Gợi ý món "ăn lại" dựa trên lịch sử (AI)
- Mã giảm giá / voucher
- Chat trực tiếp với shipper
- Gọi món bằng giọng nói
- Lịch sử đơn hàng & đặt lại nhanh
a) Phân loại cả 10 yêu cầu theo MoSCoW cho MVP 10 tuần. Đảm bảo Must không "phình" quá lớn — hãy tự ước lượng effort thô và giữ Must ≤ 60%.
b) Chọn 3 yêu cầu bạn nghi là Delighter theo Kano và giải thích vì sao chúng tạo wow nhưng không sống còn.
c) Chấm WSJF cho yêu cầu số 3 (thanh toán ví) và số 6 (gợi ý AI), dùng thang Fibonacci cho Business Value, Time Criticality, Risk/Opportunity và Job Size. So sánh kết quả và viết 2–3 câu bảo vệ quyết định của bạn trước một CEO đang rất mê tính năng AI.
d) Chỉ ra ít nhất một dependency trong danh sách có thể buộc bạn phá vỡ thứ tự ưu tiên thuần theo điểm số.
Hãy viết câu trả lời ra giấy như thể bạn sắp trình bày trong một buổi họp thật. Không có đáp án "đúng tuyệt đối" — điều tôi chấm là lập luận của bạn có chặt chẽ và bảo vệ được không.
Tóm tắt
Prioritization là nơi BA chứng minh giá trị thật: biến nguồn lực hữu hạn thành giá trị tối đa, và biến những cuộc tranh luận cảm tính thành quyết định dựa trên dữ liệu. Ba framework xương sống cần nằm lòng:
- MoSCoW — nhanh, dễ giao tiếp, lý tưởng khi có deadline cứng; nhớ giữ Must ≤ 60% effort.
- Kano Model — nhìn qua lăng kính cảm xúc khách hàng (Must-be / Performance / Delighter); giúp tránh bẫy tính năng hào nhoáng và cân bằng đầu tư.
- WSJF / Value vs Effort — định lượng hóa để xếp hạng khách quan trong môi trường Agile backlog đông; vũ khí để nói "chưa" với người quyền lực mà vẫn lịch sự.