总结

系统架构是项目重要的技术部分，它是否应该是项目经理的职责，暂且不谈；从现实的角度而言，技不压身，技能服众还是很有意义的；从项目经理角度来看，你能够准确的对项目进度、难度、工作量进行评估，对团队成员面临的困难迅速给出解决方案，减少项目经理和团队成员的沟壑；从团队成员角度来看，信任自己的项目经理，也是项目成功的一个重要因素。

项目经理能够通过对系统架构的设计，尽快评估出各部分的工作量，以安排相应的人力资源和工作计划，做到有的放矢，实际上本项目虽然包含几个业务系统，加上对本公司相关资源和技能的评估，但我个人认为系统集成和数据同步等在项目实施中占据了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次，后彻底走人了，我相信没几个人能受得了他的脾气。也许这个人很有钻研的精神，在充足的资源前提下能够做好产品，可是项目中更不需要缺乏团队精神的成员。