项目管理总结02(10.30)

在前面将自己知识经验积累的时候曾经谈到过，自己从开发，架构，到需求，再到IT项目经理，大项目经理，基本一路从技术线发展上来。从04年开始过CMMI2级对软件过程改进和项目管理知识有了较为体系化的理解和认识，到06年正式考过PMP认证，再到从做内部IT项目到做外部的集团型大型IT项目，整个实践和知识积累过程也为自己后期的项目管理打下了坚实的基础。

也是自己经常会强调的IT项目管理更多是技术+管理，只懂技术不懂管理无法把控全局，无章法，同时沟通和协同混乱；而只懂管理不懂技术，则是寸步难行，更加重要的时候关键风险问题无法识别和解决。把合适的人安排在合适的位子上，并相互之间高度协同起来，看似简单，实则困难。所有的识人，用人，激励人全部围绕这个目标而展开。

项目失败你可以回顾下，要么是没找到合适的人，要么是人没在合适的位置上，要么就是人和人之间的沟通，上下游之间的协同出现了大问题。看似技术类问题，实则人的问题。

为学日益，为道日损

如何理解这句话呢？我原来经常会举个例子，比如你去爬山，你爬到半山坡后你有两个选择，一个是走上腰的一条平路到对面山坡，还有就是你要爬到山顶然后再下到对面山坡。可以看到两个选择最终你都到达了对面山坡，但是效果却千差万别。

上到山顶，再下到半山腰就是一个为学日益，为道日损的过程，该做的实践全部做，该体系化学习的至少体系和框架全部学习。这是一个为学日益的过程，当你真正实践完成，并经过体系化的学习完成后(比如考PMP认证），这个时候你开始做为道日损的过程，即既不会忽视关键的方法论和思考方法，也不会生搬硬套各种计划和模板，而是知道如何因地制宜，因时制宜，真正抓住一个项目的Key Point，用最恰当的方法，技术和工具来进行管理。

举个例子来说，最近这个大项目，包括前期的很多大项目，我已经很久没有说要真正去按部就班的计算关键路径，再安排资源，原因在哪里？一个是项目是受资源约束关键路径法不管用，其次就是项目的重点往往并不在关键路径计算上。但是这些都不代表你做不好项目管理。

所有的方法和工具，都是协助你做好项目管理的，不是最终决定你项目成败的。你要渡河到彼岸需要坐船，但是到了彼岸一定不要死拽着船不放，而忘记了真正的目标和方向。

倚天屠龙记里面，张三丰教张无忌太极拳也是同样的道理，最后招式要全部忘记掉，那是否就完全不要教就完事了？答案显然不是，教和学的过程是为学日益的过程，融会贯通后逐渐遗忘，不要拘泥于招式这个形而真正在神上得以领会是为道日损的过程。

所以实践一段时间后，该体系化学习的方法论和知识框架还是要学，但是最终则是无形胜有形。

干系人管理和平衡

对于IT项目管理的核心前面一篇文章已经多次强调了是对团队和人的管理，再扩展一下还包括的就是对干系人的管理。这个干系人包括了甲方的客户项目经理，高层领导，甲方最终用户。特别是对于ESB项目还包括了业务系统合作厂商，这些本身都加强了干系人管理的难度。

干系人管理难点就是如何在各个干系人的述求和利益之间寻求到一个真正的平衡点。

没有找到这个平衡点，项目很难真正推进，举个例子来说，对于ESB这种大集成的项目，你只把甲方用户的述求满足好肯定是不行的，诸多的业务系统的述求无法满足，项目实施的时候业务系统不配合你，或者明里配合，暗地地不配合，这些都将导致项目最终失败或延期。

在干系人管理里面，规则很重要，简单来说就是先说断，后不乱，先把规则制定清楚。这个规则就是项目实施的方法和流程，具体的分工职责和边界。这个边界的制定相当重要，在边界划分清楚后正式的宣讲和评审，多方认同，后续按此推进工作就会更加顺畅，阻力也会小很多。

边界划分清楚了，那是否不该你做的事情你坚决不去做，或者说业务系统需要协助的地方你完全不管？很多时候事情都没这么简单，该协助的地方你还得协助，但是这是义务帮忙，非职责所在，要提前说清楚。那么为啥要协助？很简单，你不协助将影响到你自己的项目的按期完成和交付。你协助别人等于也是在帮自己完成目标。

对于ESB集成和实施这种项目，看似一个简单的技术集成平台，但是一涉及到服务实施就复杂，因为服务实施就涉及到大量的协同，这个时候不是你能力够就ok，而是需要所有和你配合的业务系统都能按时按质交付，但是你对业务系统往往并没有强管控力。这也导致你项目的成败受到外部干系人太多的制约，也存在太多的不确定因素，你能力再强有时候也无法解决。

很多能力强的人更愿意单干或单打独斗，这里面最大的原因就是自己能够很容易承诺质量和交付周期，但是一到团队，一到诸多干系人，随时都可能碰到猪队友给你挖坑，你时间都在填坑，而不是在解决问题上。所以对于这种大集成项目，我们最怕的也就是他人经常给你挖坑，你又无能为力。