项目管理
引言
现状:
当前很多的项目处于焦灼状态，此类的项目举不胜举，本篇文章以IT界软件开发为依据，笔者曾开发过些许软件项目，失败的、成功的项目都有，但是每次均无法在项目开始之时能够对项目有一个客观的、好的预测，追究其原因，主要在于没有一套好的项目管理方法，按照常规的传统观念无法保证项目能够很平顺的执行，更不敢奢想项目能够提前结束，纵然在项目之初加入了很多的安全时间也是如此。那么我们到底能够做些什么呢？是不是所有的软件项目都是如此？我想，至少是大多数的软件项目是如此的。据我个人的了解，大多数的项目都是失败的，此种失败可能是项目延期、成本失控、软件的内容大幅删减、与客户的关系愈加的难以维持等等的一种或者多种原因。
客户的需求不断的变化或者新增（变化与新增是不同的感念），讨厌的客户总是在项目验收的前一时刻才告诉我们，我们做的并不是他们想要的，他们总是无休止的“纠缠”着我们，不仅如此，他们甚至希望到手的软件不能出现Bug，而我们的程序员们在做什么呢？他们是否在做一些并不是客户需求的一些“游戏”或者搞一些偏离的需求的“高深”的“东西”？项目频临延期，我们的进度在80% - 90%开始做来回的动荡？当我们根据进度得知通过数个月的努力项目已经完成了85%，但是在接下来的一个或者几个月内，项目仍然原地踏步？程序员是否会告诉你（项目经理），他们的处理程序是多么多么的灵活，多么多么的完美，但这一切客户却从不给与半点的肯定？怎么办？你只好采取了一些措施，一个不得已而为之，却被业界都认为行之有效的措施，你减少了项目计划时期的一些部分，少了精密的质量监测，但是项目的开支还是愈来愈难以控制，膨胀的顶破了房顶，而距离项目完成却还是个未知数？天哪，公司高层告知你，需要控制项目的费用，大幅削减，大幅度的动手术，程序员的抱怨让你坐立不安，更要糟糕的是有一天客户告诉你说他们针对项目的不满意程度已经达到他们无法接受的地步，项目随时有可能被终止掉，知道这意味着什么吗？也许只有此刻你才得以知道情况竟然恶化到无法收拾的地步，公司已经为这个糟糕的项目对以往的决定表示怀疑，你的职位也面临着考验……所有的一切足以让你发疯。
或许情况不足以如上所述般的恶化，但这些状态正在逼近这每一个PM，当墨菲发动了凌厉的攻击时，一切可能变得更加的恶化，当另一波墨菲突袭时，PM开始手忙脚乱，历次磨难之后的PM开始变得聪明，不再如先前的那样在项目计划中自信的规划，而是加入了大量的安全时间，甚至加入了一倍的安全时间来应付，应对变更、应对墨菲，应对周期延长，因对团队的变更等等，似乎情况得以好转。但是，再让我们看一看吧，情况真的得以改善了吗？并没有，还如同之前一样的糟糕，该发生的事情还是发生了……
如果，作为项目经理的你的确遇到了上述情况的一种或者多种，我想，你有必要和我们一起交流，花点是时间来看这篇文章，不会浪费你太多的时间J
本篇文章不打算交流如何使得项目能够成功的执行，仅仅就一些个人认为我们应该关注的问题提出来，与大家作一个交流，希望这篇文章可以作为后续文章的引子，因为项目管理说起来是一个太大的话题，我想我们应该逐步的对项目中各个因素，特别是我们都一致认为是比较关注的问题进行分析，如此才有可能得到好的一个答案。
我们必须以务实的态度来对项目进行衡量，希望我们所有讨论的东西都是有依据可遵循的：
笔者曾接触的一个项目经理，姜平，负责开发公司的产品的更新，不妨叫做项目V，主要是将原有的系统从dot net移植到j2ee平台，并且新增加一些需求。在项目开发之始，需求基本上已经可以确定，特别需要提及的是姜平曾经在该产品前一版本中担任重要角色，并且拥有较为良好的人力资源支持，整个项目共有15人，其中高级程序员2名，项目经理助理一名。而质量控制在前期暂时投入1人，在项目的开发阶段到后期将会有更多的测试人员投入。质量管理部分中的1人对该项目全程监控。在此期间比较担心的一个问题是项目周期比较紧，三个月需要将该产品推出。整个项目就是在这种情况下启动的。该项目是公司第一个需要按照CMM3的标准作的样板工程，但也仅仅是这样的要求，值得一提的是项目有开发计划，有很好的进度安排表，以及测试介入时间，并且每周都会将项目进度以大字报的形式贴到软件事业部最明显的位置，不得不说的是在进行这个项目的同时，姜平还同时负责其他项目（项目M），暂且不来讨论整个项目的具体细节，最后得结果是项目V言重的拖延，成员无法控制，更为糟糕的是到了后期，项目V的成员有一部分脱离了该项目，或者说处于半脱离状态，出现此种情况之后，笔者尝试着于姜平进行交流，当问及到该项目延期后得后果时，姜平的回答是：“项目已经如此，所有的责任必须由我一个人来负责，我为公司产品的推迟表示深深的歉意”，很明显，姜平时一个很负责任的项目经理，也很显然，姜平似乎不知道项目延迟的真正后果，以及自己能否承担的起这个责任，项目的延期造成了公司的产品无法在此阶段内满足客户的需求，客户会逐渐流失，延迟两个月的产品是否还有机会在市场是立足？该产品是不是面临着出生后便被淘汰的结局？对于公司的损失，不仅仅是这几个月内的投入，更多的可能是客户的流失，产品市场面临着越来越严峻的考验，但我相信姜平可能没有认真的考虑过这个问题或者他的确不知道里边的更深一次的含义。为此，是否可以认为一个项目经理对项目认识的不足，对项目按时完工的价值上的认识不足会不会影响到整个项目的顺利进行呢？因此，笔者第一个需要指出的是项目经理必须要对整个项目的价值以及影响做一个全面的评估，只有高度的、精确的评估才能让我们更全力以赴。实际上，项目M也严重的延误，延误的原因有很多，但是我们前边的假想也体现在此，客户的需求不停的变化，直到项目快要结束时，需求仍然没有停止变化，其实在我提起这个案例的同时，所有的人可能都已经可以猜测得到，项目M的失败大概也在80%以上或者更多，为什么？因为姜平犯了一个比较严重的错误，在没有数量的掌握项目管理方法方式的钱体现，按照传统的项目管理方法必然造成个人的焦点无法聚焦，相当于在同一时间姜平就开始多项工作，必然会无法集中，而无法集中就是项目经理的一个大忌，如果项目经理不能专注，必然会延误，项目所带来的收入也必然会被推迟，这造成金钱上的损失几乎比任何因素都大。当然，多个项目并行的方法并不是完全的不可能，但如果按照传统的方法似乎难以解决，笔者希望在后续的文章中就多个项目的并行给与解释。项目中的多任务情况比比皆是，如下所描述：
如上边所画的三幅图所示，均有利有弊，采用图1的方式，延时处理，此种方式可能会带来成本上的减少，但是一旦任务C、任务D发生了延时，必将影响到整个项目。而图2的方式，必然会在项目已开始就使得项目经理的精力分散，（焦点？意味着什么？什么才算是焦点），并且对于成本的控制也属于预先支出。如果你相信双赢的话，就必须将多任务模式图按照其他的方式分解。因此项目经理在整个系统中必须时刻的考虑到“双赢”。
姜平在项目中于客户每天保持沟通，如果说每天扎根在客户那里也不为过，但是最终出现的结局仍然是客户需求不断变化。暂且不谈姜平的沟通技巧如何，此处需要知名的两点：“用对方的语调与其谈话”以及“及时地保持与客户的确认”，所有没有异议的话题至少需要做两件事情：1、将其写入到需求书中。2、及时地给客户Email，对问题进行再次的确认。知道这对我们有多么重要的意义吗？
1、 项目经理必须要对整个项目的价值以及影响做一个全面的评估，只有高度的、精确的评估才能让我们更全力以赴
2、 聚焦于焦点
3、 双赢
4、 用对方的语调与其谈话
5、 及时地保持确认
明天继续吧。明天引言中的主要是
1、 项目不是依靠提升各个局部的作战能力而得以提升。
2、 寻找最核心的“罪恶之源”-制约因素
3、 为制约因素松绑。
4、 警钟长鸣。
5、 避免惰性
