Business Analysis Planning and Monitoring(BAPM)

Nghe tên thì tưởng đây là việc của project manager. Không phải. Vùng này nói về việc bạn lập kế hoạch cho chính công việc phân tích của mình: sẽ làm theo cách nặng hay nhẹ, sẽ gặp ai và gặp bao nhiêu lần, ai có quyền duyệt yêu cầu, tài liệu để ở đâu và ai được sửa.

Đây là vùng duy nhất trong sáu knowledge area mà đối tượng được phân tích chính là công việc của bạn.

Năm thứ phải chốt trước khi bắt tay

• Plan Business Analysis Approach: chọn cách tiếp cận, mức chi tiết tài liệu, nhịp bàn giao.
• Plan Stakeholder Engagement: ai liên quan, ai thật sự có ảnh hưởng tới quyết định, gặp bằng hình thức nào và bao lâu một lần.
• Plan Business Analysis Governance: ai duyệt cái gì, thay đổi đi qua đường nào, và ai là người ra quyết định cuối khi hai bên không chịu nhau.
• Plan Business Analysis Information Management: tài liệu để đâu, đặt tên ra sao, ai được sửa.
• Identify Business Analysis Performance Improvements: nhìn lại cách mình đang làm và sửa nó giữa chừng.

Predictive hay adaptive

BABOK không bắt bạn chọn một trong hai một cách cực đoan, mà mô tả một dải.

Trong thực tế phần lớn dự án ở Việt Nam nằm đâu đó ở giữa, kể cả những nơi tự nhận là làm Scrum. Một dự án ngân hàng có thể chạy sprint hai tuần nhưng vẫn cần biên bản ký duyệt cho phần liên quan tới tuân thủ. Nói thẳng chuyện này ngay từ đầu tốt hơn là giả vờ đang thuần agile rồi lúng túng khi kiểm toán hỏi giấy tờ.

Làm gọn cho dự án nhỏ

Bạn không cần một bản kế hoạch phân tích 15 trang cho dự án ba tháng. Một trang trong Confluence trả lời năm câu là đủ:

1. Chúng ta sẽ viết yêu cầu ở dạng gì và chi tiết tới đâu.
2. Ai là người ra quyết định cuối khi hai bên không thống nhất.
3. Yêu cầu được duyệt bằng hình thức nào, email hay comment hay chữ ký.
4. Tài liệu để ở đâu, bản nào là bản chuẩn.
5. Thay đổi đi qua bước nào trước khi vào backlog.

Chỉ riêng câu số 2 đã tiết kiệm cho bạn hàng chục giờ tranh luận về sau.

Ví dụ thực tế

"Nếu chị đi vắng thì ai quyết?" Câu hỏi này được đặt ra ở tuần đầu tiên của một dự án hệ thống quản lý học viên cho trung tâm tiếng Anh 11 chi nhánh, và câu trả lời được ghi thẳng vào trang kế hoạch phân tích.

Trang đó dài đúng một trang. Phần stakeholder engagement liệt kê 9 người, đánh dấu rõ hai người bắt buộc phải có mặt khi chốt nghiệp vụ học phí, còn lại chỉ cần nhận bản tóm tắt. Phần governance ghi: chị giám đốc vận hành là người quyết cuối, và nếu chị bận quá 3 ngày thì trưởng phòng đào tạo được quyết thay trong phạm vi không ảnh hưởng doanh thu.

Câu đó cứu dự án ở tháng thứ ba. Chị giám đốc đi công tác hai tuần đúng lúc cần chốt cách tính học phí cho học viên bảo lưu. Vì đã có quy ước từ trước, quyết định được đưa ra trong ngày thay vì treo hai tuần và làm trễ nguyên một sprint.

Đo hiệu quả công việc phân tích

Task cuối cùng gần như không ai làm. Vài chỉ số dùng được ngay mà không cần công cụ gì:

• Số câu hỏi dev phải hỏi lại về một user story sau khi đã được refine.
• Tỷ lệ defect ở UAT thuộc loại "hiểu sai yêu cầu" thay vì lỗi code.
• Số lần yêu cầu phải làm lại sau khi đã được duyệt.

Nếu con số thứ hai cao bất thường trong hai sprint liên tiếp, vấn đề nằm ở cách viết yêu cầu chứ không ở đội dev. Đó là tín hiệu để đổi cách làm, chứ không phải để họp rút kinh nghiệm rồi thôi.