KPT(KeepPloblemTry)是一个通过反思加速改善工作和项目的框架。
在我们的工作过程中，我们经常有机会 “回顾我们所做的事情”。 可以是在年底的年终总结，当我们设计新的目标时，或当一个项目已经完成时….。
在这些时候，我们倾向于在会议上盲目地分享我们的意见，结果却遭到了”那我们下一步该怎么办?”。
这时候我们可以使用KPT框架，KPT是一种分析当前形势和确定下一步需要做什么的方法。在这篇文章中，提示KPT组成因素，实践时的注意事情。
KPT是由Keep,Problem,Try组成的框架
KPT框架是Alistair Cockburn在他的 「Reflection Workshop」中提出的 「The Keep/Try Reflection」。将反思分为以下3个因素。
- What we should keep.
- Where we are having ongoing problems.
- What we want to try in the next time period.
对上面的3个因素理解为。
- K: keep=做的好的事情(今后也要保持/持续做)
- P: Problem=做的不好的事情(今后不要做)
- T: Try=下一步要挑战的事情
KPT使用工具
比如在会议室中举行KPT时，可能需要如下工具。
- 白板
- 便签
- 笔
当我们远程工作时，就需要像Excel这样的工具。
如实进行KPT
通过坚持做KPT，让我们一直处于”改进”的状态。然而考虑KPT的质量也很重要。
Keep
- 我们所展示的价值，从改进获取的成果等，即使成果很小但越多越好
- 事先整理好自己所做的工作
- 想一想从客户或者其他人得到的”赞美”
当我们远程工作时，基本上是基于文本的对话，可能无法正确传达你的感激之情。因此，在讨论期间多说谢谢是个好主意。
在这里指名道姓地说谢谢是可以的，例如”谢谢你的帮助，Jhon!”，让我们各抒己见。
Problem
- 「分享问题给团队带来的成果」的意识
- 深入思考”为什么会发生这种情况?”
- 不要责备有问题的人
另一方面在讨论Problem中，最好是讨论整个项目，而不是指出个别问题。
例如，假设我的老板对我说：”我已经厌倦了你的代码，它不够好。”
然后发生的事情是，第二天我得到一个神秘的胃痛…….。
上述情况或许夸张，但提到个人的名字也会让人对实施KPT感到不乐观。这种场景1对1的方式应该更适合。
即使有一个与个人有关的问题，也最好说 “负责该项目的工程师之间的代码质量有差异”。从那里，你可以提出这样的建议：”那么，我们可以做什么来改善整个项目?”然后我们可以提出一个建议，比如”我们可以为整个项目做什么样的改进?”
Try
- “我会注意”或”我会尽我所能”是不够的，关键是要有具体的Action(行动)
- 从”Keep”当中寻找 “能够再进行改进的事情”
- 从”Problem”当中思考 “解决问题的方法”
- Try指定期限
- 牢记做 “Try目的”
在这里特别提示一下期限的问题。如果KPT周期是1个月，那么应该设定在1个月内完成的Try。
如果我们在1个月的KPT中设置了一个需要6个月才能完成的Try，那么这个Try将保持5个月，我们可能会失去动力，因为觉得 “尽管我们已经做了KPT……，但不觉得正在解决这个问题”。
KPT的目的不是做一次就完事了，而是定期做，以改善项目。我们应该有更多的耐心。
如果有一个问题要到KPT之后的6个月后才能解决，我们能把这个问题分成“让我们在下一次KPT之前解决这个问题”，那就更好了。
小结
工作中学习框架是非常重要的，对于个人或者团队来说KPT是一个非常有效的框架。希望在付诸实践中，能获得意想不到的效果。