项目倒排，跟工期不足say byebye~

项目倒排：预先指定项目的上线时间，要求项目在指定的上线时间之前必须上线；

相信小伙伴们在工作中对项目倒排应该并不陌生；倒排的项目常常会使开发和测试同学感到不适，带来相应的工作压力，原因在于倒推的可能时间并不足以支撑开发和测试同学完成相应的工作。下面我将给大家介绍一下我在工作中面对倒排项目的一些处理方式。

当接到一个倒排的项目，首先我们需要了解一下倒排的必要性。

需求评审的时候通过PM同学，了解一下项目背景以及为什么要倒排，如果不倒排会带来什么样的后果。我们自己可以判断一下理由是否充分，如果理由很牵强，可能只是不方便少量内部员工的使用、或者仅仅开发或产品同学的期望，这种我觉得没有倒排的必要。目前我接触到的必须倒排的项目的理由通常是直接或间接的影响收入（如影响签单量、特殊活动使用如6.18等）。

假定项目确实要倒排，接下来需要评估各个阶段的时间总和是否能够hold住项目的deadline。

阶段如下：需求确定（需求review）+开发排期+测试排期

结合上面的时间，看下能否hold住预期的上线时间，能match上且有大量的冗余，那么OK，这个倒排项目没有任何问题。

如果评估的时间无法满足最终的上线时间，那么我们需要进行内部调整；

需求确定本身占用的时间比较短，几乎没有可以压缩的空间，故调整主要针对开发排期和测试排期两个阶段。调整主要考虑以下几个方案：

方案一：增加人力

增加人力又可以从两个角度来看：

1.开发同学是否可以增加人力来缩短开发排期；

2.测试同学是否可以增加人力来缩短测试排期；

方案二：需求调整

组织三方（产品、测试、开发）会谈，看看是否可以对需求进行精简（砍），优先保证核心功能在预期的时间点上线，辅助功能可延后上线；

方案三：提升效率，合理缩短工期

通过一些手段来合理缩短测试的工期，如利用有效的自动化代替手工进行全量回归、通过脚本降低频繁且繁琐的造数在测试中的占比等等。

以上三种方案的核心思想是通过减少开发和测试同学的排期来缩短整体的项目周期，从而保证项目在期望时间点上线。

另外，在处理倒排项目的过程中还有一些注意事项：

1.面对倒排且时间不够的情况，通常产品同学会希望测试同学压缩测试工期，这个时候立场要坚定，果断拒绝。否则不但测试的过程中会被累的半死，一旦工作比你预期的复杂，那么项目依旧不会如期上线，最后的责任还会在测试同学的身上，所以工期评估绝对不要妥协；

2.工期要预留buffer，如果死压上线的时间点，延期风险会很高，稍微出点问题都可能导致项目延期。建议根据项目的复杂程度合理预留buffer；

通过以上几个方面，其实倒排的项目也就没有想象中那么可怕了。面对倒排项目，测试同学评估排期的准确性也至关重要，假如你不太擅长评估一个大项目的排期，可以采用分治策略的思想，先将项目拆分成几个小点，然后再组装到一起去。