常见的迭代结束后甚至于迭代内容处于验收末期时，开发资源就会被快速的被项目撤走。从项目的角度来说，加快资源日历的流转，看起来是可以提高“研发效率”的。简单的理解思路就是，快马加鞭，削短空闲时间。以为只要自己奔跑，就能超过时间。
部分研发人员，也会迫不及待的想进入下一个迭代的冲刺。对于这样的研发表示情感不得不鼓励，但并不赞赏。他们迫切的coding结束，提测，等待测试来发现未尽的细节。
如果是以上的情况，那么事实的通常会是，资源被快速抽离进入下一个迭代的进程之后，逐渐暴露出来：提测质量不佳、实现点缺失、关联系统影响改动遗漏、验收时间被拖延。表面看起来开发端在赶紧时间交付代码，但是如果质量不佳，不好的影响非常大：
1、新的迭代起了头，不得不被搁置。需要一气呵成的代码逻辑，被不断打断之后难免出现纰漏
2、开发自身的情绪和信心波动，由于没有完整的自测和深入的代码完毕后的复盘，面对排山倒海的缺陷甚至都怀疑人生了
3、测试、产品、开发沟通成本剧增，由于编码前的一些必要信息对齐缺失，暴露在测试阶段将会大幅度提升沟通成本，关于功能、实现逻辑等
4、产品正常的节奏、测试的节奏收到不可控的影响，引发各个环节的时间被强制挤压，整体质量下降
5、验收交付之后，由于资源早已投入下一个迭代，对于线上的质量问题，还要协调开发资源而不得不打算正在进行的开发工作
以上这些如果在项目资源规划层面没有正确的识别和评估，导致的结果必然是：研发节奏紊乱、团队信心波动，甚至于团队内部冲突。并且出现迭代总是不能如期保质保量交付，用户体验受挫。
通常能够做到对迭代正确的评估、认识、管理推进，已经是非常不错的了，这中间需要项目、产品、研发、技术的高度一致和碰撞，信息的不断对齐。同时充分相信团队成员，给予团队负责范围内的自主权利。一群人，最可怕的就是一条心搞一件事了。能做到以上，我认为就是一个好的项目管理者了，现实中能达到御己御人地步的可能也寥寥无几。更别提发布后的快速响应阶段，快速响应阶段应该成为一种常态，纳入到项目管理的资源规划范畴。
——————————
实例一则：
紧张的时间规划，版本上线后，产品、开发迅速抽离进入下一阶段的紧张验收和问题处理阶段后。上线项目，导致资源匮乏，缺乏跟进，最优势的资源被撤离后，暴露出来的是连贯性上的迅速脱节。毫无抗风险能力、容错空间，承担的后果就是不得不陷入低效冗杂的沟通、调整、修复过程，最终让整体的效果大打折扣，业务因此也会受到影响。
