KPT (KEEP – PROBLEM – TRY) – Những điều cần biết

Khi nói đến phương pháp Furikaeri (振り返りの手法), nếu tìm hiểu qua các kênh như Websites, sách báo hay tài liệu, chúng ta sẽ tìm được từ khóa “KPT”.

Nếu bạn có một tấm bảng và những tờ sticky notes, tôi nghĩ nó sẽ rất thú vị nếu bạn thử nghiên cứu nó bằng việc sử dụng KPT.

Có rất nhiều tài liệu viết về khái niệm và cách thực hiện phương pháp này, vậy thực sự KPT là gì? Làm quen với KPT như thế nào và những điều thú vị về KPT, hãy cùng tìm hiểu qua bài viết dưới đây.

1. KHÁI NIỆM KPT:

KPT là từ viết tắt ba chữ cái đầu của “Keep – Problem -Try”, là một phương pháp review (furikaeri) phổ biến ở Nhật Bản.

Phương pháp này đi theo 3 trục hoạt động: vì đã tốt rồi nên muốn tiếp tục làm theo nữa (Keep).

Vì là vấn đề (issue, trouble) nên tương lai muốn bỏ đi (Problem), kế tiếp muốn thử làm (Try).

Đặc trưng chủ yếu của phương thức này là:

• Đơn giản nên dễ hiểu, dễ nắm bắt
• Dễ làm quen, dễ dàng tham gia

Cụ thể về 3 từ KPT có thể hiểu như sau:

1.1. KEEP:

Đây là những ưu điểm, những tác động tích cực vào team giúp team hoàn thiện công việc tốt hơn, được khách hàng khen ngợi hoặc đơn giản là giúp mọi người làm việc thoải mái hơn.

Ví dụ:

– Sếp vừa mới cấp Macbook mới cho toàn bộ team (Tác động tới tinh thần).

– Bạn A mới phát triển được 1 thư viện giúp mọi người làm việc nhanh hơn (Tác động làm tăng hiệu suất).

– Bạn B mới training kỹ thuật mới cho toàn bộ team (Tác động làm tăng hiệu suất).

Có thể thấy 3 ví dụ trên có tác động tích cực đến năng suất và tinh thần làm việc của cả team.

Rõ ràng nếu những điều này được phát huy trong các sprint tiếp theo thì team sẽ ngày càng phát triển.

1.2. PROBLEM:

Đi ngược lại với keep chính là problem, đây là những vấn đề nhức nhối có tác động tiêu cực, gây ảnh hưởng tới chất lượng công việc.

Ví dụ:

– Team front end tốn khá nhiều thời gian test mà bug vẫn nhiều (cản trở hiệu suất).

– Team back-end rất hay thiếu comment code (cản trở hiệu suất + chất lượng sản phẩm).

– Server tuần vừa rồi hay bị hỏng hóc (cản trở hiệu suất).

– Điều hòa hỏng, phòng hành chính mãi chưa chịu sửa (Môi trường làm việc ko tốt, ảnh hưởng tới hiệu suất và tinh thần).

1.3. TRY

Try có nghĩa là cố gắng, tiếng Anh dịch là vậy nhưng trong mô hình này nó có ý nghĩa là các giải pháp để khắc phục problem.

Như trên đã đưa ra 4 ví dụ về problem, vậy giải pháp để khắc phục những problem đó là gì ?

Đây chính là Try. Cụ thể 4 problem trên tương ứng với 4 try dưới đây:

2. CÁCH ÁP DỤNG KPT

Cả team tổ chức họp và phát cho mỗi người vài tờ sticky note và 1 cái bút. Mỗi người ngồi im lặng trong 5 phút và bắt đầuviết ra những vấn đề liên quan tới Keep, Problem, Try.

Bạn có thể sử dụng màu sắc của sticky note để dễ phân biệt.

Về nguyên tắc thì bạn có thể tự đặt ra, ví dụ mỗi người tối thiểu 2 keep, 2 problem, 2 try và nếu ai đó có quá nhiều Keep, problem thì chỉ chọn những

điều đang có vấn đề nhất. Sau khi cả team xong việc thì dán lên bảng, nếu không sẵn bảng thì có thể dán lên tường hoặc bàn họp.

Sau đó cả team sẽ stand up meeting để chọn ra những keep tiếp tục phát huy và những problem-try để khắc phục. Đây chính là quá trình cải tiến liên tục sau mỗi sprint.

Ở lần retrospective kế tiếp team có thể xem lại retrospective đợt trước xem đã làm được những gì, có cải thiện được nhiều không ?

Cái gì lần trước ko làm được thì lần này tiếp tục làm hoặc đưa ra giải pháp (Try) tốt hơn.

3. CÁC BIẾN THỂ CỦA KPT

KPT được xem như một cách chạy retrospective cho scrum team. Ngoài KPT, có nhiều phương pháp thực hiện retrospective khác như:

• Happy/Sad (những gì làm team “thoải mái” và “buồn”, đây là template khá đơn giản và dễ áp dụng)
• Mad, Glad, Sad
• Good Point/Bad Point/Improvement (Điểm tốt, điểm xấu, điểm cần cải tiến)
• Phân loại: What did we do well?/What should we have done better?

4. NHỮNG VẤN ĐỀ GẶP PHẢI KHI SỬ DỤNG KPT

Nếu KPT quá thiên về mặt kỹ thuật hay những những khía cạnh “cứng” nói chung của dự án mà không chú ý tới khía cạnh mềm, hoặc sự tương tác giữa con người và con người sẽ gây ra hệ quả không tốt.

Đặc biệt, việc thiên về “P” (problem) quá nhiều có thể gây ức chế cho team members, đặc biệt nếu đó là những comment từ cấp trên hoặc từ người có ít thông tin về dự án.

Vì vậy, khi sử dụng phương pháp này cần chú ý đến việc dung hòa cách sử dụng giữa các yêu tố để tránh gây những tác động không tốt.

5. ĐIỂM MẤU CHỐT CỦA KPT: TỪ NHỮNG KINH NGHIỆM HÀNG NGÀY

Rất quan trọng để biết những điều được viết trên sticky notes có phải điểm cốt yếu hay không. Việc viết những điều cần lưu ý một cách ngắn gọn cũng là điều cần thiết, nhưng hãy nhớ rằng viết càng ngắn gọn, càng đơn giản càng tốt.

Nói cách khác, khi bạn cảm thấy mình đang thực hiện “Keep” và “Problem” xảy ra ở nơi làm việc với công việc hàng ngày của chính bạn, bạn nên viết notes. Sau đó bạn sẽ tìm ra cách giải quyết Prolems sau khi động não và nghĩ đến các trường hợp “Try”. Một điều rất đáng ngạc nhiên là đôi khi chúng ta sẽ cảm thấy khá khó khăn trong việc viết những vấn đề hàng ngày mà chính bản thân mình gặp phải. Tuy nhiên, mọi điều đều sẽ có cách giải quyết, miễn là chúng ta đủ kiên nhẫn để nghĩ ra hướng đi/ giải pháp tốt nhất, và chúng ta đủ kiên trì.

LỜI KẾT

KPT là một phương pháp Review/Retrospective tốt, có lịch sử lâu đời, có thể áp dụng ở mức độ cá nhân hay một nhóm.Những phương pháp review/retrospective khác có phương pháp làm tương tự có thể thay đổi tên gọi “K”, “P”, “T” sao cho nhẹ nhàng và thích hợp nhất với tình hình thực tế. Khi mới bắt đầu, có thể team chưa quen và không lại hiệu quả ngay tức thì. Thậm chí một số thành viên còn tỏ ra ác cảm với cách làm này. Tuy nhiên về lâu dài nó sẽ đem lại lợi ích to lớn, giúp team ngày càng tăng trường về trình độ lẫn năng suất. Bạn có thể áp dụng mô hình này cho bất cứ quy trình sản xuất nào, không nhất thiết phải là phát triển phần mềm hay agile.

Techtalk via viblo