背景
关于如何评工时，我梳理了一下，结合所学的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日才是交差日。(建议这么搞，否则比较复杂)
谁来评
是负责人(通常是技术负责人，懂技术的)一个人评，还是分到小组成员各自评之后进行汇总？
这个看情况，负责人很熟，那就负责人总体来，当然也可以分派给组员评。尤其是工作量巨大的时候，光负责人自己评压力是比较大的，而且有些时候不一定有组员那么熟悉。
通常只叫后端评是不对的，应该要让前端也要参与。尤其是负责人通常是后端程序员不太懂前端需要的时间。
其他注意点
然后还有留有冗余时间，用来应付突发的事情。前后端联调也需要时间，中途也可能需要维护现有系统。
也有可能中途插入更加优先的责任。这个有点没办法，这是普遍的现象。过程有很多时候就得通过赶工(加班)来保证进度。
总结
- 开了产品原型会后
- 负责人先熟悉总体的功能，拆分工作，由各自负责的组员评估自己负责的模块需要的工时，按照 人/天 为单位进行评估。前端开发也得评。
- 负责人收集组员的进度，核对
- 再次分发下去，填写开始和结束时间
- 得到总体的结束时间
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/135201.html
