Một kịch bản quen thuộc trong các môi trường Agile: một Product Owner (PO) bị nhấn chìm trong việc quản lý các bên liên quan (stakeholder), bỏ lại phía sau một đội ngũ phát triển với hàng loạt câu hỏi chưa có lời đáp. Điểm nghẽn giao tiếp này có thể dẫn đến sự chậm trễ, những hiểu lầm, và cuối cùng là …
…một sản phẩm không đáp ứng đầy đủ nhu cầu của stakeholder hay kỳ vọng của người dùng.
Hãy cùng nhìn sâu vào vấn đề. Cốt lõi của nó là sự đổ vỡ trong giao tiếp và sự thiếu sẵn sàng. PO, với vai trò là tiếng nói của khách hàng và các stakeholder, đang bị phân tán quá mỏng. Đây không hẳn là lỗi của PO; nó thường xuất phát từ cấu trúc của tổ chức, những kỳ vọng phi thực tế, hoặc sự thiếu hỗ trợ.
Nguyên nhân sâu xa thường nằm ở nhiều khía cạnh. PO có thể đang phải tung hứng với quá nhiều stakeholder có những yêu cầu mâu thuẫn. Có thể đang thiếu một quy trình được định nghĩa rõ ràng cho việc giao tiếp và sắp xếp thứ tự ưu tiên. Tổ chức có thể chưa trao đủ quyền cho đội ngũ phát triển để họ tự đưa ra một số quyết định nhất định. Hoặc đội nhóm có thể thiếu các vai trò hỗ trợ giao tiếp như một Business Analyst.
May mắn thay, có nhiều giải pháp để giảm thiểu vấn đề này.
Chúng ta có thể ủy quyền một phần việc giao tiếp với stakeholder cho các thành viên khác trong nhóm (như một Business Analyst hoặc Project Manager). Chúng ta có thể triển khai các kênh giao tiếp rõ ràng (như các kênh Slack chuyên dụng hoặc các phiên Hỏi & Đáp thường xuyên). Chúng ta cũng có thể xây dựng một product backlog chi tiết và dễ tiếp cận với các user story toàn diện, đồng thời trao quyền cho đội ngũ phát triển để họ đưa ra các quyết định sáng suốt trong một khuôn khổ đã được xác định trước.
Cách tiếp cận tốt nhất thường bao gồm sự kết hợp của nhiều phương pháp.
Việc sắp xếp thứ tự ưu tiên cho các stakeholder dựa trên mức độ ảnh hưởng và tính khẩn cấp là rất quan trọng. Việc triển khai một “vai trò đệm”, như một Business Analyst, có thể giảm đáng kể gánh nặng giao tiếp trực tiếp cho PO. Đội nhóm cũng có thể áp dụng phương pháp kanban để làm rõ và minh bạch hóa tiến độ công việc. Việc tạo ra các tài liệu vững chắc, bao gồm Definition of Ready (DoR) và Definition of Done (DoD) được định nghĩa rõ ràng, sẽ mang lại sự mạch lạc cho cả đội. Giải pháp được chọn phải cân bằng được khối lượng công việc của PO, duy trì sự đồng thuận của các stakeholder, và trao quyền cho đội ngũ phát triển.
