如何评估工时和开发计划

Posted 2021-06-26 石头StoneWang

背景

关于如何评工时，我梳理了一下，结合所学的PMP的知识，写了一篇文章。纯粹做为参考。

我的经验

评工时，首先肯定要明确范围(scope)，就是要明白需求要做什么、做到什么程度。范围越准，结果越准确。

其次要渐进明细，并非评一次就了事。可以在执行中途，比如四分之一、三分之一或者一半时，再评以修正，是需要持续修订的。(不过鉴于实际情况，很难做到多次评)

方法

1、自上而下：能快速评估工时，结果是大概的
2、自下而上：即从小的功能往大的功能汇总，非常准确，但需要对需求非常了解，耗时长。
3、参考法：参考以往类似的项目。这招对于互联网的项目来说几乎没法用。
4、领导法：领导指定一个交差时间，评估是否合理，不合理的再提出意见，或者砍功能。

评工时的单位是什么？

要按 “人/天” 评，还是按照 “现有资源/天” 评，现有资源比如有2个人，就按 “2人/天”。是按哪种？
按照 “人/天” 进行评，评完之后交给组员填写开始时间和结束时间，比如这个功能点是4人天，开始时间是2020-6-1，那结束时间就是2020-6-4

要注意，从2020-6-1~2020-6-4，意思是包含开始和结束当天的，即6-1当天就得开始干活，6-4这天也得干活，6月5日才是交差日。(建议这么搞，否则比较复杂)

谁来评

是负责人(通常是技术负责人，懂技术的)一个人评，还是分到小组成员各自评之后进行汇总？
这个看情况，负责人很熟，那就负责人总体来，当然也可以分派给组员评。尤其是工作量巨大的时候，光负责人自己评压力是比较大的，而且有些时候不一定有组员那么熟悉。

通常只叫后端评是不对的，应该要让前端也要参与。尤其是负责人通常是后端程序员不太懂前端需要的时间。

其他注意点

然后还有留有冗余时间，用来应付突发的事情。前后端联调也需要时间，中途也可能需要维护现有系统。
也有可能中途插入更加优先的责任。这个有点没办法，这是普遍的现象。过程有很多时候就得通过赶工(加班)来保证进度。

总结

1. 开了产品原型会后
2. 负责人先熟悉总体的功能，拆分工作，由各自负责的组员评估自己负责的模块需要的工时，按照 人/天 为单位进行评估。前端开发也得评。
3. 负责人收集组员的进度，核对
4. 再次分发下去，填写开始和结束时间
5. 得到总体的结束时间