时间评估
需求评审
- 了解需求故事(背景)
- 为什么要做这个需求
- 领导要求
- 线上用户反馈
- 为什么要做这个需求
- 明确需求价值
- 需求能带来什么收益(用户体验改善、PV增加…)
- 针对多个需求让PM确定优先级
- 了解项目平台
- web
- 桌面客户端
- Native
- 确定deadline
- 针对技术难点，提出技术调研需求
方案调研
- 针对技术难点进行调研评估
- 组织相关会议评审确定可行性
需求评估
- 需求评估其实就是在确定的deadline时间中找出可以满足的需求
- 通过需求了解阶段获取的信息，评估相关需求的合理性，不合理的需求可砍掉
- 待砍需求特征
- 现有技术栈无法实现或需要花费较长时间实现导致项目延期的需求
- 需求价值不高
- 明显无法产生收益的需求
- 花费较多成本但收益较低的需求
- 优先级较低的需求
- 保留的需求按照优先级排期
方案设计
- 产出详细设计方案
- 前后端接口定义
- 组件定义
- 一般包括设计文档和相关UML图（类图、时序图、活动图必须有）
- 邀请相关人员对方案进行评审
实现
- 参照详细设计方案编码实现
- 若发现有偏差及时调整设计方案并组织评审通知相关影响方
前端实现排期
布局
- 布局及交互一般需要等UI图出来才能准确评估
- 前期可以参照需求文档做个粗略评估
- 评估依据
- 是否有现成组件，修改是否方便
- 自己实现难度如何
- 正常情况下可按照一个页面平均1人日来评估
- 若有特殊兼容性要求，可酌情增加时间
- 评估依据
交互
- 交互可分为数据交互和动效交互
- 数据交互，同接口交互
- 入口数据
- 针对接口返回数据做必要校验、格式化等
- 业务数据
- 根据业务流程进行相应转换流转
- 出口数据
- 提交给接口的数据需要校验(表单验证、提交数据整理等)
- 入口数据
- 动效，同用户交互
- 未出UI图时，可按照一个页面平均1.5人日来评估
数据展示
- 将数据绑定到视图上
- 此部分一般按一个页面平均0.5人日来评估
联调
- 接口联调、端联调
- 乐观情况下，可按照一个页面平均0.5人日来评估
- 悲观情况下，按照一个页面平均1人日来评估
自测
- 预留自测时间
- 确定是否有需求细节遗漏
- 实现是否满足需求要求
- 一般评估为1人日
- 展示、交互、兼容性
buffer时间
- 预留填坑时间
- 一般为总时间的
0.2或0.3 - 例如正常实现时间需要10人日，则可预留2到3天做为buffer时间
调整排期
- 及时调整排期，应对突发情况
- UI、接口发生变化
- 后台服务不可用等等各种不可预料的情况
总结
- 尽量悲观评估，给自己保留充分的缓冲时间以应对意外情况
参考
https://www.zhihu.com/question/21109935/answer/217940281
https://www.zhihu.com/question/28461584/answer/40971581