前端需求排期指北

排期，对于前端开发人员来说是一个工作中必不可少的环节，职场人讲究的就是言出必行、说到做到，排期的准确性也侧面说明了开发人员的专业和靠谱程度，如果排期总能估的比较准确，那么也会给人一种靠谱的印象，那么如何才能估准排期呢？下面我们就来聊一聊关于前端排期的种种

为什么一定要排期

相信作为前端萌新，一定会思考过的问题就是，为什么一定要管我要排期？为什么不能先干着，啥时候干完了啥时候提测？

一个完整项目需要很多角色参与，产品经理、设计师、前端开发、后端开发、测试等，而前端只是项目中的一环，项目负责人需要整合了解这个项目的各个节点的时间安排，才能整体对项目的排期做一个规划

因为上级是需要了解项目进展和最终完成日期的，所以规划好所有事情后也好向上汇报，以方便后续安排。

如何进行项目排期

这里只聊前端方面的排期方法

排期时向上汇报通常以天为单位，有些小需求也可能以0.5天为一个单位，但想预估准确，我们排期时就不要按照天为单位，应该以小时为单位给自己拆分任务，这时就需要考虑一个问题，你每天的有效工作时间有几个小时？

我们以以下作息为例

每天早上10点上班，中午12点午休，下午2点开始工作，晚上7点下班

那么每天的工作时间为 2 + 5 = 7小时

新需求来了，你估时为30小时，那么排期为30 / 7 ≈ 5天

但每天7个小时你真的能都投入到项目开发吗？

你有没有想过为什么明明计划5天能做完的事情，但最后却总是需要加班996甚至通宵熬夜才能完成？我总结了一些会影响开发时间的一系列问题

1. 开发时是否经历过被其他线上问题打扰，修复线上问题是否占用了这7个小时中的一部分时间？
2. 上个项目提测后是否还需要跟测？修改上个项目的bug时是否占用了这7个小时中的一部分时间？
3. 上个项目测试通过后需要上线和回归？是否占用了这7个小时中的一部分时间？如果上线后有问题，是不是这7个小时的时间都被用来上线了？
4. 本次需求是否进行了接口评审？没评审之前就给排期，接口和预想不一致时是否占用了这7个小时中的一部分时间去沟通做接口评审？
5. 是否预留了本次需求方案设计时间？
6. 是否预留了本次需求连调时间？
7. 是否预留了本次需求自测时间？如果不做好自测，在做下个需求时，这个需求频繁报bug，是否还会影响下个需求的开发时间？
8. 提测部署代码和环境是否要预留时间？
9. 是否预留了各种开会时间？周会、周报、月会、日会、日报、其他需求评审等，如果没预留，遇到开会占用了一天时间应该怎么处理？不开了？

看了以上这些问题，你还觉得你一天的时间有效工作时间为7个小时吗？

我们假设如下

1. 每天预留半天处理各种线上问题时间（每天有效工作时间为7 - 0.5 = 6.5）
2. 新项目中预留上个项目修改bug时间5小时（本次项目估时 + 5小时）
3. 新项目中预留上个项目的上线和回归时间4小时（本次项目估时 + 4小时）
4. 在开发之前进行接口评审，没评审之前不进入开发阶段（接口不确定，前端无法进入开发）
5. 如果本次需求是新项目，需要预留技术预研和方案设计时间（新项目需要+技术预研和方案设计时间）
6. 需要评估连调时间，这个估时依据主要看后端人员的接口开发质量，前后端都按照接口文档严格开发，后端接口毫无bug，1天就能结束连调，如果一个接口10个bug，那1周也都调不完（主要看接口质量，前端根据之前的经验来估时）
7. 自测很重要，根据需求预留自测时间（本次项目估时+5小时）
8. 提测部署代码是否需要预留时间，这个需要看实际公司情况，有些公司基建很好，部署代码完全自动化，不需要人为操作，当然不需要预留时间，有些公司部署代码需要做很多事情，有时搞个半天都搞不好，这是公司问题，公司要为它买单，所以根据实际情况预留时间（本次项目估时 + 2小时）
9. 首先每天预留1.5小时的开会时间 （每天有效工作时间为6.5 - 1.5 = 5）

再来看刚才的估时

30小时 + 5小时修改上个项目bug + 4小时上个项目上线和回归 + 5小时自测时间 + 2小时提测部署 = 46小时

46小时 / 每天有效工作时间5小时 = 9天

你看，9天才是你考虑到所有情况下给出的你真实的时间排期

总结

以上计算方法并不适用于所有公司，有的公司实行996工作制，午休1小时，每周的工时自然多了很多，有的公司基建好，也可以节省很多提测部署上线时间，大家还是需要根据自己的实际情况来合理排期，最后祝大家都能准确预估好自己的排期，做到心中有数、言出必行、说到做到。