学步园

我只是个受害者
我在1956年曾预言FORTRAN这种程序的寿命撑不过三年，而这只是我的职业生涯中所犯下的诸多重大错误中的第一个。让我告诉你我是如何差一点就铸下另一个更大错误的故事。

失败与成功之间的区别
在1961年，我任职于IBM的系统研发中心时，负责带领一批学生所做的研究案是专门探讨那些已宣告失败的软件开发项目。学生访谈过的项目经理有一打，归纳出造成每一个项目失败的所有因素。我仔细研读这些因素后发现，它们唯一的共同点就是运气不好。诸如计算机中心闹水灾、感冒大流行、在紧要关头挂头牌的员工离职、暴风雪来袭、程序的原始文件受损、甚至还遇上大地震。显然，这些项目经理个个都是自然界定律的受害者。

学生写了篇报告把这个既惊人又令人沮丧的发现给记录下来。我拿来稍事修改，加了些我自己的看法，并打了几通电话给杂志社的编辑征询他们的意见。有一个编辑问我为什么不用较正面的语气来谈谈所有的成功项目有何共同的因素。

「我们没有去研究任何成功的项目。」我说。

「那么，你们怎么知道那些项目没有遇上运气不好的事呢？」（喀嗒）

那个「喀嗒」是他的电话断线也是──在千分之一秒后──我的大脑回过神来的声音。我们立刻抽回那篇报告，另外找了一组学生针对成功的项目再做一次类似的调查。这些专案中的每一个，同样的，也都遇到过某种天然的灾害，但是却有完全不同的结果。
尤其让人讶异的是，计算机中心同样遭火灾侵害之后这两种机构有截然不同的反应。有一个项目就宣告彻底失败，而别的项目却能恢复过来，差别就在处置方式的不同：

1. 所有原始程序的备份早已在公司外的某地另行存放，因而未同遭火灾波及。而失败的项目虽也有做备份，但未定时照规定执行。

2. 硬件用的都是标准架构，因此受损的部分可毫不考虑就加以更换。但失败的项目却为了省下几千美金而使用「接近标准」的硬件。

3. 项目的全体成员都有意愿也有能力全力投入并加班工作来做善后处理、档案回复、以及项目文件的整理等。但失败的项目则有大约两成的员工拿这场火灾做为另谋他职的机会和借口。

4. 既然无论如何一切都得重新开始，成功的项目趁机找顾问来帮忙，利用这场火灾做为重新改组的契机。但在失败的项目中，大家所能看到的唯一机会是，可以把火灾发生前众人都认为难以卸除的失败责任一股脑儿都推给这场大火。

简言之，会造成不同结果的倒不是事件的本身，而是他们对于该事件所做的反应。成功项目的反应是承认自己走霉运，然后担起复原的责任，甚至抓住机会利用这场灾难所带来的一些优势。反之，失败项目则逮到让自己装成受害者的机会。正如某位经理所说的：「我又能做什么呢？整个办公室都烧成了灰烬。」

受害者的语调
从那次之后，我再也没有接过其它计算机中心遭回禄的顾问案，可是，当然还是有许多遭遇其它麻烦的项目找我去帮忙。在这些顾问案的期间，我总是会注意去听经理人员的口中是否出现受害者的语调。若我听到任何的一句，我就与这些自我宣称的受害者共同制作一份效应图，并将所有可能需要人为控制的时间点都清楚地标示出来。

一段典型的受害者语调即一个经理会说：「项目的时程落后，我也无能为力，因为布鲁克斯定律说我不可能增加人手而不使项目落后得更多。」让我们来检查看看该如何把受害者的语调化为控制者的语调。

爱黛拉是一个项目经理，她在加派工作人员之后发现项目进度开始落后。此时，爱黛拉还是可以继续加派工作人员，但这么一来将会造成一个正向的反馈回路，若是没有管理阶层的干预就不会出现这样的回路，如同我们在图6-4中所看到的。当他们找我去帮忙时，我做的第一件事就是向爱黛拉说明，为什么她所做出的决定就是让事态恶化的元凶。这个做法说服她不再继续加派人手，但我想要表达的还不止于此。

图8-2（编注：图略）显示我是如何将图6-4（编注：图略）加以重新绘制，以利用它来向爱黛拉强调在某些地方是由她所控制的。
人为决定的时点是在既不妨碍有经验员工之工作也不增加协调工作之负担的前提下找出增加人手的方法。找出这样的方法是爱黛拉的责任，不过这还是一个容易解决的问题。一旦她认清事实上自己并不是一个无助的受害者，她就采取一些步骤来控制「新进人员之数量」对「已完成之具生产力的工作」所产生的效应。首先，她指派部分的新进人员去：

审查设计和程序代码
修改项目的相关文件
设计测试案例
当其它的工作人员有需要时帮忙打杂

这么一来，虽然她继续添加新人（这么做是出于她自己的选择，如图8-3（编注：图略）中灰色的方块所示），但她让新人的效应成为正向的（如图8-3（编注：图略）中白色的人为控制方块所代表的）。在这么做的同时，爱黛拉还在有经验人员的身上增加了一些工作的负担，不过对此她是有控制的，她发出严格的命令，规定未取得她的同意前任何人不得去找有经验人员讨论问题。这种对于「新进人员之数量」对「待完成之工作总量」所产生之效应做局部的控制，可由图8-3（编注：图略）中灰白各半的符号来表示。

简言之，爱黛拉挑起「创造属于自己的定律」的重责大任，一如图8-3（编注：图略）中的那个新效应图所展现的。与此相反，如果你偏爱自然定律的确定感，我可以推荐你一条与人类行为有关的定律，它同样具有那种天然的可预测性。不论何时当你说出
「那件事我做不到」，你所说的将永远是对的。不过麻烦的是，有时你会变成一个没用的受害者。

我不想再听到任何那类负面的讲法
即使经理人员愿意对自己所采取的控制行动负全责，他们还是会做不好，除非他们拥有正确的观察结果且据以采取行动。正确的观察不会无端发生，唯有费心将管理阶层做决定的工作做好方能达到。
彼得是个软件开发的经理，表面看来他对软件的开发过程还算了解，可是在处理因程序质量不良而造成的危机时，他却不断地做出不当的干预。调查过彼得所负责的几个项目后，我们发现他那些不当决定的起因倒不是他的判断力不好，而是他所得到的与软件质量真实状态有关的信息，容易使人产生错误的解释。

造成信息质量欠佳的原因又是什么呢？当项目开始出现质量的问题时，因为害怕将问题如实以报不知会造成怎样不可测的恶果，这使得人们宁可采取会破坏报告正确性的行动。例如，测试工程师会把所找出的问题当场即予解决，而不循正式管道把问题报告出来。其次，测试小组的负责人在做问题的归类时会把问题的严重性做向下修正。第三，程序设计师在改正过好几个程序的错误后，在报告上却写成只因有一个程序上的错误而造成许多软件功能失常的现象。程序设计小组的负责人会尽量把许多软件功能失常的现象都归类为「顾客对文件的解读错误」或「操作系统上的毛病」。这样的分类法会分散人们的注意力，不把矛头对着程序设计小组。最后，项目经理会将软件的故障报告（trouble report）加以「调整」，朝「最有利的」方向来解释。

这些做法会产生一堆严重误导他人的报告。没有哪个控制者能够以这样的报告为基础而做出有智慧的干预行动。为了向彼得展示我们所认为的真实情况，我们画出图8-4的正向反馈回路。

彼得看到这张效应图后，他的反应是用受害者的语气说出：「这个嘛，如果这就是真实的情况，我也束手无策。你看，在这个回路中并没有人为决定的时点。当有一大堆问题的时候，一般人自然而然就会对如实以报心生畏惧，此外，如果他们是真的害怕了的话，他们总是会找出办法让事情能够变得好看些。如果我拿到的报告是不正确的，也没有什么事是让我做了之后可显示我的优秀，而我如果原本就不是一个优秀的经理，质量问题必然会一个接一个的出现。因此，照你自己所订的模型来看，我是卡在一个正向的反馈回路里出不来了。」

彼得说的也有部分的道理。如果图8-4是一个完整的动态图，他的确是无法可救了。不过一个经理总是有办法在系统里添加一些东西而制造出一个崭新的图型。我们两人合力，弄出了如图8-5所显示的效应图，其中增加了一种可能性，那就是经理人员（或许在无意间）会惩罚为质量问题提供正确量测数据的那些人，并将这类的反馈称为「负面的讲法」。此一做法还会制造出另一个反馈回路，即再度强化人们对于「交出一份情况看来不妙的报告」与生俱来的恐惧。

虽然这第二个反馈回路看起来似乎会让事情变得更糟，但它确实提供了一个人为决定的时点，使得「更糟」或「更好」都能受到控制。经理人员对于提供「正确但令人感到不快的信息」的那些人不必然要施以惩罚。如果对报信者施以惩罚会导致信息系统的瘫痪，何不采取一些步骤来扭转这样的效应，并对正确的报告给予奖励呢？将这类惩罚的效应加以扭转后会创造一个具稳定效果的负向反馈回路，不但可防止对正确报告的天生恐惧，又使情况不致完全失控。

我希望我能够向读者报告说彼得立刻就将这个错误的情况矫正过来了，但是他怎么可能做到呢？如我们所见，像这样的非线性情况是不容易被扭转的。信任要建立起来得花上许多年的工夫才可能，但要将之摧毁殆尽却只需片刻。彼得真心的展开一个管理阶层的训练方案，特别着重在沟通的技巧。他自己第一个报名参加，树立了一个良好的典范。

我在彼得的公司担任顾问好长一段时间，长到足以亲耳听到他改变了自己在不经意间所用的强烈语言，但还不足以亲眼见到他在去除模式2「视负面讲法为禁忌」的工作上是否成功。正如在所有以恐惧为主要变量的场合中，预防工作比起治疗工作当然要容易上十六倍。人们很容易就会落入对自己上司会做出最坏反应的恐惧之中，因此，并不需要力量强大的动态图即可引爆这种恐惧的情绪。

在接下来的几章中，我们将会再举出许多的例子来说明，像这类无意识或无深度知识的管理决策方式会制造出正向的反馈回路，并因此而导致难以挽救的无生产力状态。更重要的是，我们也将看到，能够做出有意识、有深度知识之决策的经理人员是如何制造负向的反馈回路，并因此而终于恢复原有的生产力──或许还能够防止相同的情况下一次不再发生。