软件项目管理面面观之“玩的就是心跳”

玩的就是心跳

电话响了。

“我们想这周完成需求的规格说明书。你能过来看看可以做些什么吗？”

“规格说明书怎么了？”

“我们很急，所以新招了许多人来写规格说明书。我们觉得他们完全不清楚自己在做什么。”

“如果由我们来指导他们编写需求，效率不是更高吗？”

“但是我们这周就需要规格说明书。”

“好吧，我明天过来。”

两个小时之后。

“你能过来看看我们的预估结果吗？”

“规格说明书怎么办？”

“我们没时间了。我们就照现有的需求规格说明书进行。老板要求今天就把预估结果交上去……”

你可能已经发现这一类“心跳游戏”（adrenaline junkie）型组织的特点了：优先级总是变化不休，所有事项都是“昨天”就要，总是没有足够的时间交付项目，每个项目都是加急项目，而且加急项目还在不断出现。每个人都忙得焦头烂额……永远如此。

这些组织里面的人不会思考战略层次的问题，只是按照紧迫程度来完成工作。除非“忙乱指数”非常高，否则该指数通常都会被忽略——尽管重视它很有可能会带来显著的长期优势。人们会一直对其不闻不问，直到它突然（绝对出乎意料地）变得要紧了。“玩的就是心跳”分子相信最好的工作方式不是先规划再行动，而是越快行动越好。

这种文化认为紧迫性越高的项目，收获也越大。如果身处这种文化之中，你很难不受感染：越紧迫越好。因为给项目的时间短得荒谬而通宵加班的程序员被视为英雄（根本不在乎他们交付的程序质量）。每个周末，团队的所有成员都照常上班，以保持他们的工作量：这样做的团队比不这样做的团队更受人赞许。此外，如果你不是一直都过度加班，或者没有发疯一般忙碌，就会被贴上“局外人”的标签，你不是保障组织运转流畅的大忙人之一。非英雄行为是绝对不能接受的。

绝大部分的“心跳游戏”型组织至少存在一个瓶颈，就是那位英雄。他是所有设计的决策者，是全部需求的唯一来源，也可能包办整个架构。他扮演了两个角色：一是让自己表现出常人无法想象的忙；二是引发决策僵局，他的决策一旦公布，就会导致组织的其他部分更加忙乱。

大部分的“心跳游戏”型组织满腔热情地拥抱服务客户的教条：他们混淆了对紧迫事件的响应和值得赞赏的响应。只要客户提出了请求，不管是否能带来收益（甚至不管有没有用），都会立即转化成项目，而且通常截止日期会短得可笑。（更多讨论，请参阅模式38。）这个新项目自然会加重已经在超负荷工作的英雄们的负担，使他们更加手忙脚乱——永不停歇的需求让组织变得异常忙碌。很多这类的组织都（错误地）认为这就是敏捷的全部。

“心跳游戏”型的行动是贸然的，而不会经过思考。其结果就是大部分工作都处在不断变化、无法固定的状态，没有什么可以固定下来，也没有什么可以保持较长的时间。这种不固定的状态一直延续：需求规范不固定——没人真正清楚要开发什么；设计和计划也不固定——它们很可能明天就会改变。紧迫性是唯一的标准，没有人尝试按照重要性或者工作价值来给工作排定优先级。

对于“心跳游戏”型组织，特效药是不存在的。他们没救了，除非取消那些令人心跳加速的任务，同时解雇经理，雇用那些明白“组织只有不再忙于处理突发事件才最有效率”的人。但是这样的人事变动根本不可能被采纳，因为高层领导，通常是CEO，希望看到组织长久地保持匆忙的状态，工作匆忙会给人高生产率的幻觉。而且，如果公司的经理们迷信“玩的就是心跳”，项目团队也会效仿。

“心跳游戏”型组织并不是总会失败，他们当中有一些在多年里一直保持着匆忙的节奏。但是，它们都不可能构建重大的东西——那需要稳定性和计划。亢奋型行为不可能扩展——由一些相对较少的人在没有方向，也没有战略指导的前提下，只凭借非常、非常忙碌的工作，成果十分有限。

当然了，各种组织内都有紧迫的事情，也需要有一些角色去关心紧迫的任务。但是，不是所有的事情都是紧迫的，也不是所有的角色都要关心紧迫的任务。除非化紧迫性为优先级和约束，否则，这种“心跳游戏”的治愈希望是微乎其微了。

死鱼

从开工起，项目就完全不可能完成目标，项目团队中的大多数人都很清楚这一点，却缄口不言。

很多IT项目的目标可以被扼要地概括为：我们要在截止日期之前，完成这一系列功能，达到这种准确度，并且保证足够的健壮性。于是项目团队组建起来，项目目标和约束条件落实为详细的需求和设计，然后发布。

天大的秘密是，项目团队中没有一个人相信项目最终能成功。通常看来，如果其他目标不作修改，期限是不够的。难以思议的是，并没有人指出，失败的阴影正如散发恶臭的大死鱼，把项目变得臭不可闻。

于是希腊式悲剧拉开帷幕，项目进行得步履维艰。毫无意外，在预期交付日期之前的几周，所有的项目成员、项目经理、项目经理的上司以及任何与项目沾点边的人，要么——

(1) 对于项目没有按照即将到来的发布日期进行，表示震惊、气馁、诧异；

要么——

(2) 保持低调，除非被点名问到，否则对任何事情都保持沉默。

为什么如此多的组织里面有如此多的人会用除臭剂掩盖实情，而不是直接指出“项目现在的方式不是我们所希望的方式，死鱼就在那儿”呢？

很多组织过于看重成功，所以任何表达疑虑的人都不会因为说真话得到任何奖赏。事实上，如果谁在项目的前期阶段就声称死鱼的存在，管理层的第一反应多半如下。

“证明给我们看。给我们证明成功的可能性是零。不要拿以前项目的死鱼经验来唬人。现在的项目不一样。请用严密的数学证明来告诉我们失败无法避免。”

一旦你提出任何缺乏精确证据的东西，就会被指责为软蛋或者是试图逃避辛苦扎实的工作：

“你是软蛋还是懒汉？自己选择吧。但是我们怀疑你还能在这个奋进的组织里面待多久。”

在这样的环境里面，“努力”而无法完成比站出来说目标无法达到更安全。确实，有时我们需要勇于面对挑战，在认输之前真正地拼搏一番。非常正确——但区别是，在有确定截止时间的艰难项目中，没人会捱到最后一刻才声明情况的危急。如果项目是给只有18个月后就要发射的通信卫星开发软件（你知道如果错过了这次发射时间，就只能再等16个月），那么，你们每个人每天都要闻一闻项目有没有出现什么异味。只要闻到一丝腥味，你就应该喊出来，因为你非常清楚，如果遇到“死鱼”项目，不到最后时刻是没人说话的。

非常清楚的是，“死鱼”不仅给组织带来破坏影响，而且挫伤了“死鱼”项目团队成员和经理的士气。无论组织文化如何，没有人会觉得长期呆在发臭的“死鱼”项目里很舒服。严密封锁“死鱼”消息的成本实在太高。

献给“蒙特•派森”①迷们：

“项目还没死，它正在附住峡湾！”

“项目没有死，只是在蜕皮！”

“这项目已死。它已经驾鹤西去了。”

“现在上场的是完全不同的模式……”

  Monty Python，英国喜剧六人团，出演了系列电视喜剧片。——译者注

保姆

优秀的项目经理必须对手下员工的能力了如指掌。他分派任务、制定计划，在能用的技术和任务本身的要求之间寻求最佳的平衡点。这是显而易见的。还有一些项目经理更进一步：他们创造的工作环境——不仅是技术性的，而且是社会性的——让人们可以最大限度地发挥自己的能力，并且提高这些能力。这些项目经理确保自己的员工拥有完成任务所必需的工具。这些项目经理也鼓励提问，并且乐意与员工辩论；他们给每位团队成员提出最合适的挑战；他们在需要的时候提出批评；他们建设一个人人乐于工作的场所；他们采取必要的调整以保障各个方面井井有条。简单地说，好的经理培养他们的员工，就像保姆照看孩子一样。

在传统的英式文化中，保姆受雇于某个家庭，负责照看孩子。保姆通常要具有教师、护士和厨师的技能，全面负责孩子的体格、心灵、社交、创造性和智力发展。在每天的日常活动中，保姆要确保孩子远离伤害，保证孩子们得到足够的新鲜空气与锻炼，吃到有营养的食物，加深对世界的理解，掌握更多在世界上生存的技巧。除了照看孩子，保姆还需要促进孩子天赋的发展，并与家长沟通对孩子成长方面的顾虑。保姆要创建出安全的环境，使孩子能适当冒险并从中学到新知。

经理们如果拥有这些与保姆类似的才能，就能通过鼓励和培养员工的天赋，从员工那里获得更多、更好的工作成果。

迄今为止，我为之工作过的最好的经理是Peter Ford。这再明显不过了，比如他让员工在工作时各尽其能。举个例子，我们在一大间开放式设计办公室工作，这不是最好的思考环境，于是他设法为团队弄到一些隔音屏风，并保留了几间“静音室”。所有的这些，还有他为我们做的其他事情，要用到谈判能力和手腕，却不让我们知道。他鼓励我们在系统开发的时候多阅读并讨论新的想法。他为团队买来书籍和杂志，并安排时间让我们聚在一起讨论。当我们觉得不开心或者不舒服的时候，他会注意到这一点，跟我们交谈，帮助我们。他保护我们不受组织其他人和事的干扰，但如果他对我们不满意，他会让我们知道。他办公室的门很少关着。Peter就是我们的保姆。

——SQR　　

你所在的组织或许已经有一些“保姆型”经理，如果你留意，会发现这些现象：不必预约就能见到你的头儿，或者不必在琐碎和令人生厌的管理工作上花费太多时间。周围是开放的氛围，人们畅所欲言，互相学习。这种经理认为培训或进修非常必要，而不是视之为烧钱。他们还会专门安排时间（比如早晨咖啡闲谈或者周五下午阅读探讨），让大家在一起讨论新想法。

只要有人聚在一起，总会有流言蜚语、小道八卦和一些磨洋工的情况。然而，在被经理细心呵护的办公室里面，这类浪费时间的事情极少，因为经理确保团队成员对于实际发生的事情都非常清楚。人们不需要去打听小道消息来了解组织内发生的事情。与之相反，他们觉得自己充分知情和受到信任，把精力都放在本职工作上面。

类似于保姆的经理会把自己看成是工作的催化剂。传统保姆的工作满意度来自于看到孩子能力的发展，“保姆型”经理的工作满意度则来自于看到每个团队成员在个人角色方面得到发展、生产率得到提高，并对自己的工作更加满意。

这个模式的反面是这样的：经理关心的是争权夺利、发号施令、制定流程，逢迎上级；绘制、调整PERT图和甘特图比与团队成员交谈更重要；还有一些经理自己做了太多的实际开发，而没有解决好团队的需求。

你们的组织如何看待经理的角色？他们会因为“催化”了工作受到赞扬吗？你们雇佣的是“保姆”还是“管理者”？