场景
经常遇到前端估时不准确的情况,本文分享系列第三篇,如何在正式立项确定排期时给出一个比较准确的时间。
红线事项
以下的事情是应该绝对避免的,不然会在项目中后期有严重的延期风险。
- 接口文档必须在前后端细分后给出,至少是开发周期的前中期,要包括主要的业务接口,业务模型
- 核心流程的业务逻辑,不同用户等边界情况都必须考虑到
- ui设计稿,交互稿,90%的部分必须定稿
- 前后端在系分,以及开发的前期中期,必须就针对可能存在风险的部分进行一定的说明和备案,向项目组,产品说明
- 项目整理的需求必须是有优先级的,需求的细节上必须是可以调整的,在研发无法实现的情况下,具有一定的选择空间
- 必须留有buffer的时间,是正常开发时间的30%-50%
- 每天进行一些进度的确定,及时调整优先级和后续方案
日记中加入话题
评估时间
- 样式部分 : 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的比例应该越来越小,同样的类似的需求交付时间应该越来越短,给出越来越符合标准、快速交付的技术产物。
而这些设计,思考,也应该成为前端评估的一部分。比如你觉得这次需求中某些部分相似,或者这次与上次的某些相同,那么就要细分的时候提出,前端有抽离公共组件的一个细分工作,这很重要。