前端工时分析

1.为啥评估会不准确

以下状况大家都遇见过没

功能	估算时间	自己所想过程预估	遗漏点	实际时间
加个字段	3分钟	上次写过，CV一下就好,就改改字段名称	1. 拉取最新的代码，检查开发环境，运行代码。 2. 找到具体页面，查看代码上下文，或许还涉及样式的修改。（这里加了新字段后端也得给接口加，还要联调），自测。 3. 自测后发布测试，还得通知测试测试	2小时
做个只展示数据的纯列表页面	1小时	引入组件后，只要把后端的字段显示出来就好了	1. 后端开发这个字段可能关联四五个表单，还要处理数据，写接口文档 2. 然后前端还得查看后端接口文档，看哪些字段需要额外处理，最后还得自测，甚至可能在真正对接前，需要自己造mock接口（这里是有对应组件的情况，可能没有直接可用的组件时间要更长） 3.提测，协助测试测数据是否有问题	8小时
编辑/新增界面	8小时	做一个表单，加个校验，字段配置正确就好	1. 需要理解业务逻辑，需要做数据校验，对于类似下拉数据，图片上传，可能还要和后端沟通，数据从哪里取，分别表示什么意思，怎么上传图片，提交数据后，成功后要怎么做，以及失败的异常处理。 2. 用户刷新界面，许不需要时时保存输入数据，做怎么样的处理。	3天
一个响应式界面	8小时	写一个响应式的就是rem形式的，没什么难的	1. 响应式页面需要设计师设计 2. 还有前端要写样式已经对样式的处理	3天
切换中英文	1小时	组件切换一下就行，没啥多余的代码	1. 自己写的组件哩怎么改 2. 布局的影响哩 3.提示语怎么处理	4—5天
做一个图表	2小时	直接用组件，处理数据就好啦	1. 数据转换可能是个大工程，考虑各种情况 2. 可能组件没有对应的图表样式，要自己造 3.可能组件没有这种图表，需要去找其他的图表库	4—5天
写一个类似项目已有的界面	3小时	代码复制过来，改字段和接口就可以了	1. 界面一样，但业务逻辑不一样，要改交互形式哩 2. 字段可能不一样，校验逻辑也可能不一样 3. 后台数据类型不一样，处理方法也不一样	和上个页面一样的时间，可能还要多花时间
做一个别的网站类似的效果	2天	看看怎么实现的，去CV一下。	1. 可能没有源码 2. 没有样例，可能是网站的前端自创的组件	5—6天都不一定能完美复制
公司项目交互界面复制到自己项目	1天	CV一下改改字段应该很快	1. 框架不同怎么办哩他用React,你用Vue 2. 源代码有权限，你不能查看 3. 技术盲区，不能实现一样的效果	一个星

前端估算工时的原则可以总结如下：

1. 精细化评估：
   • 不应一次性对整个界面或模块进行评估，而应对行列、表单项、逻辑点等细节进行评估，然后将这些时间累加得到整体预估工时。
2. 合理预估时间：
   • 考虑到实际工作中的干扰因素（如被打断、开会、思考时间等），应将一天的工作时间最多算作6.5小时。
   • 评估时应至少多估20%的时间，以应对可能的不可预见因素。
3. 深思熟虑后评估：
   • 不要在初次了解需求后立即评估工时，而应先深入思考实现逻辑、重难点等，尽量不要当天给出工时评估。
4. 考虑公共组件：
   • 有公共组件和没有公共组件完成同样的功能，所需时间可能天差地别。因此，应确保先完成公共组件的开发。
5. 工作拆分：
   • 将业务逻辑理顺，把工作进行拆分，直至自己能够正确预估的范围内。
6. 考虑不同平台：
   • 对于不同平台（如移动端APP、H5、小程序、PC端等），单个功能点的交互开发工时可能有所不同。例如，移动端单个功能点工时 = 复杂度系数（1、2、3）* 1h，而PC端单个功能点工时 = 复杂度系数（1、2、3）* 2.5h。
7. 考虑测试时间：
   • 测试工时通常基于开发总体天数计算，如测试工时 = 开发总体天数 * 0.8（上下有20%浮动可调）。
8. 项目总体工时：
   • 项目总体工时总和工时 = 开发总天数 * 2.5，包括验收及相关上线总体时间。
9. 给别人评估工时：
   • 如果是给别人评估工时，应尽可能多评点工时，以避免后期出现时间不足的情况。
10. 记录与对比：
    • 平时多记录自己的工作情况，如一个功能耗费了多少开发时间、优化时间等，以便在后续任务中更准确地进行工时预估。同时，将预估时间与实际用时进行对比，以提高预估技能。

通过遵循以上原则，前端开发可以更准确地估算工时，提高项目管理的效率。