[转] 番茄工作法适不适合程序员？

在微博上收到一个粉丝关于番茄工作法在实际中的运用问题。如下：

最近我一直在实践番茄工作法，大致就是专注工作25分钟，然后修复5分钟，这30分钟是一个番茄钟。每4个番茄钟修复15~30分钟，依次循环。

实践下来的心得就是：番茄钟不太适合程序员这个工种。比如说：

1，一块功能还没做完，思路在半截，番茄钟到了，休息还是不休息？

2，测试妹子在讨论养猫，我能不参与吗？

3，测试来确认问题，不理人家不合适。

4，产品来确定对接方案，不理的话可能会被打。

5，试用期各种材料给签字。

这些问题怎么破？

这是一个来自于软件工程师关于番茄工作法的疑问，我自己就是程序员，特别适合回答这样的问题。我分成为3个方面来解答。

内部中断

2，测试妹子在讨论养猫，我能不参与吗？

第二个问题属于内部中断。常见的内部中断还有，本来上百度去查一个技术问题，结果查着查着就去看了百度新闻。内部中断源于，不能克服自身对于外部诱惑的抵抗。也就是我们经常说的拖延症。从我的经验来看，工作中的内部中断问题是最好解决：不参加闲聊、不要上网玩、尤其不要参加无聊的吐槽、专注于当前任务。

我的习惯：关闭QQ、关闭微信、手机静音、把百度推荐之类的都关闭掉。实际上在团队里我提倡，大家有事就打电话，或当面找人，而不是通过QQ、微信之类的打字过来，再打字过去。

外部中断

3，测试来确认问题，不理人家不合适。

4，产品来确定对接方案，不理的话可能会被打。

5，试用期各种材料给签字。

以上三项就属于外部中断。工作和学生学习最大的不同就是，工作中一定会和其他同事进行配合，有配合就需要沟通。解决工作中外部中断的方法就是 ：

1，团队中设置合理流程，沟通的事每天先做掉；比方现在提倡的敏捷开发、站会（站着开会）。

2，主动出击。对于开发的需求来自于产品，所以开始开发前仔细阅读产品需求，有疑问提前沟通掉，然后给出自己的开发计划给产品人员。开发出来的产品会交给测试，务必在交付的前找测试人员拿到测试用例，自己先测试一遍。

在公司里，每个人都是流水线上的一环；每一环都有上游和下游，要积极主动的和上下游环节做好沟通工作。有效避免事后沟通，事后被打搅。

当然不可能避免所有外部中断。当有外部请求时，我们第一判断是否是个非常紧急的事情？如果不是，可以先记下个代办事项，稍后进行回复。（我的习惯，每天的最后一个番茄用于处理琐事。）真的是很紧急的事，立刻进行响应，同时记录下一个番茄中断，在当天结束后反思下，下次如何避免类似情况。

精准计划

1，一块功能还没做完，思路在半截，番茄钟到了，休息还是不休息？

番茄工作法非常强调定制任务的精准性。也就是一项任务打算3个番茄完成，是否能做到不多不少正好3个番茄完成。精准性是被很多人忽略的一条规则。大多数程序员的潜台词是，编程是个脑力活动，怎么可能被精准规划好？因为不相信也就从来没尝试过。这里我给出一个框架：

1，清晰了解业务需求，开发范围。

2，充分了解可能的技术难点，开始Coding前扫清技术障碍。

3，规划好技术实现的方案。

4，计划足够细化。番茄工作法的要求，每个任务不要超过3个番茄。一个开发任务需要1天以上来完成，我就会要求他做出足够详细的计划。

5，为测试留出时间。找测试人员拿到测试用例，发布前自己测试一遍。从测试角度

我经常在团队里说的，程序员当坐到电脑前那就要开始不停的写代码，而不是一会去找产品确定需求（在接任务前就应该确定好），一会思考实现方案（利用暗时间进行思考），一会发现有个技术难点（前一天完成就应该找到答案）。如果都已准备就绪，产出一定能按计划精准发生。

总结

相比学生学习，职场人面对不同的场景。但并不意味着番茄工作法就不适用了。实际上，我发现学生是番茄工作法的最大人群，职场人很少在用。

内部中断、外部中断、计划精准这在番茄工作法手册里都提到过。大多数人在使用番茄工作法前都没有仔仔细细阅读过手册。

番茄工作法是个目标管理系统，强调劳逸有节奏推荐，让结果能在目标上下浮动，不会太离谱；番茄工作法也是个人的进化系统，不断从每天的反思、总结中提升自己的工作效率。

也是个