EN |
VN
“Vâng, phần cuối cùng của buổi Sprint Review…Mọi người có câu hỏi nào không?”
<Im lặng>
<Thiếu những phản hồi rõ ràng >
Bạn có bao giờ gặp trường hợp này chưa? Điều này khiến Product Owner (PO) và Development Team rất khó chịu khi trình bày về phần mềm/giải pháp nhưng không nhận được bất kỳ phản hồi nào! Nếu không có phản hồi, nhóm sẽ không biết được, liệu mình có đang đi đúng hướng và tập trung vào những điều tốt nhất cho khách hàng hay không. Trong khi đó là điều cốt lõi để xác định thành công của dự án.
Sau khi tự mình trải qua những buổi Sprint Review khó chịu như vậy, tôi muốn chia sẻ một số cách giúp bạn cải thiện những phản hồi mà bạn nhận được.
Hầu hết các buổi Sprint Review tôi đã tham dự, cụm từ thường được sử dụng nhất là “Có câu hỏi nào không?” Mặc dù được sử dụng thường xuyên, nhưng tôi tin rằng đây không phải là một câu hỏi tốt để lấy ý kiến phản hồi. Liệu câu hỏi có phải là phản hồi bạn muốn nhận? Mọi người có cần đặt câu hỏi để lên tiếng không? Đối với một vài người, họ cảm thấy hơi sợ hãi khi phải đặt ra câu hỏi hay thách thức điều gì đó để thể hiện sự đóng góp của mình. Hãy thử cân nhắc thay đổi câu hỏi để giảm bớt sự cản trở ban đầu và khuyến khích mọi người thảo luận.
Bạn có thể thử một trong các cách nói sau:
- Có ý kiến gì không (Any comments?)
- Có suy nghĩ gì không (Any thoughts?
- Có phản hồi gì không? (Any feedback?)
- Có thêm đầu vào gì không? (Any input?)
- Có phản ứng gì không? (Any reactions?)
Bạn cũng có thể đặt câu hỏi theo cách giả định rằng, thực tế có ai đó muốn trả lời:
- Ý kiến của bạn là gì? (What are your comments?)
- Quan điểm của bạn là gì? (What are your thoughts?)
Và rất nhiều câu hỏi hiệu quả hơn mà bạn có thể đặt để nhận được những phản hồi sâu sắc:
- Bạn đang băn khoăn điều gì? (What are you wondering?)
- Có điều gì chúng tôi chưa giải quyết không? (Is there anything we didn’t address?)
- Chúng tôi có bỏ lỡ điều gì không? (What’s missing?)
- Đây có phải là giá trị mà bạn hy vọng được nhận không? (Is this the value you were hoping to see?)
Thứ hai, hãy thay đổi phạm vi
Một điều khác giúp các bên liên quan tương tác là thu hẹp phạm vi phản hồi của họ. Thực tế là nhiều người không suy nghĩ kỹ về điều gì đó cho đến khi nó được kích hoạt. Vì vậy, nếu bạn đợi cho đến cuối của buổi Sprint Review mới yêu cầu phản hồi, những người tham gia sẽ “bơi” trong rất điều cần xem xét và không thể trả lời bất cứ vấn đề gì ngoài những ý gần nhất – chính là điều cuối cùng mà họ được nghe trình bày.
Ít nhất sau khi xem từng mục (item) hoặc màn hình của Product Backlog, hãy tạm dừng và đặt một số câu hỏi chuyển tiếp. Cho mọi người cơ hội phân tích và trả lời. Sau một thời gian thực hiện, các bên liên quan sẽ mong đợi điều đó và liên tục xem xét những gì họ muốn phản hồi.
Trung tâm của buổi Sprint Review là các bên liên quan – ngay khi họ bước vào, bạn phải khiến họ cảm thấy, sự kiện này là dành riêng đến họ…. Hãy cho họ biết trước sự kiện với mục đích gì, chuẩn bị sẵn sàng cho sự kiện để không làm lãng phí thời gian của họ, chuẩn bị thức ăn và chào đón khi họ đang bước đến hoặc đang kết nối tham gia vào buổi họp.
Khi bắt đầu buổi Sprint Review, hãy nói trực tiếp với các bên liên quan và cảm ơn họ vì đã đến, cho họ biết rằng sự tham gia và phản hồi của họ là rất quan trọng để đảm bảo sản phẩm mang lại giá trị tốt nhất với ít lãng phí nhất.
Một chiến thuật tuyệt vời khác mà bạn có thể sử dụng sau mỗi Sprint Review là hỏi các bên liên quan xem mình có thể làm gì để giúp họ đưa ra phản hồi tốt hơn. (Nghe giống như Retrospective về buổi Sprint Review phải không?) Tôi đã nhận được một số phản hồi tuyệt vời khi làm điều này, hơn thế nữa điều này làm gia tăng mức độ tương tác của các bên liên quan cho các buổi Sprint Review tiếp theo.
Nếu bạn tập trung buổi Sprint Review vào các bên liên quan và từng bước hỏi họ những câu hỏi hiệu quả trong quá trình thực hiện, bạn sẽ bắt đầu nhận được sự tham gia/tương tác cùng những phản hồi tốt hơn…và kết quả là một sản phẩm tốt hơn được ra đời.
Lược dịch: Trần Lan – Masterskills
Nguồn: Is Anyone There? Improving Feedback in Sprint Reviews
Bản tuyên ngôn Agile – lịch sử hình thành Agile
Trong dự án Agile, công việc ước tính có thật sự cần thiết?
12 nguyên tắc của Agile
Quản lý dự án với Scrum
Scrum of Scrums
Mục đích thật sự của Agile
