业务需求估期需要注意什么

转一篇文章：《业务需求估期需要注意什么》

技术同学在整个产品生命周期中纠结最多的除了 “这段代码为什么又出 bug 了” 还有就是 “这次估期为什么不准” ，估期问题不仅是新手程序员做不好的事情，很多老鸟也会在这上面出问题。估期不准，大部分情况是估期时间偏短，这既是项目质量差的祸根，也是整个团队加班的赶工期的直接原因。综合我自己的经验来看，需求估期有以下部分需要注意。

哪些部分在占用时间

很多技术同学对估期狭隘的理解为写代码的时间，这是典型的不从用户角度思考问题，站在业务方的角度来说，ta 希望你给出的时间是从你接到需求直到项目完整上线这整个阶段需要的时间，估期准确的必要条件之一是搞清楚从接到需求到需求上线，这期间可以划分为哪些部分，划分清除之后可以让我们可以针对每个部分来做估时，一些不必要的部分也可以直接砍掉节约时间。

上面是从接到需求到需求上线的大致流程切分，每部分也会存在一些问题需要考虑到：

1. 需求分析： 这个阶段要搞清楚的是有哪些功能是可以确定可以搞的、有哪些功能是存在风险可能搞不定的、有哪些功能是肯定没法搞的、哪些功能需要外部依赖等等，这是个排雷的过程
2. 熟悉老项目代码： 如果是第一次接触项目，那熟悉项目技术栈就是非常必要的，提前知道这里面可能涉及到的技术成本，比如 PC Web 开发和 APP 内嵌 web 开发、不同的项目启动方式发布方式的差异，熟悉一下代码可以让我们预知一些技术栈的学习成本，这样子在估期的时候就可以体现出这部分的耗时
3. 技术调研探索： 这部分可能是一部分技术同学容易忽略的，忽略的原因一方面可能是第一步需求分析做的不到位，另一方面可能是比较自信，但是在实际开发中，这部分不做可能会导致在写代码阶段才发现某些功能无法实现
4. 写代码： 这个阶段技术同学都很熟悉，不过我想提两点，一个是不要为了炫技而写一些很难理解的代码，可能初学者觉得代码写的越炫酷代表能力越强，但是随着代码能力的增强，往往会意识到好的代码都是很直白很简单易懂的；另一点是记得写注释，既方便自己也方便别人
5. 自测： 自测往往是在联调之前，在工作中往往会遇到不做自测的人，和 ta 配合的技术同学就沦为了 ta 的免费 QA，这样的人合作起来很难受，我们还是要做一个职场口碑好的人，做好自测
6. 联调： 联调也没啥好说的，保障主流程和修复一些明显的问题，做好问题记录即可
7. 过 Checklist： 在联调阶段或者联调结束，QA 会给出 Checklist，这也是测试阶段 QA 判断是否有 bug 的依据，所以一定要对着 Checklist 一条一条的过
8. QA 测试： 以我的经验来看，这个阶段也会占用一部分时间，需要跟 QA 沟通和修 bug
9. 上线： 做好线上环境的 URL 配置，上线前做好回滚方案

上面这些大概就是占用时间的部分以及每个部分需要注意的问题。

任务拆分的越细估期越准

除过了解哪些部分在占用时间外，对于任务的拆分是否细致也决定了估期是否合理。

对于任务的拆分，需要注意下面几点：

1. 非写代码的工作也需要拆分出任务来，比如和业务方对接时间等等
2. 重合的工作可以拆成公共模块
3. 研发类任务拆分出来的单位时间最好不超过 1 天，这样子估期更准确，并且如果工作量较大也方便加人

细致的拆分功能看似婆婆妈妈，其实这要比拍脑袋凭感觉给出估期好太多，也能体现一个技术人员的专业性。

估期细则

软件开发领域有一个定律叫 霍夫施塔特定律（ Hofstadter’s Law ），这个定律说：项目的实际完成时间总是比预期的要长。 这意味着我们在估期的时候一定要留下 buffer，因为总会有各种事情可能会占用时间，比如：

• 面试、招聘事宜
• 线上问题 oncall
• 例会，评审
• 需求细节可能会变动

诸如此类的问题，也会占用部分研发时间，所以在给出估期时一定要预留 buffer，有一个简单的公式可以参考：

• 需求非常明确并且项目很熟悉：自己的估时*1.2
• 需求可能会变并且项目很熟悉：自己的估时*1.5
• 需求可能会变并且项目不熟悉：自己的估时*2

这只是我的一个简单经验，并不一定适用于每个人，根据自己的情况可以参考

向上暴露风险

如果估期实在是很长，和业务方的预期产生了差异，一定要向上暴露风险，或许有的技术同学会选择默默承受强行缩短工期，但是这样做是埋下了隐患。如果项目按时上线还好，如果项目延期那责任肯定是背定了。

所以估期一定要如实给，有风险可以向上暴露和沟通，估期长不是不靠谱的体现，没能按时上线项目才是。