Business Requirement

Hỏi một giám đốc vận hành "anh cần hệ thống làm gì", bạn sẽ nhận được câu trả lời kiểu "tôi cần biết tồn kho thật, chứ giờ mỗi lần kiểm kê lệch mấy trăm triệu". Đó là business requirement: nhu cầu ở cấp tổ chức, phát biểu bằng ngôn ngữ tiền bạc và mục tiêu, chưa dính gì tới màn hình hay nút bấm.

Business requirement trả lời câu "vì sao chi tiền", không trả lời câu "hệ thống làm gì".

Ai phát biểu ra nó

Người ký duyệt ngân sách. Ban giám đốc, chủ đầu tư, giám đốc khối, đôi khi là hội đồng quản trị. Trong BABOK v3 đây là tầng cao nhất trong bốn tầng yêu cầu, và nó là gốc để truy vết mọi thứ phía dưới.

Người dùng cuối không phát biểu business requirement. Chỗ này đi phỏng vấn hay bị hỏi, mà đi làm cũng hay bị nhầm. Chị thu ngân không quan tâm tỷ lệ thất thoát toàn chuỗi, chị quan tâm ca của chị đóng sổ nhanh hay chậm. Cái đó là stakeholder requirement, một tầng khác.

Về mặt tài liệu, business requirement sống ở phần đầu của BRD hoặc trong project charter. Thường chỉ 3–7 gạch đầu dòng cho cả dự án. Nhiều hơn thế thường là dấu hiệu bạn đang chép nhầm mục tiêu phòng ban vào.

So sánh với stakeholder requirement

Ví dụ thực tế

Tháng 8, ban giám đốc một chuỗi cửa hàng tiện lợi duyệt ngân sách thay hệ thống POS. Chuỗi có 173 điểm bán, doanh thu trung bình 26 triệu mỗi ngày mỗi cửa hàng.

Business requirement viết đúng:

1. Giảm chênh lệch kiểm kê hàng tháng từ 1,8% giá trị tồn xuống dưới 0,5% trong vòng 2 quý sau go-live.
2. Rút thời gian chốt ca của một cửa hàng từ 25 phút xuống dưới 10 phút.
3. Đáp ứng quy định hoá đơn điện tử có mã của cơ quan thuế cho toàn bộ 180 điểm bán trước ngày hết hạn chuyển đổi.

Business requirement viết sai (nhưng gặp suốt trong BRD ở VN):

• "Xây dựng hệ thống POS hiện đại, đáp ứng nhu cầu quản lý." — không đo được, không ai cãi được, và cũng chẳng làm gì được với nó.
• "Màn hình bán hàng phải có phím tắt F2 để tìm sản phẩm." — đây là solution requirement lạc chỗ.

Mục số 3 là mục không mang ra bàn được. Tới vòng cắt phạm vi, giám đốc tài chính cắt từ dưới lên rồi dừng ngay trên dòng đó — hạn chuyển đổi hoá đơn điện tử do cơ quan thuế đặt, không do dự án đặt.

Mẹo khi đi làm

Ép mỗi business requirement phải có một con số và một mốc thời gian. Nếu người đề xuất không đưa ra được con số, hỏi tiếp: "hiện tại đang là bao nhiêu". Không ai biết hiện tại là bao nhiêu, thì việc đầu tiên của dự án là đo cái hiện tại, chứ chưa phải code.

Còn một việc nữa đáng làm: giữ một bảng nhỏ hai cột — business requirement bên trái, các tính năng phục vụ nó bên phải. Sau vài sprint mở ra xem, bạn sẽ thấy có những tính năng nằm chình ình trong backlog mà cột bên trái để trống. Đó là ứng viên số một cho việc cắt giảm khi timeline bắt đầu căng.

Và khi khách đề nghị thêm một thứ giữa dự án, hãy hỏi "cái này phục vụ mục tiêu nào trong ba mục tiêu chúng ta đã chốt", thay vì hỏi "cái này có cần không". Hỏi kiểu đó thì việc từ chối không còn là ý kiến cá nhân của bạn nữa.