前言
系统架构是项目中技术实现的最重要的环节。系统架构的良好与否关系到系统的性能指标、安全指标、稳定性指标、可扩展性、业务实现等等。
系统架构涉及到系统硬件的选型、网络拓扑、操作系统选型、数据库选型、B/S与C/S的选型、B/S各框架的选择、缓存的实现、数据库设计等诸多方面。
在大型IT企业中，项目经理和架构师是分离的；但对于国内IT公司尤其是小企业来说，就成了一种奢望。项目经理一肩挑的现状至少短期之内还是无法改变的，这自然也增加了项目经理的痛苦指数和工作量。
关于系统架构是什么？我最认同一句话：架构即关注点分离。
项目经理不是万能的，系统架构需要更广博的知识，当然某些方面专业的知识也是必须的，这取决于平时知识的积累和总结，也需要其他团队成员共同的努力。
关于部分系统架构图的内容参见：

系统硬件
关于系统硬件的选型，首先是根据业务需求和性能指标确定硬件的需求数量和相应型号；举例说：一个普通的B/S系统需要有web应用服务器，数据库服务器，如果对于性能有较高的要求，则需要增添cache服务器；如果对于稳定性和高可用性有特殊的要求，则需要对相应的服务器进行集群处理。
关于系统硬件的选型，一是关于厂商的选择(有IBM和HP之争)，一是关于机器架构的选择(PC服务器和小型机)，再则是某种机型的选择（在本系统中主要为HP360和HP580）；再细的话就是更细型号的选择了(HP360、HP580都至少有十几种型号)，最后是机器选件，比如是否需要扩充硬盘、内存或者CPU。
其实最重要的一项就是预算，呵呵。本系统的硬件采购是由甲方采购的，但是架构是由自己做的，方案如果有之前的案例就会很轻松很多，很不幸，这个方案改了几十版，跨度达到4个月。无他，对硬件，我不熟。
系统软件
关于系统软件的选择主要上是操作系统、数据库、开发工具
选择什么样的操作系统与计算机硬件本身有很密切的联系，当然也与甲方的要求有关。Linux/Windows/专有UNIX都是可选项，windows囿于安全性原因，一般不为推崇；UNIX与硬件有很大关联，一般也很少用；所以普遍选择的是Linux；
关于操作系统版本的选择，一般建议选择目前市面比较稳定的版本，最新的版本往往意味着兼容性问题，太老的版本一般有性能问题；
关于操作系统的32/64位的选择，这个需要硬件的支持；在64位CPU上安装32位的操作系统意味着资源的浪费；在这个项目上曾经考虑有所欠妥，结果造成了一定的问题。
关于数据库的选择，与操作系统有一定关系，也和对系统的安全性、稳定性、高并发性有一定关系；虽然一个好的DBA在任何一种数据库上都可以构建出高可用性的数据库，呵呵。
关于开发工具的选择，与操作系统相关，也与甲方的要求有关，开发工具一向有java和微软两条线路之争；在本系统中采用的当然是java了。
关于web中间件的选择，与开发工具、操作系统都有关系，JBOSS，websphere，tomcat，resin，web logic都有一定的拥蹇和市场；取决与甲方的要求和本团队对相应系统的熟悉程度。
B/S架构
关于系统软件架构通常是指的是B/S部分实现的具体框架，此部分仍属于技术架构部分。
众所周知，B/S的框架有不下数十种，常用的有SSH（Structs + Spring + Hibernate）和SSI（Structs + Spring + iBatis），SSH和SSI从本质上没有什么不同，就是实现业务逻辑层、控制层、数据持久层和展现层的分离。
B/S缓存的架构：OS Cache + EhCache
说到软件架构，我就不太在行了；我做过Powerbuilder，ASP，java(JSP,HTML,CSS,Javascript,structs,spring,xml,xsl,ajax,webservice)不过都是入门级水平，实在连个称职的程序员都算不上，唯一的好处就是对方方面面都略知一二，查资料方便一点而已，呵呵。我个人只是在数据仓库和数据库开发、设计方面还算有点研究。
幸亏下面有相应的项目经理，也是项目中的技术经理，他在这方面是权威，B/S技术架构本来就是一个虚虚实实的框架，呵呵。
系统同步和接口架构
关于数据同步，在本平台中是最重要的环节，缺少数据的系统是无用的；为了实现系统数据同步架构，我曾先后在虚拟机上进行过oracle高级复制、Oracle Stream的测试，也曾为了该同步和公司技术总监吵过N多次，他主张用程序来实现，不过在他那边总是不了了之。
尽管通过测试，高级复制和stream都可以实现实时数据同步，不过我知道在实际生产环境中是远远不会这么简单的；
首先源数据和目标源的结构并非完全一致，允许目标源的结构大于原数据源的结构
其次多环节数据实时同步，从中心数据库到电信数据库，再从电信数据库同步到网通数据库。
再次各数据库均采用RAC方式，现实的例子中很少有类似应用。
最后Oracle的stream有许多的bug，需要进行不断调试和patch升级。
事实上，在同步方案的过程中，也遭遇到很大的困难，前后的测试和最终顺利实施经历了2个月之久，不过stream仍需要不断的人工监控和干预。我相信到目前为止即使市面上也没有任何一种完全稳定的同步方案。
关于MQ 、Webservice、LDAP接口，目前的业务和技术虽然已经完全实现，但是还缺乏稳定性和一致性。
总结
系统架构是项目最重要的技术部分，它是否应该是项目经理的职责，暂且不谈；从现实的角度而言，技不压身，技能服众还是很有意义的；从项目经理角度来看，你能够准确的对项目进度、难度、工作量进行评估，对团队成员面临的困难迅速给出解决方案，减少项目经理和团队成员的沟壑；从团队成员角度来看，信任自己的项目经理，也是项目成功的一个重要因素。
项目经理能够通过对系统架构的设计,尽快评估出各部分的工作量,以安排相应的人力资源和工作计划,做到有的放矢,实际上本项目虽然包含几个业务系统,加上对本公司相关资源和技能的评估,但我个人认为系统集成和数据同步等在项目实施中占据了50%的工作量.
言
项目风险管理是指对项目风险从识别到分析乃至采取应对措施等一系列过程，它包括将积极因素所产生的影响最大化和使消极因素产生的影响最小化两方面内容。
风险识别--确认哪些风险有可能会影响项目进展，并记录每个风险所具有的特点。
风险量化--评估风险和风险之间的相互作用，以便评定项目可能的产出结果的范围。
风险对策研究--确定对机会进行选择的步骤及对危险作出应对的步骤。
风险对策实施控制--对项目进程中风险所产生的变化作出反应。
本文无意讨论项目风险管理的一般流程和相应的控制，只是根据项目中所遭遇到的问题把自己的一点心得体会表达出来，很多在其他人眼中也许算不上风险，有一部分甚至超出了项目管理的外延，但对于部分IT企业或者中型项目管理，至少是本人所经历到的事情，或许对大家有所参考。
背景：本人于08年06月入职某公司，8月份即开始负责该项目，对公司组织、制度和相关业务缺乏了解；公司于08年4月进行重组，高层和人员变动剧烈，新老冲突严重；公司IT力量比较薄弱，产品线较丰富，均为小项目，但自命不凡；后来了解到我是作为双方利益冲突的牺牲品来负责该项目的。
企业内部管理的风险
公司领导对IT管理的熟悉程度。公司领导对IT管理的熟悉程度事实上决定了项目管理中的很多事情例如人员，但不幸的是往往公司的领导非IT出身，这意味着你要尽更多的精力来与之进行沟通、解释工作；曾有领导认为大项目是小项目的简单叠加，即人月的倍数；更甚者领导对系统集成缺乏认知，我曾花了3个月进行沟通，甚至差点导致项目流产。
公司领导对IT项目的支持程度。公司领导对IT的熟悉程度影响了对IT项目的支持程度，但另一方面与公司高层对本公司的IT定位也有关系。
公司财务制度。这个说起来与公司内部管理和制度有关了，财务控制成本，项目经理也要控制成本，但是做起来就比较困难了，日常费用的报销、应急费用的申请、是否有备用金、是否有项目活动经费、是否有项目奖金、甚至团队成员的住宿、考勤、租房等等；如果与财务产生了矛盾，也会让你吃不了兜着走；项目经理是否能够承受这么多的额外工作？
公司HR制度。主要是项目中新员工的招聘、转正申请、工资发放等等，外企和正规化的IT公司应该不存在这类问题，但是我遇到很多类似问题，也帮助团队成员去讨薪；这类问题的解决与否直接影响到项目团队成员的积极性。
公司组织架构。大中型项目往往意味着你要同公司内部多个部门直接进行协同工作，了解公司部门组织结构，认识相关部门经理，甚至公司领导会对解决问题的效率有很大影响。
企业项目管理的成熟度
IT部门组织架构。了解IT部门的组织结构是项目负责制还是等级制度，可以了解自己所处的环境，以便寻求合适的资源。
公司所做过的最大项目规模。了解公司所做的项目规模可以直接对公司的软件和实施能力进行评估，就像让一个儿童去做成人的工作，显然是勉为其难的。当然通常情况下公司领导会按照项目金额去衡量项目规模，导致缺乏可比性。
公司之前有没有做过类似的项目。这个包括业务类似、架构类似、技术类似等。
公司的软件能力成熟度。软件能力成熟度反映了一家公司的IT管理水平，高成熟度的公司至少可以让你在项目流程、项目文档、项目支持上受益。
公司IT技术总监的能力。往往一个公司的IT技术总监能力和整个公司的IT水平息息相关，他的能力和水平也影响到对项目的支持水平。呵呵，反正我每次去公司开会寻求资源时总是要PK上半天的。
项目经理的职责风险
项目管理主要包括工作范围管理、时间管理、质量管理、成本管理、风险管理、沟通管理、人力资源管理、采购管理、整合管理。
需要了解项目经理所拥有的权限。大多数情况下公司除了成本、人力资源、采购涉及到money的不会让你经手之外，恨不得会都让你包办。下面就是你的义务了，呵呵。
需要了解本项目经理所要负的全部义务。我理解的义务就是项目经理所要担当的角色，首先是保姆，最好用最少的money管理项目成员的吃喝拉撒睡；其次是炮眼，要勇于担负起所有甲方对公司的压力，以及团队成员与公司之间的压力，不该管不要管，要少管(这是公司其他领导的原话)，实施上可能吗？然后是架构师、系统分析员、需求调研员、DBA、程序员，曾经有领导问我会不会写代码，我说我不会，当然是气话，事实上我写的不比任何一位成员少。
项目经理的人力资源调度能力
这个与公司组织、IT部门组织结构、甚至技术总监有很大关系。
避免双重管理，在我的team中有4类人，2拨人来自于公司IT部门两个不同的领导；1拨人是属于我直接管理，当然人很少；还有1拨人属于支援性质的；其中3类人不归我考核、管理；领导总是会说你要敢于管理，呵呵，怎么管？借调个人，首先要确认是谁的人马，然后向个人电话沟通，再向相应的主管电话沟通，最后向公司领导沟通。
如何处理害群之马，项目管理比较忌讳团队成员无法按照自己的进度进行，因为是个团队协同工作，项目不能因为个人而有所延误；其次希望自己的团队成员能够积极沟通，当无法正常按进度实施的时候，至少双方能够积极交流共同面对分析并解决。
在我的一个子项目中，需求调研人员换了3批次，项目经理换了3批次，项目成员换了3批次；项目经理不辞而别达三次，辞退员工4人，原因是认为团队成员不合格，其实我个人认为是他不合格，为了此事还曾与他的直接主管吵了几次。据说他喜欢与业务比他强技术比他强的人进行配合，大概是我的能力太差了吧。
人员的技能问题
一个理想的团队包括子项目经理、系统架构师、系统管理员、DBA、高级工程师若干、工程师若干，测试员若干、美工等。
平衡你的资源和相应人员，在一个资源不充足的团队中，只有勉为其难了，有什么样的人用什么样的人，尽量做到用人不疑，疑人不用；一个人尽量担当多个角色，挖掘个人潜力了。
团队成员是需要培训的，这在外企通常做的比较好，内企则因项目通常人少，周期比较紧，结果无法实施。
系统集成能力
个人认为系统集成程度是大中型项目与小型项目的一个明显区别。
系统集成能力主要表现在是否对系统硬件，操作系统，数据库，不同接口开发，系统架构上，这方面知识的积累并非一朝一夕所能造就，取决于公司的积累。
系统外包经验
当公司资源无法满足项目要求的时候，需要适当的引入外包资源；公司在这方面是否有过独立的经验，也对项目的顺利实施与否有很大关系。
甲方项目经理能力问题
甲方的项目经理素质的高低对项目的成本、范围、时间、沟通等几个方面均有相应的影响。不幸的是，我们很难影响甲方的决定。但至少和甲方的项目经理关系要做到融洽，而不要推到对立面去。

顶起出售 位

传说中的沙发？？？哇卡卡