认识达内从这里开始

程序员加班可以说是互联网中非常常见的一个现象了，而大部分的程序员本身是不喜欢加班的，我相信没有人喜欢加班吧。今天我们就一起来了解一下，程序员如何排好自己的项目开发工作时间来减少加班的次数。

一、梳理时间分布

作为主要工作，理想的情况下一天的时间都应该花费在需求研发上，但是各种事情的插入，甚至开发自己的心情变化都会影响需求研发的进度。根据我们团队的工作事项，总结下来研发同学日常的时间主要花费以下几个方面：

需求研发

技术支持(工单、线上问题)

团队事务(指导新人、分享、招聘)

会议沟通(评审、例会、技术咨询)

技术学习

可以说大多数情况下，一个项目的工期进度，受到研发同学在这些维度上的时间分配影响。假设需求研发按照八小时来分配，那么随着其他维度的时间消耗，基本上在工作上的时间要花费是十一个小时左右，而对于在技术和管理中并行的同学，恐怕研发外的事务花费时间更多。同时需要在各个维度上进行思维的切换，这部分切换的时间按照0.5小时来算，那么在工作上的时间基本要达到十二个小时。算上通勤、吃饭、午休，基本要消耗十六个小时。一鼓作气，再而衰，三而竭。久而久之对项目造成严重的风险，对团队管理亦带来沉重负担。

要做合理的开发排期，一步是要摸清楚自己每天的时间分布，然后按照自己的有效研发时间来对项目需求估算工期。打个比方如果开发同学真正的有效率的开发时间是6个小时左右。那么在新的项目中，就以六个小时的开发时间来估算工作量的消耗时间，从而估算出项目的开发周期。

根据多年来经验，对于上述维度的时间分配建议比例是，6:1:1:1:1，这样一天的时间是十个小时，对于互联网工作的同学，这个时间还尚可接受。另外除了需求研发外，其他的事项并不是每天都有或者每天都同时发生，那么省下来的时间，可以放到需求研发或者学习中去。在遇到时间紧张的项目时，可以根据情况砍掉一些项目(比如技术学习)，可以请求其他同事在这段时间内，对一些事务进行支持(比如技术支持、团队事务)

所以做合理排期至关重要一步： 以实际(每天)需求研发时间来估算开发周期

二、预留buffer

工作中经常遇到一些很自信的同学，做排期时不留buffer。可预知的事情是在有事情插入或者遇到技术难题时，这位同学会往往加班加点赶工期的情况下度过，甚至导致项目对外承诺的时间点不成如期完成。所以不管是什么项目，不管是什么段位的技术大牛，一旦在实际项目中工作，预留buffer都是非常重要要的事情。对于buffer的作用无外乎降低项目风险，buffer的预留和使用可以参考以下两点：

总体buffer原则是一周预留一天

项目版本迭代建议也预留部分buffer

UI走查建议使用buffer时间

三、管理依赖

需求某个事情完成才能进行的工作就是我们的依赖项。一个项目难免在项目成员或者对外部团队产生依赖，依赖完成的时间和质量都会产生项目风险。对于依赖的管理也会影响我们的开发排期甚至是整体的项目进度。根据经验依赖管理主要有以下两方面

依赖项完成时间点

规划联调时间，一个依赖建议1-2天

对于二条要特别重视，很多情况下在项目排期时容易忽略联调时间，想当然以为依赖项在这个时间点给出的是一个稳定的输出。导致后期发现问题反复沟通修复，延误项目进度。

四、测试与复查

项目进行到尾期需要进行测试工作，在这个过程中还有两部分工作：产品复查部分细节逻辑合理性，UI走查设计同学确认交付产品满足视觉要求，但是这两部分都可以放到测试阶段来做。

测试阶段工作，对于开发来说主要是部署环境和修复bug。同时这部分时间还受产品逻辑的复杂度影响，在这阶段如果没有足够的时间来进行测试覆盖和bug修复，对产品项目来说同样是不能交付的产品，项目风险极大。测试与复查时间的分配可以参考以下几点：

周版本大概1-2天

两周版本大概2-3天

月版本建议4-5天

产品复查使用测试时间

UI复查使用测试或者buffer时间

另外为什么测试时间这么重要，因为有些依赖项即使跟他联调成功后，输出的依然不是稳定产品，因为他们根本没有QA介入，只是简单的自测!

同时遇到项目周期超过三个周的项目，后是拆分迭代版本，每个迭代都有一个输出成果，同时对每个迭代的输出成果单独测试。对每个迭代的测试bug，只修复严重问题，其他问题可以在项目后续开发中修正或者在整体的bug修复时间进行修复。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。