在软件开发实践中，我们每天都在和项目管理人员打交道。多年的实践经验告诉我，一个项目的失败往往来自于糟糕的项目管理。
 
    在前面的章节中，我们已经讨论了软件开发过程中的很多话题。很明显，要想做出一款出色的软件产品，或者完成一个成功的软件项目，需要在前面章节中提到的每一个环节上下功夫。例如，团队文化、软件开发方法论、软件开发负责制、简单原则、想象力、架构设计等。相反，要想使项目失败则容易得多，只需要在某个或某几个环节上掉链子就可以了。这其中关键的一环是项目管理。
 
    为什么是由项目管理人员而不是由其他的角色来承担这个关键性的责任呢？要回答这个问题，我们先得来看看项目管理的定义。
 
    项目管理是一个管理学分支的学科，指在项目活动中运用专门的知识、技能、工具和方法，使项目能够在有限资源限定条件下，实现或超过设定的需求和期望。
维基百科
 
    这个定义很好理解。

    如果你在拉斯×××，抓到了一手烂牌（没有成形的制度和文化，没有高素质的人才，没有完善的设计），而你所有的身家都押在这一局，你不可能拍屁股走人，仍然需要振作精神玩下去。客观上——你的赢面不大，但还没有到必输的地步；主观上——你要用牌技和运气放手一博，赢面难看但可以保住身家。项目管理就是你的牌技。

    现在你或许可以理解为什么该由项目管理人员来承担关键性的责任了。你手上拿的牌是客观存在的，在这样一种不利的情况下，如果你的牌技还很差，你还能怎么玩？当你输得叮当响的时候，真的不应该把自己的烂牌，而是应该把自己，从39楼丢下去！问问自己，为什么来拉斯×××？

    是的，在上面的故事中有两个隐喻：一手好牌和牌技。在一手好牌和牌技之间，我选择好牌。毕竟，软件开发不是×××，不应该总是面临牌技的考验。

    我一直认为，好的项目管理，对于项目的成功并没有多少关键性的推动作用（有一定的推动作用），但是差的项目管理，对于项目的失败却要负一种关键性的责任（会输掉有赢面的牌局）。这种想法和传统的对于项目管理的认识不大一样。

    在传统的认识中，项目管理仿佛是解决问题的银弹（这也可以解释为什么项目经理总是拿着更多的薪水）。但实际上，一手好牌才是你最应该追逐的。它会使你的获胜概率有实质性的提高，而不用每一局都玩心跳。

    有心的读者或许已经从本书的写作内容中看出来了，我对项目管理一点也不感冒。一方面，在我的职业生涯中，我见过很多糟糕的项目管理，它们给软件开发工作带来了巨大的负面影响，这使我心有余悸；另一方面，即便对于传统意义上好的项目管理，我也在不断反思它的内容和价值。

    开源软件的开发团队常常是一手好牌。我曾经认真地关注过开源软件社区。可以想象，那些优秀的开源软件作者和贡献者们的工作场景是多么的诱人——极度的投入、专业的技术、高效的工作、友善的沟通。这其中哪一点不是项目管理的最高期望呢？

    我们在现实中看到的却常常是完全不同的场景。例如，项目管理人员与软件开发人员之间的关系总是对抗性的，项目管理人员热衷于干涉不该干涉的事情等。这些场景说明很多人对于项目管理的本质存在误解。本节将会对此展开讨论。

    项目管理包含哪些内容呢？按照传统的说法，项目管理试图获得对5 个变量的控制：

时间
成本
质量
范围
风险

    其中，时间、成本、质量也是衡量项目成功与否的主要指标。为了控制这5个变量，并最终达到项目成功的标准，项目管理人员通常要做这样几件事情——项目策划、风险管理、进度计划、项目跟踪和过程改进。

    我们来看看项目策划。
 
    在软件项目策划中，最重要的一项工作是工作任务分解，此外，风险评估、项目规模估算、成本估算、外部资源估算等也都包括在项目策划活动中。在本书中，我不想过多地解释这些工作内容，只有一点要明确地指出——无论是工作任务分解、风险评估，还是成本估算，都和软件本身密切相关，或者说，完全建立在技术性很强的软件开发工作之上。
 
    传统的项目管理人员一般都不会从事具体的技术工作，他们对于工作任务的理解是不足的。有些“聪明”的项目管理人员会间接地从项目团队中的技术人员那里获得一些信息，然后，按照合同上的时间要求，倒推出一份工作计划。因为是特制的工作计划，看上去总是完美地合乎要求。接着，这份特制的工作计划将成为软件开发人员头上的枷锁，任何工作内容的变动和创新，都会被“项目进度说”的拥趸拒之门外。

    我经常对头脑中闪过的一个场景忍俊不禁：一个项目管理人员趴在手术室的窗外，紧紧盯着主刀医生手上的动作，并且在窗外大喊大叫。
 
    传统的项目管理方式已经被大量的实践证明是低效的。那么，项目管理到底应该做些什么？这或许要从最基本的项目管理思路说起。
 
    在软件开发领域，项目管理工作的基本思路不是控制，而是创造环境和顺势引导。这是因为，项目管理人员往往无法决定自己手中的牌，例如，企业文化和团队文化是公司层面的工作，产品质量是软件架构工程师和其他软件开发人员的工作。对于项目管理人员来说，要想玩好手中的牌，只有优化组合（牌技）一条路。优化组合的意思，是指用出牌时机、出牌组合和出牌次序来玩手上的牌，而不是去干涉牌的大小，老实说，也干涉不了。要想干涉一张牌的大小，是一项长期的工作。例如，追求团队成员的主动性。主动性是决定牌面大小的一个关键因素，要想获得这一点，不是一件简单的事。关于如何提高软件开发人员的主动性，我们在前面已经谈过了很多，这里不再赘述。但是无论怎样，我都敢百分之百地肯定，主动性绝不会来自于项目管理人员的控制。
 
    我总是听到一种愚蠢的说法，项目管理人员可以监督开发人员的工作。为什么需要监督？要监督什么？我想，提出这个观点的人也不是很清楚这些问题。

    监督通常有两个目的。一个是解决信任问题，一个是增加一重质量保证。项目管理人员的监督常常是解决信任问题，换句话说，因为不相信开发人员会完成自己的工作，所以需要项目管理人员的参与。可是我们转换一下思路，就会觉得这个逻辑很可笑。每个人都有自己的本职工作。作为更高一级的管理人员，如果你不信任开发人员的工作，又凭什么信任项目管理人员的工作？

    我们说，项目管理工作的基本思路不是控制，而是创造环境和顺势引导。这是一种新的管理思路。我的解释是，在知识型的企业中，项目管理是一项服务，是一项通过环境和引导来帮助软件开发人员提高生产力的服务。

    我这里有一些支持这种新思路的理由。

    首先，项目管理人员无法直接参与软件生产，以软件开发中的技术风险评估为例，项目管理人员所能直接参与的工作就极其有限。他们提供的只能是一些外围的服务。服务得越好，项目成功的可能性就越大。

    一般来说，要解决软件开发中的技术风险问题，正确的方式是这样：在软件开发过程中，当技术人员表示出自己的担心时，项目管理人员应该立即把这些担心记录在案。换句话说，项目管理人员的工作内容，就是对这些记录在案的技术风险问题进行管理。项目管理人员应该在自己的系统中工作，联系外部资源，与行政部门沟通，在项目团队内部协调，尽可能地为软件开发工作扫除各种障碍。与此同时，他们也应该时时提醒软件开发人员对于技术风险问题的注意。

    有人也许会说，听上去所谓的“服务”与传统意义上的管理也没有什么不同，我平常就是这样做的。不，服务与传统意义上的管理是不同的。所谓服务，是指服务者做好各种服务的准备，等待着去响应软件开发过程中的各种需要。而传统意义上的管理是主动地干预软件开发过程中的各项工作，而且偏向于把人作为一种类似于工具的资源。

    在现实中，我们碰到的往往是热衷于控制的传统意义上的管理方式。项目管理人员成天拿着技术风险列表召集会议，并要求技术人员不断做出解释。项目管理人员决定着解决这些技术风险问题的人员安排和日程表，甚至包括解决方案。事实上，这些会议和活动不仅严重干扰了技术工作，而且在潜在地传播着一种解决问题的错误思想，那就是技术方面的话语权被转移到了管理人员的身上。

    我一直都感到很困惑，如果，有人认为技术人员不懂得解决软件开发中的技术风险，那么，谁会懂得解决呢？

    我有一个忠告，让项目管理人员远离任何技术方面的决策，这一点非常重要。技术决策不是项目管理人员的工作内容。让项目管理人员来做技术决策，就像让人事科长去为病人动手术一样。

    是项目管理人员懂得解决软件开发中的技术风险吗？

    我们总是看到项目管理人员（甚至更高层的管理人员）热衷于在技术会议上发表意见。他们的经典句式很有趣，例如，我不知道，但是我觉得XX 方案更好；这件事做起来很难等。这些凭空想象的意见放大了一些声音，很容易使技术决策走入歧途。更严重的是，这些管理人员根本不用承担任何技术方面的责任，老实说，这会大大挫伤饱受决策错误之苦的软件开发人员的士气和积极性。

    为什么不禁止这种事情的发生呢？还记得我们提到的跳蚤的故事吗？

    把项目管理和软件开发工作清晰地分开，是一种最佳的实践。

    在我看来，项目管理关注的应该是项目进行过程中的各种信息，需要进行管理的也是这些信息，通过信息的管理来间接影响技术工作，而不是直接干涉技术工作本身。另外，那些信息是经过项目管理人员设计的“传感器”获得的，而不是强制软件开发人员停下本职工作来进行整理和汇报而获得。
    “传感器”的做法，是基于服务的思想，而“停下本职工作来汇报”的做法，是基于控制的思想。我们遇到的经常是基于控制的思想。这种管理方式，主要的工作目标是为了项目的可视性和安抚项目管理人员的担忧，而不是为软件开发提供支持。它使原本简单的技术工作加入了很多复杂的非技术因素。

    支持“管理即服务”这条新思路的第二个理由是，在软件开发过程中，项目管理可以被作为一个独立的工作体系。这个体系的工作内容包括：项目信息（规模、成本、风险、质量）采集、统计和分析，资源协调，商务沟通，项目进展反馈等，而不包括技术相关的工作计划、技术决策、技术人员安排、技术问题跟踪等。后面的几项工作可以而且也应该由软件开发人员（架构工程师）来完成。

    项目管理作为一项服务，在商用软件的开发过程中占有重要的一席之地。项目管理对软件开发工作的间接影响，会在一定程度上决定着牌局的走势（毕竟，在一个项目中，非技术性的工作也占有相当的比重）。但是，无论如何，项目管理不应该与软件开发工作混为一谈。