背景介绍：
根据公司大的战略调整，原有项目合约任务交付第三方，同时承接第四方合约任务。此次调整所波及范围涉及各个分公司，多个部门而非我们项目组。
项目背景介绍：
公司对项目质量各方面指标均有要求，交接双方分属不同分公司，不同部门。接到新项目的时间为下半年（7月份），根据需求方多项年度计划必须及时启动，并拟定项目交付计划。
需求中多为一句话需求，例如：我们需要xxxxx；xx部分功能需要调用xx系统来实现....(由于工作原因，隐去此部分实际内容)
年度任务的核心为：多种核心功能外移，前端技术升级
另：每月需求人员从客户方反馈回来的内容需要得到及时支持
我们的实际做法：
在接手后，我们组织项目组内工作能力比较突出的人员用时一个星期对项目进行熟悉，根据经验对开发年度计划任做了初步评估，预计10月底完成相关工作。在提交到上去的评估中我把这个时间根据经验延长到了11月中旬（因为为年度任务，这个时间还在可承受范围内 ）
问题的发生：
1.老项目的持续支持（在承接新项目的同时，老项目的移交也在并行过程中，原计划于8月移交完成的项目在交付后出现了接手放能力，人员不足向总公司申请抽调人员继续支持的情况。不得已我们只能分出一位业务熟练的人员予以支持（通常这类人员都是项目组中技术过硬的））
2.保持不变（这是一个十分坑的需求，那就是没有需求，我们的需求就是和现在一样，这导致了一个致命的问题，开发猜测需求！是的，开发怎么做，需要阅读老代码逻辑！代码逻辑在实际的开发中发现存在很多一个核心service上千行代码，一个核心sql几百行...）
3.外部环境(上文提到很多核心功能需要迁移到外系统实现，这个至于为什么，只能说是硬性要求！这些外系统我们想当然的认为已经有了，实际的情况为这部分内容为此次改造特别提出的，其他项目组的成员正在对此部分内容进行开发，甚至都没有稳定的对外接口提供，开发人员每天都在修改，然后重新部署)
4.多版本开发(上文已经提到，在做这次改造的同时，我们需要同时支持客户每月需求，一个大需求来得很突然，新客户投产！这是一个比较费时间的事情，没有一个特别熟悉项目的老手，上千个配置，又一项目技术核心抽离去做)
5.测试团队换人（在公司的的背景下，测试团队的移交恰巧发生在这个期间内）
思考：
在项目真正完成后我静下心来思考掉下去的这些坑，
经验主义是主要问题之一，根据我们之前太久时间相互接触的系统关系人已相当熟悉，问题处理响应时间远远短与新项目，以老系统预估新系统，出现很多的误差；
严重的外部依赖，且没有稳定的外部环境也是问题之一，大量的返工耽误的时间也是占比不小；
沟通，这是一个我们具有很强主观能动性的因素，很多事情如果多问一句就会有不同的结果。比如 在说到制定需要使用外系统的实现功能的时候，我们理所应当的任务此外系统已经完备了，事实却并非如此。
乐观主义，当接收项目之初，曾向我们承诺为了配置此次年度，每月需求会尽可能的减少，压缩。然而。。。（客户爸爸的钱，往往具有一锤定音的作用！）
新员工的技术水平培养，这不是一个一朝一夕的问题。却反映得非常突出，尤其是在核心抽离之后。开发人员相互之间负责的业务彼此了解熟悉，才能在人员离开后迅速补上。
个人总结：
在越来越多的项目实践中我发现，拖慢节奏，不能达到预期目标的原因多种多样，客观的，外来的，自身的，团队的...没有人能列举完。没有办法改变的我们需要接受，完全将问题归结于这些并不能解决实际问题。那就只能更多的想想自身的问题，这个提升往往都是坑踩过了才能总结，时间的积累是必不可少的。对待项目得要保持一颗略带悲观的心，对外展露自信，对内常常自省（这通常也是知易行难的）。
ps:希望曾经踩过的这些坑，能帮助到各位道友吧。