项目百态之# 模式1 玩的就是心跳
## 组织相信忙乱的工作象征着高效的生产率。
%% 电话响了。
%% “我们想这周完成需求的规格说明书。你能过来看看可以做些什么吗？”
%% “规格说明书怎么了？”
%% “我们很着急，所以新招了许多人来撰写规格说明书。我们觉得他们完全不清楚自己在做什么。”
%% “如果由我们来指导他们编写需求，效率不是更高吗？”
%% “但是我们这周就需要规格说明书。”
%% “好吧，那我明天过来。”
%% 两个小时之后。
%% “你能过来看看我们评估的工作量吗？”
%% “规格说明书怎么办？”
%% “我们没时间了，我们就照现有的需求规格说明书进行。老板要求今天就把苹果的工作量交上去……”
你可能已经识别出这一类“玩的就是心跳”型组织的特点了：优先级总是变化不休，所有事项都是“昨天”就要，总是没有足够的时间交付项目，所有项目都是紧迫项目，紧迫的项目源源不断。每个人都忙的焦头烂额……永远如此。
这些组织里面的人不会从战略层次上思考问题，只是按照紧迫程度来完成工作。除非“忙乱指数”非常高，否则它通常都会被忽略——尽管它很有可能会带来显著的长期优势。人们会一直对其不闻不问，直到它突然（绝对出乎意料的）变得非常紧迫。“玩的就是心跳”分子相信最好的工作方式不是先谋而后动，而是竭力追赶时间。
这种组织文化认为紧迫性越高的项目，绩效也越高。如果身处这种文化之中，你很难不受感染：紧迫性是受到鼓励的。那些为了某个短的可笑的期限而加班到深夜的程序员被视为英雄（根本不在乎他们交付的程序质量）。每个周末，团队的所有成员都照常上班，以保持他们的工作量：这样做的团队比不这样做的团队更受人赞许。此外，如果你不是一直都过度加班，或者没有发疯一般忙碌，你就会被贴上“不是自己人”的标签，你不是保障组织运转流畅的大忙人之一。非英雄行为绝对不能被接受。
绝大部分的“玩的就是心跳”型组织至少存在一个瓶颈，就是那位英雄。他包揽了所有设计的决定，是全部需求的唯一来源，或者一个人决定框架的方方面面。他扮演了两个角色：一是让自己表现的比常人难以想象的还要忙；二是引发决策僵局，他的决策一旦公布，就会导致组织的其他部分更加忙乱。
大部分的“玩的就是心跳”型组织满腔热情的拥护客户服务的理念：他们错误的认为对紧迫事件的响应就是值得赞赏的响应。当客户提出一个请求，不管是否存在潜在的利润（甚至有效性），该项请求都会立即转化为一个项目，而且通常截止日期会短的可笑。这个新项目自然会加重本已超负荷工作的英雄们的负担，使他们更加手忙脚乱——所有的这一切无休止的让组织变得非常、非常忙碌。很对这一类的组织都错误的认为这就是敏捷的全部。
“玩的就是心跳”型组织经常会断然行动，而不是三思而后行。这样导致的结果就是大部分工作都处在不断变化、无法固定的状态，没有什么可以固定下来，或者保持较长的时间。这种不固定的状态一直延续：需求规范不固定——没人真正清楚要构建的是什么；设计和计划也不固定——它们很可能明天就会改变。紧迫性是唯一的标准，没有人尝试按照重要性或者工作价值来对工作排定优先级。
对于“玩的就是心跳”型组织，回春妙手是不存在的。他们完全是没救了，除非消除那些令人心跳加速的事情，而且解雇经理，雇用那些明白“组织只有不再忙于处理突发事件才最有效率”的人，但是这样的人事变动根本不可能被采纳，因为高层领导，通常是CEO，希望看到组织长久的保持匆忙的状态，因为工作匆忙让人生出一种高生产率的幻觉。而且，如果公司的经理们是“玩的就是心跳”分子，项目团队也不会相去太远。
“玩的就是心跳”型组织并不是总会失败，他们当中有一些在多年里一直保持着匆忙的节奏。但是，它们都不可能构建重大的东西——那些需要稳定性和计划。亢奋型行为不可能扩展——由一些相对较少的人在没有方向，也没有战略指导的前提下，光凭着非常、非常忙碌的工作所能达到的效果十分有限。
当然了，任何组织内都会遇上紧迫的事情，也需要有一些角色去关心紧迫的任务。但是，不是所有的事情都是紧迫的，也不是所有的角色都要关心紧迫的任务。除非化紧迫性为优先级和约束，否则，这种“玩的就是心跳”的治愈希望是微乎其微了。