XXX管理平台项目经理能力
前言
现在网络上比较热衷于数字化评选项目管理 人员的能力，最典型的代表如以下文章：
IT 项目经理必备的五种能力
IT 管理人才必备的十大能力
此外在也有 PMI 中对 IT 管理人员的能力有所要求和定义。
本人也根据自身的项目经历和从业经验，分享一下自己对项目管理 人员所需能力的理解；当然不同软件 能力成熟度的公司对于项目经理能力要求也不尽相同，人不能脱离大环境而存在；以下能力按重要程度进行排序。
沟通能力
与销售人员、售前人员相比，技术 人员的最大差距在哪里？就是沟通能力。无论从拜访客户、需求调研、商务谈判、与公司的上下级沟通还是甲乙双方的人际关系，感觉商务人员确实要比纯粹的技术人员高明很多；项目经理相当于半个商务人员，我也一致致力于此，但从和商务人员近一年的相处而言，确实要学习 的太多了。
项目经理的沟通主要包括内部沟通和外部沟通。外部沟通是与甲方和相关方的沟通，包括甲方的领导，项目经理，技术人员，以及相关接口系统的友商，沟通的目的在于确认双方需求、系统进展、相关协调等等。内部沟通主要是与公司内部的沟通，包括公司相关高层领导，平级协助部门，团队成员，主要目的是为了创建一个良好的工作氛围，尽可能屏蔽与项目无关的损耗，使团队集中精力到项目过程中去。
针对不同的对象沟通的方式也是不同。外部沟通过程中甲乙双方的地位实际上是不平衡的，乙方处于弱势位置，为了避免命令式的强制 / 被压制，服从 / 被服从的发生，最好是双方建立良好的朋友关系，这样甲方既可以及时了解项目的进展，也可以了解项目经理和项目所面临的困难，以期达到部分谅解；外部沟通也包括一些营销活动，这取决与甲方的喜好和公司的财务制度，呵呵。关于这一点，销售人员更有发言权。
内部沟通中与公司高层领导的沟通主要是进行耐心说服工作，通过邮件电话均可，当然如果无法对领导实施相应的压力比如资源，也可以借助甲方的力量 ( 这是下下策 ) ；与部门评级之间的沟通，要尽量采用温和的手段，为了避免无效沟通最好知公司高层、其直接领导，然后再进行沟通；与团队成员的沟通，首先是进行会议沟通，会议沟通主要发生在项目的关键点上，比如项目启动会、项目验收会，或者重大事项的时候，频繁的会议沟通，我不认为有太大用途，尤其是人多的时候；其次是 1 对 1 的沟通，与下面的项目经理和团队成员进行面对面沟通，可以及时了解项目进展、团队成员的思想波动，有针对的为其提出建议、解决方案，让团队成员感觉到项目经理的人文关怀，并传达公司的温暖；最后是避免不了的项目活动，聚餐、爬山、电影都是很好的活动方式，这取决与项目经理的权限和公司的财务制度。
关于沟通的目的，如何进行沟通、要解决什么问题，大体可以按如下步骤来做：
是什么？
为什么？
怎么做？
这几点看起来很容易，实际上包含了你对问题的理解、总结、思考、应急能力；记住这三点，并应用在你今后的沟通过程中 ( 比如会议、电话、邮件 ) ，相信对改善和提高你的沟通能力和沟通效果有很大的帮助。
组织能力
建立核心团队：
这里的核心团队是指子项目的项目经理和关键技术人员，具体视不同的项目规模而定，人员的管理和沟通是有成本的，我个人认为 3-5 个人比较合适，太多的人员太多的细节靠一个人有限的精力是无法进行跟踪和控制的；当然这里的核心团队成员是指那些技术和架构水平高超、有一定的项目管理能力、善于团队协助的人；核心团队成立越早越好，有利于项目的稳定和提前进入角色。如前文中所述，不善于团队协助的人只能带来负面效应。
协作能力
协作能力主要表现在项目内部各团队之间的协作、与公司内部其他团队的协作，与项目相关的友商的协作能力上。
项目管理能力
软件工程
软件工程按照传统的理解即需求分析、系统设计、系统开发、系统测试 ，这对项目经理而言是最起码的要求；就大部分国内项目而言，项目经理还是要样样都懂一点的，我不太赞同工作 2 、 3 年就自命不凡担当项目经理的人，技术、业务、人际关系的把握的积累都是需要时间的；当然外企也有职业的项目经理，他们可以不专技术，而专注过程。
软件能力成熟度
软件过程能力（ Software Process Capability ）：描述了在遵循一个软件过程后能够得到的预期结果的界限范围。该指标是对能力的一种衡量，用它可以预测一个组织（企业 ）在承接下一个软件项目时，所能期望得到的最可能的结果。 IT 企业有自己的软件能力成熟度，当然个人也有自己的软件能力成熟度，即体现在个人对过程的定义、监控、跟踪和度量上。本人有幸在 3 家 CMM5 的公司工作过，不过仍称不上对 CMM 有多深的研究，一来过于繁琐，再则软件能力成熟度与所在的 IT 环境有密切的关系，过程的实施和度量需要一系列的保障；事实上严格遵循 CMM 流程的企业并不多，基本上都是为了内部评估而评估的；不过基于过程的思想值得项目去参考和学习。
关于本项目的话，如果一定要说有什么软件能力成熟度的话，我认为是 2 级吧，项目管理的基本流程和系统文档已经有了，做类似的项目是具备一定的复制性的。
架构能力
系统架构，这个与项目经理的角色和定位有一定关系，项目经理需要从整体上把握系统的各个环节，硬件、操作系统、数据库 、软件、软件框架、甚至测试，都需要有所涉猎，能做到一精多专已经是不错的状况了，能做到全能的人应该是大师级的人物了，至少我不是，呵呵。
系统集成，这项能力与具体的项目有关，对于小项目来说只需要完成相应的业务功能，对性能的考虑、系统扩展型、系统部署、外围系统的接口要求并不高，所以对系统集成考虑的较少；如果实施大中型项目的话，项目经理最好具备起码的思想和评估能力。
关于系统架构、系统集成能力的提高，需要本身知识储备的日积月累、阅读大量的相关资料、以及项目实施过程中的学习，除此之外，别无办法。
学习能力
技术学习
项目经理需要的一个最基本的能力便是对他们的基本技术技能进行深度和广度的拓展。目前的技术知识更新换代过于频繁，但技术本身的内涵确实恒久不变的。如 Oracle 从 9i 到 11g ，其 Concept 变更的并不多，其基于关系的数据库特性在短期内还是无法改变的；如 java 和 .net 之争，其核心仍是面向对象的；如各技术框架之选型，无非是实现展现层、业务逻辑层、控制层、数据持久层的分离；适当的扩展自己的技术能力也是与时俱进的一种体现。
业务学习
相比技术而言，业务是更难学习的，尤其是财务、 ERP 、金融证券业务等，与 IT 背景相距深远，但是又不能不学，作为项目经理需要与甲方业务方进行沟通，缺乏相关知识背景，会造成沟通上的鸿沟，甚至无法理解对方的意图。当然并不是说项目经理一定要成为业务专家，事实上也是不太可能的。
文档能力
项目经理一定要会写，这是由项目经理的工作性质所决定的，从解决方案、系统架构、需求文档、验收文档的编写，到设计文档、测试文档的规格要求，无不打上项目管理人员的烙印；撰写文档是组织自己思路进行深层思考的过程，如果文档无法表达明白的话，相信自己的思考也一定不成熟；撰写文档也是沟通的需要，会议纪要、需求文档如果写的不清不楚的话，双方如果进行确认？想清楚才能写明白这是很简单的一个道理。
总结
项目经理的能力依据项目的规模和公司的成熟度有不同的要求，不能一概而论；举例而言，在本系统中假设时间为 100 的话，各项过程所占的比例分别如下：
本文转自baoqiangwang51CTO博客，原文链接：http://blog.51cto.com/baoqiangwang/312996
，如需转载请自行联系原作者
