这是《落叶》文集里第 129 片落叶，希望你能喜欢，不为别的，只为这份坚持。
【背景】
很多测试新人在工作了半年或一年之后，经常会觉得没什么成长，跟之前的自己相比，并没有什么进步，于是就会对现状很迷惑，自己明明每天都忙忙碌碌的，也很努力的在工作，可为什么还是觉得自己什么都没有学到呢？
【你问】
每天忙忙碌碌，可为什么还是觉得自己什么都没有学到呢？
【我答】
GTD 就是 Getting Things Done 的缩写，直译过来就是“把事情做完”的意思。GTD 的核心理念概括起来就是必须记录下来要做的事，然后整理安排并使自己依次去执行。GTD 的五个核心原则是：收集、整理、组织、回顾、执行。
为什么先说 GTD 呢？因为在 GTD 的理论里有一个核心原则叫做“回顾”，它的本意其实就是让你至少在每周结束的时候，回顾一下自己本周的待办事项，并根据最新的情况进行总结、分析和调整。
理论解释如下：
如果你不至少每天或者只要你有时间就回顾检查，那么你的行动和提醒的列表将会变的毫无用处。以你当时拥有的精力、资源和时间，决定什么是对你来说最重要的事情，然后做。如果你倾向于拖延，你可能会老是做最容易的事情，避免那些难的。为了解决这个问题，你可以一个接一个地做列表上的事情，按照它们的顺序，就象你处理你的收件箱一样。
至少以星期为周期，GTD 要求你回顾所有你比较主要的“行动”,“项目”和“等待”的事项，确保所有的新任务或者即将到来的事件都进入你的系统，而且所有的事情都更新到符合最新的情况。
能对自己的现状产生迷惑，觉得自己在过去的一年中什么都没有学到的人，我想多半是个会做定期回顾的人，就算是没有定期，那至少也会在一年当中的某几个特定时刻，对自己做一次总结回顾吧，比如月度总结、季度总结或者是年终总结。
所以，很多人在工作了三个月、一年、三年，甚至于五年之后，都会经常觉得自己没什么成长，觉得自己跟几年前相比，也没什么进步，于是他们就会心生迷惑，就会感到焦虑，然后，就会开始分析：
是不是我方向选的不对，那我是不是该换个方向呢？
还是 GTD 里的“回顾”原则其实没用，那我是不是该换种时间管理的方法呢？
...
绝大多数时候，这种问题都跟方向无关，也不是方法的错，我们先不说方法本身其实就是根据大量的实践检验而总结提炼出来的一种行之有效的手段。
我们可以先假设“回顾”原则对我们的成长肯定是有帮助的，那问题肯定就出在我们自己身上，不是理解偏差的问题，那就是执行的问题。
我相信很多人肯定跟我一样，不管是不是采用 GTD 这种时间管理的方法在管理自己的工作和生活， 刚开始的时候，我每天都会做回顾，但慢慢地，就会变成隔天做一次，然后就是一周做一次，再往后，就没有然后了。
原因是我那时候所做的回顾，只是对所有待办事项的完成情况做一次回顾，已按时完成的直接忽略，未按时完成的就调整计划，提醒自己在什么时候要赶紧完成了，仅此而已，所以每天都觉得只是在重复做 To-do-list 的调整，并没有什么收获，于是就放弃了。
既然找到了问题的原因，是因为我觉得 GTD 里的回顾没有给我带来任何收获，所以我没有坚持执行。于是我就去思考，那是否可以改进一下“回顾”的方法呢？因为那种逐条逐项的检查，我认为产生不了收益，所以我就想，是否可以在每天结束的时候，从当天的已完成工作中，挑出一项自己满意或者不满意的，进行复盘。
在对这件已完成事项进行复盘的过程中，我们可以把事情的起因、背景、采用的方法、执行的步骤，以及最后的结果都写下来，然后再从头开始审视每一个要素和环节，去客观的衡量和分析，哪些做得好，哪些做得不好，假如换一种思路或者方法，是否结果会更好一些？对于每一个环节，都多做几次这种假设，最终我们可以归纳出一套能取得最优结果的方法或思路，并记录下来，在以后的同类型任务中可以去实践和改进。
复盘的作用已经说过了，再来说说为什么一定要是“每日”呢？这只是一个建议频率，因为我个人以为，现如今是个快节奏的时代，很多时候，不仅仅只靠“质”取胜，也要靠“快”取胜，所以才需要小步快跑，将复盘的频率提到极致。
另外，现在我们每天处理的信息量其实很大，如果你将复盘的频率设为每周或每个月，那你真正能做到复盘的，还是你做复盘那天所做的事情。如果你不信，可以回想一下，你上一周都完成了哪些事情，每一样事情，你是否都能回想起它的起因、背景、采用的方法和执行的步骤？我猜，你大概能记住的也只是从 Done-List 里记录的完成结果吧，对吗？
综上所述，你之所以每天忙忙碌碌的，可还是觉得自己什么都没有学到，就是因为你没有做到每日复盘。我想跟你说的是，在职场当中，虽然知识的学习、理论的实践和经验的积累都很重要，但它们并不是拉开你和其他人的差距的关键性因素，而每日复盘是真正能让你和其他人拉开差距的决定性因素。
《测试路上你问我答》里的 Q&A 2，如果是你要的，甚好！如果不是，你问，我答！
【无戒日更挑战营第八天】
作者简介：14 年测试 + 11 年项目管理 + 11 年团队管理 = 一个测试老兵
