这周继续尝试着使用番茄钟工作法进行工作，出现了一些问题，使我还没有产生条件反射一样的目标工作状态。我针对两周的实践记录，整理了一下实践中遇到的“变数”，我的改变，以及依旧感觉不大舒服的点。

番茄钟频频打断的事件：

1. prod的问题，我们的工作原则是生产环境有问题一定要第一时间放下手头的事情去解决。这样的事情两周发生了两次。

2. 环境清理的任务，一般的support可能能放到下一个番茄钟，但是有一种是application要进行load test然后需要清理环境，虽然好像拖延半小时之内也不是不可以，但是感觉因为自己的事情delay了一组人的测试有点不大合理，所以好多次没有忍住。

3. 冲上门来的support，番茄工作法指导如果有同事有事找你，可以根据事情的紧急程度放到明天的schedule，下一个番茄钟。但是如果同时冲到你的面前问你事情，或者电话打过来，就很难说先让他回去，然后之后再安排讨论。这种情况每天都有发生。

4. 十点五十叫外卖… 这个事件有时会无法回避的出现在一个番茄钟内…

难以估算的时间：

1. 开发时间，书中也有提到估计可能是不准确的，但是不重要，重要的是每一个番茄钟都会有收获。but… 如果遇到了一个不知道为什么发生的开发或者部署问题，有可能几个番茄钟都无法解决，而且当发现问题所在的时候会发现是本不应该的某些操作导致的问题，所以并不会有解决问题的兴奋感。这就会产生一种负面情绪。

2. Email的时间，尤其是关键的回复大佬的Email。一般要经历：自己写 - 自己修改 -同事或者manager verify - 发送 - 可能会有下一个email周期生成。甚至这两周有几次需要我重新写email的情况。有的时候要花几小时的时间在一封email。

3. support时间，因为问题的难度不一样，而且存在变数。比如昨天遇到的，虽然我只需要purge一些request，也就是跑一条sql的事情，但是遇到了transaction lock，只能向他人寻求帮助，最后花了大概半个多小时。

4.会议时间，虽然会议时间一般是固定的，但是由于粒度问题，比如上午还有一个半小时，但是在十五分钟后有一个一小时左右的会议。就无法放置番茄钟了。

任务间的相互影响：

这周的工作主要是针对三个applications，所以如果不同番茄钟要根据优先级决定开发或者support不同项目，就要有环境的切换。其中有一个是在本地运行server的，如果项目处于启动中，会影响我其他support的效率。

这周我做了一些调整

1. 由于上周沙漏模拟番茄钟并不能及时得知番茄钟完成时间，所以这周采取了手机闹钟的方式。但是关键问题还是很难放下手里的工作… 比如：部署到一半的时候，代码还有几分钟就编写完成的时候，测试将要完成的时候… 很多事情可能再需要五到十分钟就可以完成。 虽然书中说可以放到下一个番茄钟中，多出来的时间可以用来回顾反思。但是问题还是：为一个即将完成的工作中间放置一个休息中断值得吗？下一个番茄钟2/3的时间都用来回顾合适吗？所以有的时候我还是会把事情做做完，所以感觉打破了番茄钟的规则…

2. 最主要的问题还是一个事件粒度的问题。我现在番茄钟的规则只用于开发，然后support或者其他事情我觉得是很难通过番茄钟估量的。比如说回答一个问题，可能要花十分钟，一封邮件可能要写十分钟 或者多余一个番茄钟五到十分钟，qa环境的清理… 种种事情都是很零碎的时间，无法成型成一个任务。所以就会出现我每天其实只有五个左右的番茄钟，然后其中可能还会有因为上面提到的事情打断的情况。然后当回顾的时候才发现，其实我的每天大部分时间都是解决问题，分析问题。都是“助人”的事情，能产生累积性效益的工作其实并不多。我又想起了之前看到专注力中提到的，每天的重点要放在有收益的事情上，但是对于以support为主的我而言，实现起来好像并不是很顺利。

总结

番茄钟工作法是一个很好的工作方式，这必须承认。他能帮助我们在固定的时间内集中精力，用条件反射的原理管理自己的精力分布。应该是会提高工作效率的。但是也会发现，实践中很多情况会打破这种习惯的养成。我周末也试过用番茄钟管理作息，感觉就比工作中要顺畅很多。所以我觉得是否适合使用番茄钟，取决于你的角色，换句话说你的时间多少是可以自己把握的。所以我觉得也许相比于support为主的我们，该方法更倾向于developer。