背景介紹：
根據公司大的戰略調整，原有項目合約任務交付第三方，同時承接第四方合約任務。此次調整所波及范圍涉及各個分公司，多個部門而非我們項目組。
項目背景介紹：
公司對項目質量各方面指標均有要求，交接雙方分屬不同分公司，不同部門。接到新項目的時間為下半年（7月份），根據需求方多項年度計划必須及時啟動，並擬定項目交付計划。
需求中多為一句話需求，例如：我們需要xxxxx；xx部分功能需要調用xx系統來實現....(由於工作原因，隱去此部分實際內容)
年度任務的核心為：多種核心功能外移，前端技術升級
另：每月需求人員從客戶方反饋回來的內容需要得到及時支持
我們的實際做法：
在接手后，我們組織項目組內工作能力比較突出的人員用時一個星期對項目進行熟悉，根據經驗對開發年度計划任做了初步評估，預計10月底完成相關工作。在提交到上去的評估中我把這個時間根據經驗延長到了11月中旬（因為為年度任務，這個時間還在可承受范圍內 ）
問題的發生：
1.老項目的持續支持（在承接新項目的同時，老項目的移交也在並行過程中，原計划於8月移交完成的項目在交付后出現了接手放能力，人員不足向總公司申請抽調人員繼續支持的情況。不得已我們只能分出一位業務熟練的人員予以支持（通常這類人員都是項目組中技術過硬的））
2.保持不變（這是一個十分坑的需求，那就是沒有需求，我們的需求就是和現在一樣，這導致了一個致命的問題，開發猜測需求！是的，開發怎么做，需要閱讀老代碼邏輯！代碼邏輯在實際的開發中發現存在很多一個核心service上千行代碼，一個核心sql幾百行...）
3.外部環境(上文提到很多核心功能需要遷移到外系統實現，這個至於為什么，只能說是硬性要求！這些外系統我們想當然的認為已經有了，實際的情況為這部分內容為此次改造特別提出的，其他項目組的成員正在對此部分內容進行開發，甚至都沒有穩定的對外接口提供，開發人員每天都在修改，然后重新部署)
4.多版本開發(上文已經提到，在做這次改造的同時，我們需要同時支持客戶每月需求，一個大需求來得很突然，新客戶投產！這是一個比較費時間的事情，沒有一個特別熟悉項目的老手，上千個配置，又一項目技術核心抽離去做)
5.測試團隊換人（在公司的的背景下，測試團隊的移交恰巧發生在這個期間內）
思考：
在項目真正完成后我靜下心來思考掉下去的這些坑，
經驗主義是主要問題之一，根據我們之前太久時間相互接觸的系統關系人已相當熟悉，問題處理響應時間遠遠短與新項目，以老系統預估新系統，出現很多的誤差；
嚴重的外部依賴，且沒有穩定的外部環境也是問題之一，大量的返工耽誤的時間也是占比不小；
溝通，這是一個我們具有很強主觀能動性的因素，很多事情如果多問一句就會有不同的結果。比如 在說到制定需要使用外系統的實現功能的時候，我們理所應當的任務此外系統已經完備了，事實卻並非如此。
樂觀主義，當接收項目之初，曾向我們承諾為了配置此次年度，每月需求會盡可能的減少，壓縮。然而。。。（客戶爸爸的錢，往往具有一錘定音的作用！）
新員工的技術水平培養，這不是一個一朝一夕的問題。卻反映得非常突出，尤其是在核心抽離之后。開發人員相互之間負責的業務彼此了解熟悉，才能在人員離開后迅速補上。
個人總結：
在越來越多的項目實踐中我發現，拖慢節奏，不能達到預期目標的原因多種多樣，客觀的，外來的，自身的，團隊的...沒有人能列舉完。沒有辦法改變的我們需要接受，完全將問題歸結於這些並不能解決實際問題。那就只能更多的想想自身的問題，這個提升往往都是坑踩過了才能總結，時間的積累是必不可少的。對待項目得要保持一顆略帶悲觀的心，對外展露自信，對內常常自省（這通常也是知易行難的）。
ps:希望曾經踩過的這些坑，能幫助到各位道友吧。