Requirements Life Cycle Management(RLCM)

Thu thập yêu cầu xong không phải là hết. Yêu cầu còn sống suốt dự án: bị đổi, bị ưu tiên lại, bị hiểu khác đi sau ba tháng, và phải trả lời được câu hỏi "cái này ai duyệt, duyệt lúc nào". Vùng knowledge area này lo đúng phần đó.

Elicitation lấy yêu cầu về. Requirements Life Cycle Management giữ cho chúng còn dùng được cho tới ngày go-live.

Năm task, nhưng đừng đọc như năm bước

Ba cái đầu chạy nền suốt dự án. Trace Requirements nối yêu cầu với mục tiêu kinh doanh, với thiết kế, với test case — đây chính là traceability. Maintain Requirements giữ cho yêu cầu còn dùng lại được thay vì mục ruỗng dần sau mỗi lần sửa vội. Prioritize Requirements xếp thứ tự theo giá trị, rủi ro, chi phí, ràng buộc.

Hai cái còn lại chỉ nổ khi có chuyện. Assess Requirements Changes — đánh giá tác động trước khi ai kịp gật đầu. Approve Requirements — có người đủ thẩm quyền ký, và có chỗ ghi lại là đã ký.

Ranh giới với hai vùng đứng cạnh nó hay bị mờ:

Traceability trong đời thật

Sách vẽ ra một ma trận truy vết đẹp đẽ. Ngoài đời, ở dự án 62 user story, một file Excel với cột "mã yêu cầu, mục tiêu kinh doanh, màn hình, API, test case" là đủ dùng. Lên tới bảy trăm mấy yêu cầu thì phải làm trong Jira với link giữa các issue, vì Excel sẽ chết ở khoảng giữa.

Truy vết có ích nhất vào đúng hai thời điểm: khi khách xin đổi và bạn cần biết đổi cái này ảnh hưởng tới đâu, và khi có bug ngoài production mà bạn cần biết yêu cầu gốc nói gì.

Ví dụ thực tế

Dự án hệ thống thu hộ cho một ví điện tử, xử lý khoảng 40 nghìn giao dịch mỗi ngày, có 8 đối tác tích hợp.

Tuần thứ 9, đối tác lớn nhất yêu cầu đổi định dạng file đối soát cuối ngày, từ CSV sang một cấu trúc có thêm ba trường. Nghe rất nhỏ. Nhưng vì đội có ma trận truy vết, trong hai tiếng đã liệt kê được: 4 yêu cầu chức năng liên quan, 1 job chạy lúc 23:30 phải sửa, 2 màn hình hiển thị lịch sử đối soát, 11 test case phải viết lại, và một chỗ đáng chú ý là báo cáo gửi kế toán đang đọc trực tiếp file cũ.

Cái báo cáo kế toán đó nằm ngoài đầu mọi người trong phòng. Không có truy vết thì đội sửa xong phần tích hợp, ba ngày sau kế toán mới phát hiện báo cáo trống. Chi phí ước tính ban đầu là 2 ngày công, sau khi truy vết đầy đủ thành 6 ngày công. Đối tác vẫn đồng ý, nhưng lịch được dời hợp lý ngay từ đầu thay vì trễ trong hoảng loạn.

Lỗi hay gặp

1. Không ai duyệt gì cả. Tài liệu gửi email, khách im lặng, đội coi như đã đồng ý. Tới UAT khách bảo chưa từng thấy. Một dòng xác nhận trong Confluence hay một email trả lời "đồng ý bản ngày 12/3" giải quyết được chuyện này.
2. Ưu tiên bằng cảm tính. Ai nói to hơn thì yêu cầu người đó lên trước. Dùng một khung đơn giản như MoSCoW cũng còn hơn không có gì.
3. Tài liệu và Jira lệch nhau. Yêu cầu sửa trong Jira nhưng FRD vẫn bản cũ. Được ba tháng thì hỏi bản nào đúng, mỗi người chỉ một chỗ khác nhau. Chọn một nguồn duy nhất làm chuẩn và ghi rõ ngay đầu tài liệu rằng chỗ còn lại chỉ để tham chiếu.
4. Đánh giá thay đổi chỉ nhìn phần code. Quên đào tạo người dùng, quên dữ liệu cũ, quên tài liệu hướng dẫn.

Mẹo khi đi làm

Đặt một quy ước đặt mã yêu cầu ngay từ ngày đầu, kiểu FR-PAY-012. Nghe rất nhỏ nhặt, nhưng khi dev nhắn hỏi "cái nghiệp vụ hoàn tiền nằm chỗ nào" thì bạn trả lời trong 5 giây thay vì lục lại cả tập FRD.

Và giữ một mục "quyết định đã chốt" ở đầu tài liệu: ghi ngày, ghi tên người quyết, ghi đúng một dòng lý do. Chính dòng lý do đó là thứ khiến lần sau không ai phải họp lại từ đầu để tranh luận một chuyện đã có kết luận.