前端工时评估是前端工程师的必修课,但做为一种带有预测性质的行为,工时的评估绝非易事。甚至不少有着多年经验的前端工程师,也难免在工时预估这件事情上栽跟斗,以致于最后不得不拼命加班来弥补预估不许的过失。前端
最近的项目就吃了评估时间不够的亏,开发时间不足,致使加班搞,提测时功能先跑通,小问题留在测试时debug,致使bug巨多。前端工程师
最近思考了不少,总结了下前端工时评估的几点,记录下测试
- 在预估工时的时候,必定要留有必定的buffer,由于项目随时有风险点出现。同时,尤为值得注意的是,项目临时加需求的状况太常见了,几乎没有不临时增长需求的项目。
- 预估时必定要计算一下参加会议的时间,把这些时间刨除在有效时间以外。各类开会,和pm讨论问题,code review。杂七杂八的算下来,天天真正编码的时间没想像的多,按天天8小时算排期,评估天天实际开发的时间。
- 若是视觉设计师、交互设计师给出的内容不够细致,就会有大量的UI上的返工,并且可能出现设计的交付晚于预期的状况,这种种因素势必会对前端开发工做的进行形成影响。
- 统计打点、文案修改这类需求经常在PRD中不会体现,但这都是明显的常规性潜在需求。对这些潜在内容,必需要有所估计。
- 有些需求是一带而过,有时是一句话,有时是几个字,有时多是一个图,等等。在评估的时候,你得把眼睛放亮点,可能这样一个“简单” 的需求,够你作好几天才能搞定的。
- 平时多记录本身的工做状况,好比一个功能耗费了多少开发时间,耗费了多少优化时间,平均天天编码的真实时间有多长等等。
- 接手每一个任务时,先决定你要作什么。而后在开始以前估算任务所需时间。最后测量实际花费时间,并与估算相比较。一样比较你实际完成的与计划完成的。这样你将会既提升你对一个任务包含细节的理解,一样也提升了你的估算技能。
前端工时评估模版,仅供参考;
项目名称: xxxx
前端开发:xx、xxx
总工时:10人日
详细工时: 以下表优化
页面 |
功能 |
UI还原 |
交互逻辑 |
适配 |
联调 |
自测 |
总工时 |
备注 |
首页 |
导航 |
.5 |
1 |
.5 |
1 |
.5 |
3.5 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
合计 |
|
|
|
|
|
|
3.5 |