背景：我所在的业务域属于需求较多的业务，每周的需求评审新增需求会超过10+，而我们整个小组也就20人左右，虽然需求有大有小，但对于研发人员的排期是有要求的。

一  日常的工作内容繁杂影响排期准确性

我们的日常工作内容很杂包括开发，沟通需求解决方案，配合测试联调，配合对方研发接口联调，进行功能设计，指导新人，解决线上问题等。有很多工作的耗时很难准确预估，比如沟通方案可能几轮都无法和上下游达成一致，指导新人可能老遇到稀奇古怪的问题，偶发的线上问题解决起来费时费力还要修数据。

二   老的排期方法以及问题

当然我们的需求的增长也是有一个过程的，在早年需求不多的时候，我们的排期方式是按大家的开发时间完成到提测后，再排入并行的另一个需求，并且预留一些配合测试的buff时间，但在需求爆炸涌入后，这个方法彻底玩不转了：

1    新需求设计推进难： 新需求评审后，研发人员不愿介入设计，因为预估buff不足，新需求完成设计文档需要的时间会影响进行中的工作

2    代码质量下降：需求不多的时候，大家有时间打磨代码质量，需求增多后，大家由于并行的事情增多，代码质量下降

3    排期只看到自测：需求多了后，需要更多关注和测试的协同配合，和上下游研发的联调配合，配合方如果无排期或者排期较晚，就会导致我们不能做好联动，影响后续的工作安排

4    需求太多缺乏筛选： 各种需求都来了，都过审了，都要做了，然后都玩不转了

三   思考及改进

发现以上问题后，我们也进行了深刻反思，该如何不被上升，又能让整个节奏慢下来，最终有2个方法：

1   对需求排优先级： 庞大的基数不见得都重要，和产品沟通好，挑出最优先最紧急的需求，优先支持，其他的顺序排，并且不要把开发时间排的太紧张，留足buff

2   关注各环节时间点，合理调整排期：在需求评审完后，我们给出排期后，并非一成不变，我们称这个为预开发排期，只包括开发自测的时间，我们需要产品协调测试反馈测试排期，联调调用方排期，上线时间等一系列时间，并将之固化到我们的研发人员排期中。如果其他干系方给出的排期和我们的后延很多，我们也需要将我们的排期后延，避免我们先开发完，其他方无介入，导致投入产出低的局面

3   排期给出后，关注每个时间点执行情况： 这个很重要，当我们给出对外承诺后一定要确保每个任务的执行人对这些关键时间点是明确的，并确保这些里程碑按时完成， 同时，每个里程碑的时间点，我们也都需要和任务负责人沟通完成情况以及产出，曾经遇到过有同学部署完预发环境后自己不做冒烟验证，导致联调时问题很多，造成工作延迟，这件事也给我们思考，需要把每件事的产出结果列好：

a)  设计阶段： 产出详细设计文档（包括流程图，修改点，接口文档变更说明，自测点说明），和工时，排期

b)  开发阶段：完成功能开发并跑通冒烟测试用例

c）代码评审：和架构师review代码，并产出会议纪要

d)  预发联调阶段：部署完预发环境并跑通冒烟测试用例

通过关注大家的产出结果，保证任务完成情况，并最终交付需求