今天公司里,一个经验很丰富的同事在跟老板开会时预估了开发计划,然而这个开发计划的时间让组内的其他同事感到一丝不合理。下班的路上,几个相对来说开发经验比较丰富的同事便聊起了预估开发计划的事情;
同事A说:预估工时首先依据模块的技术实现定一个时间,然后再在这个时间的基础上适当添加一些时间。同事B说:你们前端的来说实现起来相对简单些,但是后台就不一样了。要开发庞大的数据库后台,首先架构的讨论就是一个很费时间的过程,需要反复讨论修改。然后才是结合产品的需求1:1的来预估开发周期;
听完之后,想想自己在预估开发周期时候,仅仅局限于技术模块的实现时间,并没有将梳理需求探讨需求的时间考虑在内;至于开发前期框架的讨论、搭建、修改更是忽略掉了。
今后在预估工时时:
1-技术模块的实现所需时间;
2-讨论需求梳理需求需求所需的时间(一般情况下一个模块大概需要一天的时间);
3-在实际开发过程中,遇到实际的问题询问产品更改需求又会耗费一定的时间(一般结合项目在总工时上延时2~3天);
4-就是框架的讨论时间(用户量大的前提下才会用到)。
5-测试人员测试、修改bug、及测试环境是否来大姨妈;
综上所述:预估开发计划需要考虑上述所有因素,才能制定出不跳票的上线时间!!!