總結
系統架構是項目重要的技術部分，它是否應該是項目經理的職責，暫且不談；從現實的角度而言，技不壓身，技能服眾還是很有意義的；從項目經理角度來看，你能夠準確的對項目進度、難度、工作量進行評估，對團隊成員面臨的困難迅速給出解決方案，減少項目經理和團隊成員的溝壑；從團隊成員角度來看，信任自己的項目經理，也是項目成功的一個重要因素。
項目經理能夠通過對系統架構的設計，盡快評估出各部分的工作量，以安排相應的人力資源和工作計劃，做到有的放矢，實際上本項目雖然包含幾個業務系統，加上對本公司相關資源和技能的評估，但我個人認為系統集成和數據同步等在項目實施中占據了50%的工作量.
六、XXX管理平臺系統項目教訓
前言
聊一下自己的總結吧，經驗也是在教訓中不斷成長。
技術方面
之前對硬件和網絡缺乏基本的選型概念，以及對整個系統的整體和技術方案把握有所欠缺，導致整個系統架構從項目之始到系統部署完成一直處于變動之中，周期達5個月，版本不下幾十版。
關于數據庫方面，雖然對困難有所估計，也做過一些預研工作，但是對實施過程中的難度估計仍然有所不足。典型的是安裝了Oracle32位版本導致無法充分利用系統硬件資源，以及Oracle Stream數據同步過程中出現了若干的bug。
關于系統接口的處理，缺乏穩定性、健壯性、容錯性，有待于系統設計的完善和技術人員水平的提高和總結。
業務方面
因為第一次從事該行業，對其中的數據庫和業務缺乏了解，導致前期在系統需求匯報和與公司進行溝通尋求資源的時候，因為缺乏理論依據，結果導致溝通過程中發生了不少誤會；這也是項目前期開展不順利的一個原因。
與甲方進行溝通的時候，因為業務原因，完全依賴與相應的項目經理的溝通，自己則對各子系統細節缺乏深入了解，造成整體工作的被動。
團隊方面
盡管有因人而異，因材施教之說，實際上不同的人在團隊合作方面確實有不同的差別，尤其是項目的核心成員如果缺乏團隊合作意識，對項目的進度和成本會造成延遲和增加，對項目團隊建設和協作也會造成嚴重不良影響。
舉例而言，某子系統，因人員原因，換了3撥需求調查人員，換了3撥項目經理，換了3撥開發人員；而集中在某項目經理上，更加典型，該項目經理做.Net開發出身，被公司派來做java項目，他的技術水平如何不談了；首先本系統準備采用Structs + Spring + iBatis的B/S架構，他非要自作主張使用Structs + Spring + Hibernate的B/S架構；缺乏與項目中的技術高手的交流，喜歡埋頭苦干；缺乏與甲方的主動溝通，導致需求遲遲未定；他本人不熟悉java，卻喜歡把java和.net進行比較，懂不懂說java如何如何；比較喜歡鉆研技術和追求完美的技術框架，而自己的能力卻又無法達到，實際上到后發現他的代碼也不過如此，缺乏注釋，代碼缺乏分層控制；重要的是對自己的團隊成員缺乏理解和溝通，人的技術水平是無法實現突飛猛進的，懂不懂拍桌子指責自己的團隊成員，本來只有4個人的團隊，結果被他趕走了5個人次，只有一個愿意跟他干活，人走了又去抱怨公司不給資源，確實在這方面公司有不少責任，但他自己何嘗沒有更大的責任呢？后他先后撂挑子自己離開項目組3次，后徹底走人了，我相信沒幾個人能受得了他的脾氣。也許這個人很有鉆研的精神，在充足的資源前提下能夠做好產品，可是項目中更不需要缺乏團隊精神的成員。
