引言

如果要用一个词来总结我的4月，那么就是两个「加班」。自从去年10月底进入新公司的一个月之后，开始进入全新的项目组进行开发工作。

第一版的任务比较多，一直处于赶进度的状态，去年基本上每天都有在加班。内测版上线的前一个星期我们连续工作了12天（那次周末两天都过来加班）， 直到4月25号内测版上线那天晚上我们加班到第二天凌晨1点左右才下班。那天之后持续加班的日子总算熬过头了。

下面我要总结几条经验和教训：

需求详细设计文档的必要性

首先立项的时候项目需求不是非常的明确，第一个月经常改需求，但是项目只给了2个月的时间，是非常的紧急，在这种需求不明确，还没有需求详细文档的情况下，开发进度肯定是非常缓慢的。 但是一旦产品经理给出需求设计详细文档开发起来会非常快的，我们以前公司产品是不写需求详细设计文档的，只有原型，呵呵。

需求详细设计文档看似是花费了产品的大量时间来编写，但是大大方便了开发和测试人员。如果没有需求详细设计文档，开发或者测试只会按照原型结合自己的思维方式来工作，所以需求详细设计文档保证了唯一性。 测试验收产品的时候也非常方便。

合理的预估开发时间

有一次产品急着要我们评估时间，然后我就没怎么看功能的细节，结果报了1天时间，最后等我去开发的时候，才发现里面有很多坑，1天是不可能完成的。最后因为我的原因没有按照时间完成今进度。

所以开发人员对于时间的预估这个也是非常重要的。需求过来之后首先你要基本预估一下时间，建议你不要很快的给出一个时间，而是仔细看一下需求，把每个需求拆分成最小颗粒的功能点，然后再去预估你开发每个功能点的时间， 最近把每个功能点相加再乘以2就是你的最终开发时间。

不要因为产品给的时间是明天你也给明天，如果你明天还是完成不了，那只会拖累整个项目的进度。一旦拖延次数多了，整个开发组的人都非常的被动。所以你首先要合理的给出 开发时间上报，如果时间产品那边接受不了，可以再商讨一下是不是可以通过加班赶一下进度或者说是否有必要砍掉不是必须要做的功能。

标记优先级

不管是需求还是 Bug 我们都应该标记优先级，标记「必须要完成的」和「可以延期处理的」，然后我们优先完成「必须要完成的」的。

给测试一点时间

到目前为止我们有两次上线的经历，但是为什么两次我们都是转钟1点钟才下班的呢？我认为原因有两点：

  • 进入测试阶段我们还在改需求或者写需求。正常情况下这个阶段应该就是只改 Bug 的，如果你改在写需求或者改需求，那么项目肯定是不能按时完成上线的。
  • 测试时间给的太少。项目上线那天，最迟应该下午把所有 Bug 都改完了，然后就等着晚上上线。上线测试一遍，如果有 Bug，立刻改 Bug。

以上就是这次项目的总结，希望以后工作尽量标准化，拒绝小作坊工作方式，拒绝不必要的加班。