让前端估时更准确的真实案例分享 -- 立项时给的时间

1,629 阅读4分钟

场景

经常遇到前端估时不准确的情况,本文分享系列第三篇,如何在正式立项确定排期时给出一个比较准确的时间。

红线事项

以下的事情是应该绝对避免的,不然会在项目中后期有严重的延期风险。

  • 接口文档必须在前后端细分后给出,至少是开发周期的前中期,要包括主要的业务接口,业务模型
  • 核心流程的业务逻辑,不同用户等边界情况都必须考虑到
  • ui设计稿,交互稿,90%的部分必须定稿
  • 前后端在系分,以及开发的前期中期,必须就针对可能存在风险的部分进行一定的说明和备案,向项目组,产品说明
  • 项目整理的需求必须是有优先级的,需求的细节上必须是可以调整的,在研发无法实现的情况下,具有一定的选择空间
  • 必须留有buffer的时间,是正常开发时间的30%-50%
  • 每天进行一些进度的确定,及时调整优先级和后续方案

日记中加入话题

image.pngimage.png

评估时间

  • 样式部分 : 1.5 d (话题标签样式,话题选择模态页,日记发布成功后页), 细节上的点
  • 业务逻辑部分: 0.5d 话题显示字段,查询话题分类以及列表接口,提交日记
  • 数据模型:0.5d 话题的不同分类,状态对显示以及业务逻辑的影响
  • 产品交互与页面 跳转:0.5d
  • 接口联调:0.5d

保证基本逻辑顺利的情况下,上述的功能需要 4 天,加上buffer,应该在5.5天左右 。

另一个案例:个人主页就加一个关注话题的入口

比如,在一个相对不熟悉的小程序环境下,针对一个个人关注的页面添加一个话题入口,看似就是一个div的显示,都不用请求接口,但实际上坑点非常多 。 做下全量枚举:

  • 需要找到这个页面的入口
  • 实现ui组件
  • 查询话题关注状态
  • 制定话题列表的入口,点击实现跳转
  • 不同tab切换时是否更新
  • 从列表返回时是否更新
  • 顶部双击时是否更新
  • 部分素材使用图片还是图标
  • 组件的调用与通讯方式

熟悉的情况下,2-3小时;不熟悉的情况下,建议评估时间 0.5天

基本原则

让精准的估时成为标准

相比短时间的快速交付带一堆bug和资源调动,准时交付更为重要,我们要保证一个功能点上有足够的时间处理各种问题,而不是粗略觉得这个事情很简单,就是1-2个小时的事情,尤其是toC的业务,一般情况下设计稿和交互稿都会比较严格,会有多项的细节考察。

所以不要担心别人说你做东西慢,在保证质量的情况下,慢一些没有什么问题,有问题的是让别人对你过高的期待,然后无法兑现。

用buffer的时间去保证质量

buffer的时间不是用来降低工作压力的,反而是让大家增加工作压力的,在有缓冲时间的情况下,我们要尽可能完善细节,讨论细节, 做整体架构、性能的优化,保证整体的交付质量,为下次迭代提供良好的代码、文档。

去设计些什么,为以后磨刀

相比一味的低效的写重复代码,我们要注重维护一些逻辑的、组件的高效方式,使用方式。

经过对某些场景、业务、项目的积累,在做积累性质的迭代时,我们的buffer的比例应该越来越小,同样的类似的需求交付时间应该越来越短,给出越来越符合标准、快速交付的技术产物。

而这些设计,思考,也应该成为前端评估的一部分。比如你觉得这次需求中某些部分相似,或者这次与上次的某些相同,那么就要细分的时候提出,前端有抽离公共组件的一个细分工作,这很重要。

相关文章