Stakeholder Requirement
Tầng yêu cầu ở giữa: mô tả nhu cầu của từng nhóm người liên quan và cách họ tương tác với giải pháp. Do trưởng phòng, người dùng nghiệp vụ, đội vận hành phát biểu.
Định nghĩa
Giữa mục tiêu của ban giám đốc và đặc tả kỹ thuật cho dev có một khoảng trống lớn. Lấp khoảng trống đó là stakeholder requirement: nhu cầu của từng nhóm người cụ thể, phát biểu theo cách họ làm việc hằng ngày.
Ví dụ nhanh. Business requirement: "giảm 40% thời gian xử lý hồ sơ vay tiêu dùng". Từ đó xuống được tới màn hình thì còn xa. Ở giữa là những câu như: chuyên viên thẩm định cần xem được lịch sử tín dụng và ảnh giấy tờ trên cùng một màn hình; trưởng nhóm cần duyệt hàng loạt hồ sơ dưới 50 triệu; bộ phận kiểm soát nội bộ cần truy được ai đã sửa gì lúc mấy giờ.
Đây là tầng dịch: từ ngôn ngữ mục tiêu sang ngôn ngữ công việc, trước khi dịch tiếp sang ngôn ngữ hệ thống.
Vì sao tầng này hay bị bỏ qua
Vì nó tốn thời gian và không ai đòi. Khách đưa BRD, sếp giục có FRD để dev bắt đầu, thế là BA nhảy thẳng từ mục tiêu xuống đặc tả chức năng. Hệ quả xuất hiện muộn, thường ở UAT: hệ thống làm đúng những gì tài liệu viết, nhưng nhóm kiểm soát nội bộ không ký được vì không có nhật ký thao tác, hoặc bộ phận chăm sóc khách hàng phát hiện họ không có quyền xem trạng thái hồ sơ để trả lời khách gọi vào.
Những nhóm bị bỏ sót gần như luôn là các nhóm gián tiếp: kiểm soát nội bộ, kế toán, đội vận hành hạ tầng, chăm sóc khách hàng, và bộ phận đối tác bên ngoài. Họ không dự họp kick-off nên không ai nhớ tới họ.
Ai làm, làm lúc nào
BA làm, ngay sau khi có danh sách stakeholder và trước khi viết đặc tả chức năng. Đầu vào là phân tích stakeholder và các buổi elicitation. Đầu ra thường ở một trong hai dạng:
- Theo nhóm người dùng: mỗi nhóm một mục, liệt kê những việc họ phải làm được.
- Theo user story ở mức thô: "Là chuyên viên thẩm định, tôi cần... để...". Nhiều đội Agile viết stakeholder requirement dưới dạng epic rồi mới bẻ nhỏ.
Một cách kiểm tra nhanh độ phủ: vẽ đường đi của một hồ sơ qua toàn bộ tổ chức, xem nó chạm vào bao nhiêu phòng ban. Mỗi lần chạm là một nhóm stakeholder cần được hỏi.
Ví dụ thực tế
Một hồ sơ vay tiêu dùng đi qua bao nhiêu cái bàn trước khi tiền về tài khoản khách? Ở dự án số hoá này, câu trả lời là năm — và mỗi cái bàn là một nhóm phải ngồi hỏi. Ngày thường khoảng 680 hồ sơ mới.
| Nhóm | Stakeholder requirement |
|---|---|
| Chuyên viên kinh doanh | Tạo hồ sơ trên điện thoại tại điểm bán, chụp ảnh giấy tờ, gửi thẳng lên hệ thống |
| Chuyên viên thẩm định | Xem hồ sơ, kết quả chấm điểm và ảnh giấy tờ trên một màn hình, ghi ý kiến |
| Trưởng nhóm thẩm định | Duyệt theo lô các hồ sơ dưới hạn mức được uỷ quyền |
| Kiểm soát nội bộ | Truy xuất toàn bộ lịch sử thao tác của một hồ sơ trong 24 tháng |
| Chăm sóc khách hàng | Tra trạng thái hồ sơ theo số điện thoại khách gọi vào |
Ba dòng đầu ai cũng nghĩ ra. Hai dòng cuối thì thường xuất hiện ở tuần thứ chín, lúc anh phụ trách kiểm soát nội bộ ngồi xuống và hỏi: "Thế ai sửa gì trên hồ sơ, xem ở đâu?"
Lỗi hay gặp
Hỏi mỗi người quản lý rồi coi đó là đủ. Sếp phòng mô tả quy trình như trong quy định, còn nhân viên làm theo cách khác vì quy định đó chạy không nổi. Cả hai đều thật, và BA cần cả hai. Ngồi cạnh một bạn nhân viên nửa buổi, bạn sẽ thấy chỗ nào quy định bị lách, và vì sao nó bị lách.
Kiểu hỏng còn lại: gộp yêu cầu của các nhóm mâu thuẫn nhau vào một danh sách phẳng rồi để dev tự xử. Kinh doanh muốn duyệt nhanh, kiểm soát muốn thêm bước xác minh. Mâu thuẫn đó không phải lỗi kỹ thuật, nó là quyết định kinh doanh, và người phải mang nó lên bàn là BA — càng sớm càng đỡ đau.
Khi bạn nhận ra hai stakeholder đang đòi hai thứ loại trừ nhau, đừng tìm cách viết một câu làm hài lòng cả hai. Viết cả hai ra, ghi rõ xung đột, và đưa vào họp có người đủ thẩm quyền phân xử.
