Unlimited Design & Technology

Triển khai dự án

Dùng retrospective để cải tiến cách phối hợp

Retrospective cần tạo thay đổi có thể thử, không chỉ thêm danh sách bức xúc. Dùng sự kiện quan sát được để chọn một thỏa thuận phối hợp, thiết kế thử nghiệm nhỏ và xem hành vi mới có hữu ích không.

UDT Insights16/05/2020
Hai đồng nghiệp chuyển bảng retrospective thành thỏa thuận chung thể hiện bằng cái bắt tay. Người điều phối giơ bàn tay mở.

Nhóm có thể bàn đi bàn lại cùng một khó khăn bàn giao mà không đổi cách làm. Retrospective, tức buổi nhìn lại để cải tiến, hữu ích khi quan sát dẫn tới thỏa thuận phối hợp cụ thể để thử. Thỏa thuận cần mô tả hành động trong điều kiện rõ ràng, không phải mong muốn như “giao tiếp tốt hơn”. Hãy bắt đầu bằng một vấn đề phối hợp lặp lại mà nhóm thực sự tác động được.

Chuyển lời phàn nàn thành sự kiện quan sát được

Hỏi điều gì xảy ra, bước bàn giao hỏng khi nào và thiếu thông tin hoặc quyết định gì. Tách sự kiện khỏi suy đoán về ý định đồng nghiệp. Ví dụ hữu ích là yêu cầu rà soát tới sau giờ làm của người nhận và thiếu bản dựng đã thử, không phải nhận xét ai đó không hợp tác.

Scrum Guide định nghĩa Sprint Retrospective là cách lập kế hoạch tăng chất lượng và hiệu quả.[1] Phạm vi xem xét cũng gồm tương tác, quy trình, công cụ và Definition of Done.[1] Khuyến nghị ở đây là chuyển việc nhìn lại thành thay đổi hành vi nhỏ, thay vì danh sách hành động không giới hạn.

Viết thỏa thuận có thể đem thử

Mô tả điều kiện kích hoạt, hành động mong đợi, vai trò chịu trách nhiệm và đường xử lý ngoại lệ. Thống nhất nơi lưu quy tắc cùng thời điểm xem lại. Phân công người hỗ trợ thử nghiệm diễn ra, nhưng không buộc người đó chịu trách nhiệm duy nhất cho hành vi của tất cả thành viên.

Kiểm tra đề xuất bằng các câu hỏi sau trước khi áp dụng.

  • Thỏa thuận có giải quyết sự kiện nhóm thực sự quan sát không?
  • Mọi người có biết khi nào phải thực hiện hành vi mới không?
  • Hành động mong đợi có nằm trong thẩm quyền của nhóm không?
  • Bằng chứng nào cho thấy cải thiện hoặc vướng mắc phát sinh?
  • Khi nào nhóm sẽ giữ, chỉnh hoặc dừng thử nghiệm?

Ví dụ giả định: bàn giao rà soát muộn

Trong ví dụ giả định về dịch vụ tài liệu, người rà soát nhiều lần nhận thay đổi mà không có bản xem trước dùng được. Nhóm thống nhất mỗi yêu cầu phải kèm liên kết xem trước, hành vi dự kiến và các kiểm tra đã làm. Nếu chưa có bản xem trước, người gửi phải nói rõ đang xin ý kiến thiết kế, không xin duyệt triển khai.

Tại buổi nhìn lại tiếp theo, nhóm xem một mẫu yêu cầu và hỏi người rà soát có bắt đầu được mà không cần làm rõ không. Nhóm cũng kiểm tra việc chuẩn bị bản xem trước có gây chậm không cần thiết không. Thử nghiệm có thể cần chỉnh nếu sửa câu chữ nhỏ nay phải chuẩn bị như thay đổi quy trình phức tạp.

Tách học hỏi khỏi đổ lỗi

Thỏa thuận phối hợp không giải quyết được thiếu thẩm quyền, thiếu năng lực kéo dài hoặc phụ thuộc do tổ chức khác kiểm soát. Ghi giới hạn đó và chuyển tới người chịu trách nhiệm phù hợp. Đừng trình bày quy tắc trao đổi cục bộ như lời giải cho vấn đề cơ cấu.

Quá nhiều thỏa thuận có thể thành quy tắc không ai theo. Bỏ quy tắc lỗi thời và để bộ đang dùng ở nơi dễ tìm. Chọn một thử nghiệm sau buổi nhìn lại tiếp theo, giải thích cụ thể cho mọi thành viên nó đổi công việc ngày mai ra sao và dành thời gian cùng nhau xem kết quả. Cuộc họp chưa thực sự đạt mục đích chỉ vì danh sách hành động đã có người phụ trách.

Tài liệu tham khảo

Trao đổi về dự án của bạn

Cùng UDT xác định nhu cầu và bước triển khai tiếp theo.

Liên hệ UDT
Zalo