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.

KPT tương ứng với giai đoạn “C” (check) trong mô hình PDCA (Plan-Do-Check-Action). Thời điểm để áp dụng việc review (trong tiếng Nhật được gọi là “振り返”(Furikae)) là khi chuyển giao giữa iteration/sprint thứ N và N + 1.

Đặ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:

"Keep" (Những điểm cần lưu giữ, phát huy): Đâ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, là một nguồn động viên, khích lệ thành viên trong team khi đạt được kết quả tốt hay một động lực khích lệ cả team hoàn thành công việc có hiệu quả. Động lực đó có thể đến từ tài chính hoặc một lời khen ngợi, và cho dù có là động lực vật chất hay tinh thần thì nó cũng đem lại cho cá nhân được khích lệ cũng như toàn Team một sự thoải mái cũng như một "đòn bẩy" để các cá nhân cùng cố gắng nỗ lực hơn trong tương lai vì mục tiêu phát triển Team.

Có thể đưa ra các ví dụ như: – Sếp vừa phê chuẩn quyết định cấp Macbook mới cho toàn bộ team (Tác động tới tinh thần). – Nhân viên A mới phát triển được 1 phần mềm giúp mọi người làm việc nhanh hơn (Tác động làm tăng hiệu suất). – Nhân viê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).

Qua 3 ví dụ nêu trên, có thể thấy cả 3 hành động đều tạo ra một 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 (hay những vấn đề) 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, cây để bình nước hỏng, đã yêu cầu sửa nhiều lần nhưng không thấy có hồi âm (Môi trường làm việc không tốt, ảnh hưởng tới hiệu suất và tinh thần).

1.3. TRY

Try có nghĩa là sự cố gắng. Tuy nhiên, 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ề problems, vậy làm thế nào để giải quyết được các vấn đề đó? Việc giải quyết problem được nêu ra chính là Try. Cụ thể 4 problems trên tương ứng với 4 try dưới đây:

2. ÁP DỤNG KPT NHƯ THẾ NÀO?

Để áp dụng KPT, team sẽ tổ chức họp và phát cho mỗi người vài tờ sticky note (với nhiều màu khác nhau càng tốt) và 1 vài cái bút (nên sử dụng nhiều màu khác nhau). Mỗi người sẽ dành 5 phút và bắt đầu viết ra những vấn đề bản thân mình cho đó là Keep, Problem, Try. Bạn có thể sử dụng màu sắc của sticky note và màu của bút để dễ phân biệt đâu là problem, đâu là keep, đâu là try.

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 đã hoàn việc liệt kê Keep, Prolem, Try theo cảm nhận cá nhân của mình thì dán lên bảng (board). Sau đó cả team sẽ tiến hành 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. Ở lần retrospective tiếp theo, toàn team có thể xem lại lần retrospective đợt trước xem team đã làm được những gì, các problem có cải thiện được nhiều không, những điều lần trước chưa làm được thì lần này tiếp tục đưa ý tưởng thực hiện, hoặc đưa ra các giải pháp (Try) tốt hơn và lựa chọn những giải pháp tối ưu trong số các giải pháp được đề xuất. Có thể lấy ý kiến số đông để biểu quyết.

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” (khô khan, khuôn khổ) 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ố K-P-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, sẽ xảy ra trường hợp các thành viên trong team chưa quen với phương pháp này, nghiêm trọng hơn cũng sẽ xảy ra trường hợp có thành viên phản đối phương pháp này. Tuy nhiên, xét về khía cạnh lâu dài có thể chắc chắn rằng phương pháp này sẽ đem lại lợi ích to lớn, giúp team ngày càng đạt hiệu quả cao về trình độ cũng như hiệu quả công việc. 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. Hãy thử một phương pháp mới, bởi càng mới mẻ thì càng đem lại nhiều giá trị.

Bài viết có tham khảo từ nguồn dưới đây:

1. http://hisa-magazine.net/blog/ref/kpt2/
2. https://7bsp1018.wikispaces.com/Retrospective