Requirements Prioritization

Mọi dự án đều thiếu thời gian. Nên câu hỏi không bao giờ là "làm gì", mà là "làm gì trước". Và nếu không có một cách xếp thứ tự mà mọi người cùng chấp nhận, thứ tự sẽ được quyết bởi ai gọi điện nhiều nhất hoặc ai có chức vụ cao nhất trong phòng họp.

Xếp ưu tiên là kỹ năng đàm phán nhiều hơn là kỹ thuật. Khung phương pháp chỉ giúp cuộc đàm phán đó có ngôn ngữ chung.

Khi mọi thứ đều ưu tiên cao thì không có gì ưu tiên cao. Ép người ra quyết định phải chọn là một phần của công việc.

Các khung hay dùng

MoSCoW — chia thành Must, Should, Could, Won't. Dễ hiểu nhất, hợp khi làm việc với khách không quen thang điểm, hợp cho việc chốt phạm vi một bản phát hành. Điểm yếu kinh điển: ai cũng muốn mọi thứ là Must. Cách chữa là đặt hạn mức trước, ví dụ Must không quá 60% năng lực của đội trong phát hành đó.

Mô hình Kano — phân loại tính năng theo cách chúng ảnh hưởng tới sự hài lòng: nhóm cơ bản (không có thì bực, có cũng không khen), nhóm tuyến tính (càng nhiều càng hài lòng), nhóm gây thích thú (không ai đòi nhưng có thì ấn tượng), cùng nhóm vô cảm và nhóm ngược. Hợp cho sản phẩm hướng người dùng cuối. Cần khảo sát người dùng thật mới chạy đúng, nên hơi nặng cho dự án nhỏ.

RICE — điểm = (Reach × Impact × Confidence) / Effort. Reach là số người ảnh hưởng trong một khoảng thời gian, Impact cho theo thang cố định, Confidence là mức tự tin vào ước lượng, Effort tính bằng người-tháng. Hợp cho đội product có dữ liệu người dùng. Giá trị lớn nhất của RICE nằm ở cột Confidence: nó buộc người đề xuất thừa nhận mình đang đoán.

WSJF — dùng trong SAFe: điểm = Cost of Delay chia cho Job Size, trong đó Cost of Delay gộp giá trị kinh doanh, tính cấp thiết theo thời gian, và khả năng giảm rủi ro. Hợp khi nhiều đội tranh một nguồn lực và cần cách xếp hạng tương đối minh bạch.

Ngoài ra còn vài cách nhẹ mà hiệu quả: xếp hạng cưỡng bức (từ 1 tới N, không cho đồng hạng), 100 điểm chia cho các bên liên quan, và ma trận giá trị so với công sức vẽ trên bảng trắng trong 20 phút.

Ví dụ thực tế

Ứng dụng đặt vé xe khách liên tỉnh, 4 tháng để ra bản đầu tiên trước cao điểm Tết, đội 6 người, backlog 47 hạng mục.

Đội chạy hai vòng. Vòng một dùng MoSCoW trong workshop 3 tiếng với chủ đầu tư và trưởng phòng vận hành, ra 12 Must, 15 Should, 14 Could, 6 Won't. Con số 12 Must đến sau khi BA đặt trần: đội làm được khoảng 20 hạng mục lớn trong 4 tháng, mà Must chỉ được chiếm tối đa 60% năng lực đó, nên trần là 12 mục — mục thứ 13 muốn vào thì phải có mục nào đó bước ra. Phần 40% còn lại để dành cho Should và Could, đó chính là chỗ đội nhả ra khi tiến độ căng mà vẫn giữ được mốc.

Vòng hai dùng RICE để xếp thứ tự trong nhóm Should, vì nhóm này cạnh tranh nhau cho phần năng lực còn lại. Kết quả gây bất ngờ: tính năng "chọn chỗ ngồi theo sơ đồ xe" mà ai cũng cho là quan trọng lại xếp sau "nhắc lịch trình qua Zalo trước giờ khởi hành 2 tiếng", vì tính năng nhắc lịch chạm tới toàn bộ khách đặt vé còn chọn chỗ chỉ ảnh hưởng khoảng 35% chuyến có sơ đồ chỗ.

Nhóm Won't được đánh máy lại thành một trang riêng và gửi cho khách ngay chiều hôm đó.

Lỗi hay gặp

Xếp ưu tiên mà không có trần năng lực. Không biết đội làm được bao nhiêu thì danh sách ưu tiên chỉ là danh sách mong muốn được sắp xếp cho đẹp.

Bỏ qua phụ thuộc kỹ thuật. Một tính năng điểm cao nhưng cần nền tảng chưa có thì không thể làm trước. Sau khi xếp theo giá trị, luôn rà lại một lượt cùng tech lead.

Quên yêu cầu tuân thủ và NFR. Chúng không tạo ra giá trị nhìn thấy được nên luôn tụt hạng, cho tới khi bị thanh tra hoặc hệ thống sập vào ngày cao điểm.

Và đừng xếp ưu tiên một lần rồi khoá. Mỗi vài tuần dữ liệu mới xuất hiện, thị trường đổi, đối thủ ra tính năng mới. Danh sách ưu tiên là thứ sống, không phải thứ đóng khung treo tường.