当需求提出后，我们往往需要给出一个上线时间，要求严格点的，甚至需要给出工时明细，这个时候就需要各位研发同学大显身手，有的是拍脑袋给出一个上线时间，有的是要求业务或者产品同学给出上线时间。这一段时间我们也在搞立项的流程，这里面就需要对项目的工期进行评估，总结了目前我们的做法，供大家参考。

1.工时的构成

从需求提出，到项目上线通常需要经历下面的流程：

技术评审->项目开发->联调->提测->测试->业务验收->上线发布

这一步我们主要是把影响工时的因素给列举出来，当然不是每一个公司都是这样的流程，或多或少都有变化，这里我只是以我们的现状来举一个例子来加以说明。

2.工时的计算

• 技术评审：这一步通常是发生在需求提出后，研发的同学需要对需求做设计，数据库的设计，业务流程的对齐，灰度，降级等等，通常会在需求评审1-2天内做这个事情，也是给大家了解具体业务逻辑细节的时间。

• 项目开发：这一步是工时的大头戏，通常会跨多个域，多个岗位，最复杂的也是这一步，这一步通常需要分解为三部分：

  1. 任务拆分，也就是对需求要进行最细粒度的拆分，拆到自己能控制的地步，以做一个优惠券系统为例：
     • 优惠券模板的分页查询
     • 优惠券模板的创建
     • 优惠券模板的发放
       • 提供圈定用户的查询接口
       • 对优惠券模板库存的控制，需要做分布式锁
       • 将优惠券模板和用户绑定生成优惠券

  拆的越细，工时越好评估，对于功能复杂度我们每个人心里应该有把尺，简单的功能比如一个分页查询，通常不会超过4h，复杂的一个功能点，也尽量让工时能够控制在1天以内就能完成。

  2. 加buffer：buffer是在任务拆分后，对每一个任务加上buffer的操作，不同的研发同学对业务的理解，prd的清晰程度，项目的复杂程度，等等这些都会影响到开发进度，通常我会加一个1.3的buffer，如果需求描述的不够清楚，那可能还要再多加点。
  3. 对齐：后端有后端的工期，前端有前端的，别的域的同学也有自己工期，所以我们要和他们对齐，约定一个统一的时间，通常是需要对齐的同学当中最晚的工期，作为提测时间。
• 联调，开发完成后，前端需要和后端联调，后端也需要和别的域的同学联调，这个时间通常在2天左右。
• 提测：提测需要show case和发布到测试环境等操作，通常需要预留0.5天。
• 测试：测试的工期由测试同学给出，可以按照测试用例的维度进行每一条的评估，也可以按照功能来，进行一个打包的评估。有的公司会要求研测比的时间，比如开发3天，测试1天，这个不同的项目，不同的公司时间肯定是不一样的，所以搞一刀切不是一个很明智的选择。
• 业务验收：通常需要0.5天的时间来做这个事情。
• 上线发布：这个因项目，因公司而异。
  

  3.工期带来的问题

  1. 工时排定后，业务或者产品同学觉得时间太久怎么办？
     

     坚持自己的想法，把每一条任务明细列出来，告诉他们，我们需要做这么多事情，所以任务拆分很重要，也是和他们沟通最好的证明。

2. 你的老板看了工期觉得太久怎么办？

   减少buffer的时间。

3. buffer减少后，他们还是觉得长怎么办？

   两个办法，加人或者砍需求，通常老板会选择加人的做法。

4. 没有办法加人或者砍需求，如何缩短工期？

   加班吧。

5. 如果你评估了一个项目需要15天，而老板们觉得只需要2天，怎么办?

   这种问题比较棘手，建议跑吧。