要想成为一名成功的软件咨询师，你需要注意看似无足重轻的语言。在计算机软件领域，到处充斥着这类陷阱。让我来谈谈这个主题，我需要引证一个更广为人知的领域——犬类培训。

我妻子Dani的职业是人类学研究，因此她自然是个富于技巧的倾听者。如今，她已经从人类学家的职位上退休了，但是她却把她作为人类学家和管理咨询师的全部技能和经验，带到了她的新职业中——为狗和饲养者和培训者提供行为咨询(behavioral consulting)。跨领域的综合会产生很多有趣的想法，比如她告诉我的训练军犬的方法。通常，军犬训练过程中最大的问题不在于“狗”，而在于“人”。

倘若有个人听说一只狗接受过攻击性训练，大概有三分之一的人会转过身对狗下命令；“KILL（咬）！”

开个玩笑。

让我们看看狗会怎么做。

为了防止这些鲁莽的行为以及脱口而出的言语，军犬的训练者从来不使用类似于“kill”这些词作为攻击的命令。相反，他们使用一些类似于“health(健康)”的良性词汇，这些词语绝对不会以命令的语气说出来。

这类预防措施是必要的，因为一条经过训练的狗相当于一个信息处理机（information processing machine）,从某方面讲非常像“长着尖牙的计算机”。任意一条武断的命令，对于狗来说可以意味着任何事情，这取决于它是如何被训练的——或者说，被编程的。

这个武断性与狗是否为军犬并无很大关系。训练者也许会对下列情况感到尴尬：Rover听到ROLL OVER命令后，飞奔而出去叼住一个球（狗的名字“Rover”与命令“ROLL OVER”发音相同），好在这并无大碍。但是如果训练狗的时候，是以咬住喉咙作为对命令ROLL OVER的响应的话，那么情况就完全不同了。

做好维护，否则计算机会露出利齿

这和计算机是相同的。因为计算机是需要编程的，又因为程序中的很多字段的含义是非常随意的，所以，一个单独的错误就会将一台原本能提供帮助的计算机转变为可以攻击并且破坏企业的机器。这就是为什么我永远都不能理解我的一些客户，他们对待维护工作的态度如此漫不经心。一次又一次地，我听到经理在辩解，说维护工作可以让能力差一些的（而且便宜的）员工来完成，维护操作的开展也完全没有正规的控制与准则——因为它并非至关重要的。看起来再多的争论也不能让他们相信相反的观点——直到他们经历了一次因维护引起的代价高昂的重创。

幸运（或者不幸）的是，代价高昂的维护事故相当普遍，因此管理者会有很多课程（lesson – 既有“课程”又有“教训”之意），即使学费相当高昂。我私下保留着一个列表，上面记录着我的客户在程序中犯下的代价惨重的错误，其中花费最大的就是维护错误。大部分问题都出现于修改了先前运行程序中的一个数位(digit)。

在所有的案例中，“修改”都被认为是无害的、“微不足道的”，因此，在需要做出修改前，总是由一个检察员临时地通知一名底层维护程序员去“修改那个数位”——不写修改指令说明书、没有测试计划、也没有人复审新的修改，甚至于完全不在乎一个程序员与组织机构日复一日的运作之间的差异。这非常像是一条经过训练的狗执行“KILL”命令——或者是“HELLO”。

只修改一行

我曾经做过研究，确定了在为维护而进行修改时犯错误的可能性，这依赖于修改的规模。以下是表格的第一部分：

      修改的行数        犯错的可能性

1                    .50

          2                    .60

          3                    .65

          4                    .70

          5                    .75

看到如此高的比率，开发者通常会感到震惊，原因有二。首先，在开发过程中做修改比在维护时修改更容易。开发中的修改用于简化、精练代码，并改进代码的结构。通常，这些代码不会被看不见的手从很远的地方进行修改，因此它们不会包含一大堆难以琢磨的子程序调用。在大多数代价惨重的灾难中，都能看到这些程序间调用指令的身影。

第二，在开发阶段的错误变动导致的代价通常影响较小，因为修正这些错误并不会影响到现实中的操作。因此开发者并不会过多地关注他们的错误，也因此更容易低估错误发生的频率。

在开发过程中，你简单地修改一个错误后仿佛什么都没有发生过。不像是维护阶段，那时你必须为错误导致的破坏收拾残局，然后花费无数个小时在各种会议上解释，为什么这个错误不会再次出现了——直到它下一次出现为止。

由于这两个原因，开发者将维护过程中出现错误的高发生率归结为：这是无知的或者缺乏经验的维护程序员引起的。但是如果我们继续看看上述表格的下面几行，我们会发现，真正的起因既不是“无知”，也不是“缺乏经验”。

     修改的行数         犯错的可能性

         10                    .50

         20                    .35

谁杜撰了这些听起来无辜的词语

而且又有多少次你听到那些程序员的经理同意这种论调？以至于“修改很微不足道时”，工作起来就“仓促而粗劣（quick and dirty）”。

如果“微小”的变化真的很微小，这种“无所谓”的态度倒也无所谓——如果程序的维护工作就像是公寓楼的维修工作的话。并不是说看门人的工作不会带来风险，但是看门人也可以这样假设；修理厨房水槽里的垫圈，并不会招致巨大的风险，不会导致建筑物的倒塌并且埋葬了所有的住户。不过，如果对每日运行着业务的程序也作这样的假设，就非常不安全了。然而我们使用词语时过于随便和武断，“维护”一词在各种各样的场景下就被滥用了。

无论是谁为计算机程序编写杜撰了“维护”这个词，他都是个有些粗心、缺乏思考的人，就像那个训练军犬，让它听到命令“KILL”或“HELLO”就去扑杀的那位驯犬师一样。作为“事后诸葛”，我建议“维护”程序员更应该充当脑外科医生的角色，而不是看门人——因为“打开”一个工作中的系统更像是打开人类的大脑，并换上一条神经，而不是掀开水池更换垫圈。如果维护工作被称为“软件脑外科手术”，它的管理还会容易么？

按照这种思路来思考。假设你有一个坏习惯——比如对一只军犬说“KILL”，你难道会对脑外科医生这么说么？“医生，撬开我的头骨吧，切掉这个小毛病。尽管做这一仓促而粗劣的工作吧——这不过是很小的变化！仅仅是一次微不足道的维护！”

职业精神

当然，作为咨询师的你，从来不会在语言上的如此粗心，不是么？但是，当你被正处于麻烦的客户——就像细微的但损失惨重的维护修改——召集来时，就要倾听他们“无辜”的语言。它所包含的线索是，你只需做很小的修改，就能修正问题了。

噢，请等一下！

原文链接: http://secretsofconsulting.blogspot.com/2007/03/innocent-but-dangerous-language.html

发表于 @ 2007年03月19日　16:25:00 | 评论( loading... ) | 编辑| 举报| 收藏

旧一篇:应对各年龄段的批评 | 新一篇:设计者应该知晓什么？