（刚工作必看）业务需求估期需要注意什么

本期文章主要是关于业务需求估期的思考，或许很多技术同学只关心技术深度广度，但是身在职场，首要任务是把交代的工作按时保质的做好，让人觉得你靠谱了，才有更好成长的可能。

技术同学在整个产品生命周期中纠结最多的除了“这段代码为什么又出bug了”还有就是“这次估期为什么不准”，估期问题不仅是新手程序员做不好的事情，很多老鸟也会在这上面出问题。

估期不准，大部分情况是估期时间偏短，这既是项目质量差的祸根，也是整个团队加班的赶工期的直接原因。综合我自己的经验来看，需求估期有以下部分需要注意。

哪些部分在占用时间

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

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

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