Đôi điều về KPT (Keep-Problem-Try)

KPT là gì?

Keep-Problem-Try được viết tắt bởi KPT, là một phương pháp review (furiakeri) phổ biến ở Nhật Bản.

K, P, T là gì?

“K” = Keep là những việc tốt nên keep (duy trì) trong thời gian tiếp theo.

“P” = Problem, là những tồn tại (việc xấu) trong thời gian vừa qua cần được giải quyết.

“T” = Try, là những việc cần thử nghiệm về sau này.

KPT tương ứng với giai đoạn “C” (check) trong mô hình PDCA (Plan-Do-Check-Action)

Bối cảnh áp dụng

KPT được khuyến khích áp dụng trong các dự án IT theo kiểu Agile và lặp lại (iterative) hoặc theo mô hình xoắn ốc. Ở đó, các công việc được chia thành các đơn vị (được gọi là iteration hay sprint) khác nhau.

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ách áp dụng KPT

Có thể sử dụng bảng trắng (whiteboard) phối hợp PostIt (giấy dán) (hoặc sử dụng text edior, bảng tính)

Thành viên dự án viết lại cảm xúc, tự review/đánh giá iteration/sprint trước đó và dán lên bảng.

Tiếp theo, team leader và team members đọc và sắp xếp lại những tờ giấy đã dán lên bảng và dán vào cột “K”, P”, “T” tương ứng.

Biến thể khác 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ư

1. Happy/Sad (những gì làm team “sướng” và “buồn”, đây là template khá đơn giản và dễ áp dụng)
2. Mad, Glad, Sad
3. Good Point/Bad Point/Improvement (Điểm tốt, điểm xấu, điểm cần cải tiến)
4. Phân loại: What did we do well?/What should we have done better? (viết rõ bằng bằng plain English cho dễ hiểu)

Áp dụng ở KPT ở đâu khác?

Trên đây là một phương pháp áp dụng KPT cho một nhóm. Tất nhiên, KPT có thể áp dụng cho một cá nhân với cách làm tương tự để tự kiểm kiểm/đánh giá lại bản thân mình.

KPT có thể áp dụng ở dự án IT hay phi IT như là một phương pháp thực hiện review/retrospective nói chung.

Quan ngại về KPT & cách tháo gỡ

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.

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

Tiểu kết

KPT là một phương pháp review/retrospective tốt, có lịch sử lâu đời, bắt nguồn từ Nhật Bản (cite?) 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ể tailor, 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ế.

Tham khảo

1. Ví dụ thực tế về KPT ở Septeni Technology
2. Định nghĩa KPT (tiếng Nhật)
3. Nhận định về việc dùng KPT như là một phương pháp cho retrospective