软件项目为什么难做

很多项目经理不乏理论知识和技术功底，但还是觉得项目难以推进。有的疲于应付，有的半途而废，有幸能够坚持到项目结束仍“健在”的，也是身心疲惫，谈“项目”色变。

　　笔者本人对第一个项目的记忆还历历在目：那时刚刚被提升为项目经理，并“ 系统 ”地学习了项目管理知识，踌躇满志地进入了一个被称为“具有XX意义”项目，对未来充满希望。但仅仅几天之后，就发现实际情况与想象的完全不同：

　　项目的范围超乎想象，口头承诺多得惊人，客户的抱怨此起彼伏，延期的消息接踵而至，情绪很快就由开始时的“豪情万丈”转为“惊惶失措”。

　　镇定下来之后埋头于解决各种问题，但很快陷入了悬而不决的“协调”过程中。发现作出一个决策必须那么多人同时说“Yes”，但不幸的是任何人可以说“No”。（直到今天，笔者在面试项目经理的时候，问及工作职责时听到的最多的一个词仍然是“协调”）。

　　一般总要等到时间已经刻不容缓的时候才会达成一致（这好像是一个项目中的基本规律），但留给项目组的时间已经不多了，大家必须加班加点，紧追慢干；此时，最让人心惊肉跳的是各种变更，让人猝不及防…

　　另外，中间还要 准备 好应付来自方方面面的“交流”、“汇报”、“检查”。如果运气好的话，可能会迎来领导的关心慰问；如果运气不好话，可能会因为“推进不利”而成为项目延期的“责任人”，轻则批评，重则撤换…

　　随着经验的不断积累，不断反思为什么会出现这些问题。发现项目管理的理论和实践之间还是有很大差异的，其中的一些重要原因与软件项目本身的一些特点相关。

　　第一，交付成果“看不见”，度量困难

　　与普通的项目不同，软件项目的交付成果事前“看不见”，并且难以度量。特别是很多应用软件项目，已经不再是的业务流程的“电子化”，而是同时涉及业务流程再造或业务创新。因此，客户在项目早期对到底要做成什么样，确实很难说清楚，但这一点对于软件项目的成败恰恰又是至关重要的。

　　与此矛盾的是，公司一般是销售人员负责谈判，其重点是迅速签约，而不是如何交付，甚者为了尽早签约而“过度承诺”。遇到模糊问题时也怕因为解释而节外生枝，所以避而不谈；而甲方为了保留回旋余地，也不愿意说得太清楚，更不愿意主动提出来（因为甲方还有最终验收的主动权）。等到项目经理一旦接手，所有这些没有说清楚的隐患和口头承诺，都将暴露出来，并最终都由项目经理承担，所以项目经理刚刚进入项目的时候，会感觉“惊慌失措”。

　　第二，项目周期长，变数多

　　IT项目的交付的周期一般都比较长，一些大型项目的周期可以达到2年以上。这样长的时间跨度内可能发生各种变化。

　　从外部来看，商业环境、政策法规变化会对项目范围、需求造成重大影响。例如，笔者曾经从事的金融项目，临近上线时国家推出了“利息税”政策，造成整个系统的大幅变更。

    从内部来看，组织结构、人事变动等等，对项目的影响更加直接。有时，伴随着新的领导到任，其思路的变化，甚至对项目的重视程度的变化，都可能直接影响项目的成败。软件项目管理中有一个重要的生存法则：“不要相信任何人的口头承诺”，就是这个原因：即使是你绝对信赖的人，也可能发生人事变动，之后你无法保证继任的人员能够继续兑现承诺。  

第三，需要满足一群人的期望

　　 软件 项目提供的实际上是一种服务，服务质量的好坏不仅仅是最终交付的质量，更重要的是客户的体验。尽管客户这两个字一直挂在我们口上，但仔细想想客户到底是“谁”？实际上，项目中的“客户”不是一个人，而是是一群人！他们可能来自多个部门，对项目的关注点不同，在项目中的利益（得与失）也不同。所以，当我们谈到满足“客户需求”的时候，实际的意思是“满足一群想法和利益各不相同的人的需求”。

　　除了表面的需求，客户个体其实还有隐含的“需要”。举个生活中的例子，买衣服的人都会谈颜色、款式和面料等方面的需求，但买衣服隐含的需要可能是“御寒”，可能是“漂亮”，也可能是“体面”，而且这些需要不会直接说出来。如果不弄清客户的真正需要是什么，可能一件一件地试，但客户始终都能挑出毛病。

　　如何应对上述三个问题呢？

　　第一个问题可以通过公司的组织级的职责调整来解决。在本公司内，谈判时客户经理和项目经理同时参与，客户经理负责 商务 条款—《合同》，项目经理负责工作范围和验收标准—《工作说明书》，问题已经基本解决；第二个问题，通过正规的变更控制和风险管理可以控制，这方面的文章很多，不再赘述。另外，公司运营模式的改变也是解决这类问题的途径。比如，提供解决方案，客户有参考基础，通过差异分析解决问题；再比如，公司如果具备咨询 能力 ，了解客户业务问题，帮助客户理清需求，都可以很大程度上解决类似问题。

　　第三个问题通常是项目经理感觉最棘手之处。回到上面买衣服的例子，软件项目类似，但是更复杂：好比是要做一套制服，同时满足不同人御寒，漂亮和体面的需要。反映在项目中，就是整体目标和个体利益的之间“矛盾”和组织各级的“ 政治 ”关系。而项目经理没有决策权，如果找不到问题的关键，就只能是“平衡”各种需求，“协调”组织关系。

　　买衣服解决的关键是必须弄清制服是什么场合穿的，并据此找到共同的需要，冬天户外穿就只能牺牲漂亮，春秋室内穿不用考虑御寒。这种共同的需要，就是项目的目标。忽略了项目目标，你根本无法达成一致，只能陷入不断的“协调”过程中；而忽略了个体的需要，客户不会有愉快的“体验”，你很难获得大家的支持，甚至陷入政治纷争，最终失败。

　　对“政治”的敏锐性是项目经理的一个重要技能， “斡旋”能力也项目经理的一个重要职责。一旦将个体的需要统一到项目目标之下，项目经理就真正获得了项目的驱动力。

    下面通过与大家分享一个实际案例，说明如何获得项目的驱动力。

　　案例：这是一个客户高度关注大型软件项目，进度已经相对滞后。正当所有的人都在紧张地追赶进度时，客户方的一个负责人突然提出修改进度计划，将其中系统的一部分提前上线。因为项目的数据移植和切换都是作为一个整体来处理的，此方案需要增加接口 开发 和数据移植的工作量，额为投入很多资源；其次，切换方案的修改会影响已经展开工作，这些都对项目的最终交付日期会造成巨大的风险。但是，无论项目经理如何解释，对方仍坚持要求公司增加人手，部分提前上线。

　　处理：项目经理与项目总监进行了分析，首先认为这样的决策可能是更高级别作出的。这点很快得到了验证，是客户的一个部门经理的决定；要求变更的负责人只是执行者，跟他解释无法改变决定。

　　根据这一情况，项目总监与客户方的部门经理进行了沟通，获知了变更计划的真正的原因：由于项目延期，上级对项目能否按期完成忧心忡忡；部门经理决定通过部分提前上线的方式“展示”项目的执行力。看来，决策的症结还不在部门经理这里。

　　项目总监求助公司高层与客户高层进行了一次沟通，了解到高层真正的担忧并不是“延期”本身，而是项目 信息 不透明，过程不可控，“没人说清楚到底要延到什么时候！” 

　　至此，状况基本清晰。项目总监与再次与客户的部门经理进行沟通。首先，告知客户高层的真正担忧，对于这个反馈信息部门经理非常重视，也很感谢，立刻拉进了与项目总监的距离。其次，项目总监提出，部分提前上线的方式其实没有解决高层担忧的根本问题，且最终的交付风险增大，只是风险后移，最终可能使其处境更为严峻。最后，建议不要修改计划，而是主动将项目的进展状态和问题向高层汇报，使得项目过程透明，将所有人的精力集中到按预期交付项目上。客户接受了建议，沟通和透明增加了高层的信心，改变了项目的处境，而且项目组还获得了很多意想不到的 资源 。

点评：从一个变更计划的需求之下，反映的是不同的需要：项目负责人，是执行者，需要是坚决的贯彻部门经理的决策；部门经理，是决策者，需要证明项目的执行力，增加 高层 信心；客户高层，决策的“影响者”，其担忧的内容直接影响决策。可见，一个需求下面有三种“需要”。要统一认识，必须回到整体的项目目标 “按期上线”（在这个目标上各层很容易达成一致）。此目标下，最有效的措施不是提前上线，而是增加项目的透明度，而且，这个措施同时可以满足所有人的需要。通过这个措施，将所有人的注意力聚焦到确保最终交付日期的目标之下，从而获得了项目的驱动力。回到案例的起点，如果项目经理仅仅匆忙决策满足客户需求，向公司施加压力要人，及时按期完成了部分系统，最后仍可能成为项目整体延期的罪魁祸首。这就是一个普通项目经理和一个优秀项目经理的本质区别。

　　总之， 软件 项目难做是客观的事实，项目经理除了扎实的理论 技术 ，对组织关系的敏感，也是成败的一个重要原因。衷心希望项目经理在遇到难题的时候，能够冷静 分析 问题的症结，挖掘深层次的原因解决根本问题。