上图为团队数据月报。它详细说明了每个业务部门产品需求、技能改进情况、bug 修复情况、上线需求总数、需求总数、需求完成率、需求超 5 人天需求数。技术团队对产品团队说，你们需求太多；产品团队表示 ，我们需求并不多，只有 5 个需求，你们都没有统计需求，怎么可以说多。技术团队表示不满意，明明系统都有统计数据。于是产品团队技术说，你们需求总是不能达成。技术团队又不乐意了，他们表示他们需求完成率为 100%，全上线了，即使存在没有上线的需求，但完成数仍保持高的状态。而关于 bug 的修复，观察数据就可以发现质量低的团队，数据都是明确的。

3 找到主要矛盾，针对性的改进

不管是产品提测的问题，或者是研发测的问题，还是整个测试质量的问题，先看数据找到主要矛盾，再进行针对性的改进。我们曾经有过问题测试维度很高的情况，有些部门有三个，有些部门有五个，而一次上线成功的概率低，且上线之后第一时间总是出现问题，还要进行新一轮的修改再上线，于是收集数据、找到主要矛盾、针对改进。

3、加班篇

1 加入技术设计 + 评审环节

业务研发团队压力大，项目完不成，加班情况严重，就会导致项目延期。2016 年，我刚加入 58 同城，曾观察过项目的执行情况。正如许多创业公司会做的，首先产品团队写出需求，之后进行评审，需求评审结束之后，项目产品负责人会咨询技术负责人，评审已结束，需要多长时间完成项目 。技术负责人回复，需求较多，还不能完全消耗，据经验需要四个星期时间完成项目。产品同学立马呈现出不信任的样子，并且表示这么简单的项目，时长期限只允许两个星期。于是产品同学与技术同学对时长期限进行争论，最后约定三个星期完成。

于是技术同学开始做任务，然后发现技术范围比想的还多得多，以为接口已经存在只需调用就好，最后发现却不是，而当时却没有考虑这个问题，可期限只有三个星期，于是赶快开始实现。其实经验丰富的工程师评估时间是较为准确的，而经验不丰富的新手工程师评估能力还有待提高。他们不能在三个星期的期限内完成任务，怎么办？他们不得不再次找产品同学表示他们确实不能在三个星期内办到，产品同学表示需求时间是技术团队自己决定的，不能按期完成，为何还找我们？技术团队那怎么办？加人？从别的部门协调两个人加入团队。

但参加过项目团队的同学都知道，并不是所有加人的项目都可以缩短工期，但产品团队却觉得人员增加一倍，时间减少一半。这种情况下，既然加人并不是一个完美的选择，那么怎么办？那就只有加班的选择了。周六周日加班到 11 点，还可能因为未按期完成任务受到产品团队的投诉，在经过长期几轮的加班后，离职率便增高。而现阶段的状态也是如此导致其人员流动性高。

2 控制需求变更

1 流程存在的问题

如上图所示，项目流程包括需求到需求评审、开发、联调 + 提测、测试 + 修 bug、上线。然而，比经验排的时间点不准确更可怕的是什么？如下图所示。

上图为实际项目流程，需求到需求评审、开发到需求变更、开发到联调 + 提测到需求变更、开发到联调 + 提测到测试 + 修 bug 再到需求变更、开发到联调到上线。

2 项目周期定理

变化出现在项目流程的越上游，项目风险越小，项目越可控。需求是项目流程的第一步骤，大多数推翻项目重新开始的阶段便是在项目的早期阶段，或是需求评审时期。在这阶段时期，并没有研发同学参与，全程仅仅是产品团队在解决，那为何会产生如此多的需求变更？因为在很多情况下，产品团队在没有思考清楚时便开始着手准备，在进行一半时却发现有一个更好的想法，只是这个想法在初期没有想到，于是推翻重新开始。如果变化发生在设计阶段或者开发阶段，重来仅仅是重新设计、重新开发；若变化发生在需求阶段时重新需求；若变化发生在上线阶段，重来是整个流程的重新开始。因此变化越上游风险越小。

互联网公司需求是不会保持一成不变的，反之是一定会变化的，并且有些变化的需求是不可拒绝的，然而这种情况的需求较少，产品较多。很多时候不是不让变化，而是变化需要付出代价。大多数技术团队认为，需求变化是理所当然且正常的行为，不变化才是不合理的状态。但介于大家目标一致，都是为了 PV、UI、PD 等度量，因此正常的变化是被接受的，j2直播，而频繁的变化会让人无法理解。