《程序开发心理学——程序开发组》

程序开发是一项个人行为——也许与其他职业相比，程序开发的这一特点尤为明显。此外，这种个人的行为取决于程序员自身的、而不是其他人的个人能力。你每天遇到的其他程序员是多是少，对你的程序开发工作来讲会有何不同吗？如果被问及此类问题，多数的程序员会说，他们宁愿独自工作，而且其工作环境中最好不要有任何其他人的打扰。
       上面一段中所罗列的一些观点，也许就是在改进程序开发方法的过程中，我们将遇到的最大的拦路虎。首先，如果这些的确就是人们对程序开发这一职业的普遍认识，那么人们对这一职业将会为之吸引、还是敬而远之，将只取决于他们是否喜欢独立工作、还是喜欢与别人一道工作。社会心理学家告诉我们：不同人的性格特点也不尽相同——这一点似乎人人皆知，但是如果打上权威的标签，恐怕说出来的效果会更好。对于人们通常的个性气质，有一种方法是通过三个方面来进行衡量——一个人或者是“服从的”，或者是“进取的”，或者是“超然的”。服从型的人之性格特点是，其态度倾向于“与他人合作，并且会对他人很有帮助”；进取型的人则总是希望“赢得金钱和声誉”；而超然型的人则倾向于“只有独自相处才能有创造力”。
       实际上，每个人都是上述三种态度的混合体，只不过大多数人在某一种特点上的倾向性更重。毫无疑问的一点是，当今的程序员绝大多数都倾向于“超然的”类型；究其原因，一方面是他们个人的选择，同时也是因为现在雇用程序员的政策——这种政策常常会倾向于寻找这类人。而且在很大程度上，这种选择还算不错——因为程序开发中的大部分工作，都属于“独立进行与创造性”的类型。
       然而与其他的好事一样，程序员的“超然”经常被强调得过了头。尽管他们与其他人相互隔离，他们与程序的距离却更接近了。确实的，他们的程序常常就是他们自己的扩展——比如说在程序中附加个人姓名，这种令人生厌的风气，就是对这一点的很好证明。起始，即使程序的作者没有被官方授予署名权，程序员也可以清楚的知道，某段程序的作者是谁。
       那么，保留对程序的“所有权”会有什么错呢？艺术家“拥有”他们的绘画作品；作家“拥有”他的著作；建筑师“拥有”他们设计的建筑。这些技艺精湛的劳动者，之所以可以陶醉于平庸之辈的赞赏和效仿之中，难道不正是这种特定的作用吗？在开始阅读之前，如果我们希望了解某本书的内容，封面上的作者署名难道不是非常有帮助的吗？进一步讲，这一点对于程序不也是同样适用吗？如果人们真的会阅读程序，那么也许是适用的，然而我们知道的是，很少有人这样做。因此，对于某个程序员的崇拜，不仅不会导致对他所编写的程序的效仿，相反却只会养成其怪癖的程序开发风格。正如我们在“艺术群落”中所看到的那样，每个人都知道如何打扮得像一位艺术家，但是很少有人能够像真正的艺术家那样动手画上一幅作品——即使有，恐怕也不会很多。
       “基于特性的”程序开发方式真正面临的困难来自另一个方面。如果我们认为一个作品不入流，无论是绘画、小说还是建筑物，都无非是口味差异的问题。但是如果我们认定一个程序是不入流的——尽管我们已经知道，在判断“优秀的程序“这一问题后面隐藏着很多困难——这种结论至少是潜在的经过了客观的证明或证伪之后才得到的。最起码的，我们可以把程序交给计算机，然后检查一下其输出结果。面对关于其作品的批评意见，如果一位艺术家觉得不中听，他可以完全置若罔闻；但是，程序员又怎么能对来自计算机的评价置之不理呢？
       表面上看，来自计算机的评价似乎是无可争辩的，而事情果真如此，程序员在自己的程序中署名的做法，必将严重的影响到他的自我形象。每当计算机查找出程序中的一个错误，这个程序员就肯定会这样来推理：“这个程序有缺陷。由于这个程序是我的一部分，是我的扩展，其中甚至还有我的名字，所以我也有缺陷。”
       这种自我鉴定令人感到刺耳，所以极少地被贯彻实行。针对被称为“认知失调”的心理现象（在某些情况下，当你的行为与你的态度相反时，态度会有所改变以和行为保持一致），社会心理学家Festinger曾经进行过一些研究；在他之后，别人又进行了一些有趣的实现，目的在于揭示这一现象的本质。关于认知失调的一个经典的实验，是这样进行的：测试者被分为两组，要求每人各写一篇短文，从正面来论述一下他们本来极不同意的某个观点。在第一组中，每写一条理由，就可以得到1美元的奖励；而在另一组中，每条理由的奖励是20美元。在实验结束前，还要针对其观点，再次对每个人进行测试。我们也许会根据“常识”认定：相对于1美元的奖励，面对20美元的奖励人们更容易改变其观点。但是认知失调理论却预言：1美元那个小组的成员才更容易改变其观点。这个预言，已经被数十次此类的实验所证实。
       认知失调理论背后的道理非常简单。在上面简要介绍的那个实验中，两个小组的测试者都必须完成相同的任务：写一篇驳斥自己所持观点的文章。在通常的情况下，他们都不会这么做——因为，试图去论证自己本不相信的观点，这种行为无异于“伪善”或者“虚伪”，在我们生活的社会中，这两种行为都是受人鄙夷的。这样，就构成了一种失调的环境。一个人如果自认为是诚实的，那么此时此刻，其心中的自我形象就会与客观实际发生冲突——“我居然违心写了这样一篇文章”。根据这个理论，失调对于人类而言，是一种不适的、不稳定的状态，因而人们必然会通过在两种态度之间进行选择，以尽快脱离这种状态。为了脱离失调的状态，造成这种失调的某个因素必须让步——无论是这个还是那个，必须选择其一。到底那个因素将会让步，这样取决于当时的条件。但是一般而言，不会是此人的自我形象——即使是最不可思议的论证，人的自我形象也能得以保留下来。
       在刚才所述的实验中，可以获得20美元的测试者，将很容易从其失调状态中解脱出来。“当然”，他们会这样对自己（或者任何可能提出质疑的人）解释说，“我并非真的相信那些观点。我之所以生成自己相信，完全是为了获得金钱。”为了金钱而无端编造理由的行为，虽然不是一种令人起敬的美德，但是与质疑自己的信仰相比，却要好得多。但是让我们看看，仅可以获得1美元的那个小组的成员们将会处于何等两难的境地。虽然参与心理学实验的测试者都是尚不富有的大学生，但是即使是对于他们而言，1美元依然是微不足道的。于是，另一小组用来脱离失调状态的托词，对于他们就不再适用。因此为了从失调的处境中解脱出来，他们必须从其他方面寻找借口。至少对很多人来说，最容易的一个解决办法就是使自己承认：“我原先反对的这些观点，其中也确实有些道理。”——只有这样的自我解释，他们撰写这些短文的行为才不至于是虚伪的，而成为了一种目的在于培养公平和诚实意识的练习，而且这种意识可以使人们能够同时看到问题的两个方面。
       在另一个应用中，认知失调理论可以准确的预言出，在做完一项大的交易（比如，购买了一辆轿车）之后，一个人的行为将会有何倾向。比如说有一个人购买了一辆福特轿车，如果你塞给他一大堆有关轿车的广告并要求他阅读，那么他就会把大部分时间用于阅读有关福特轿车的广告。如果他购买的是雪佛兰轿车，那么他就会对有关雪佛兰的那些广告更加关注。其实，人们一旦意识自己有可能进入认知失调的状态，就会有意识的去回避那些可能导致失调的信息——刚才的实验就是这样的一个例子。因为如果购买的是一辆福特轿车，那么人们就绝对不愿意发现，事实上雪佛兰轿车更好；而避免发现这一情况的最好方法，就是不要看有关雪佛兰的广告。这样，无论看多少有关福特的广告，购买了福特轿车的人也不至于会发现原来自己并不是一个聪明的消费者。
       现在认知失调对我们的程序开发中的矛盾会产生什么影响，已经再明显不过了。如果一名程序员真的把自己编写的程序视为其自我的延伸，那么他就绝对不会希望在他的程序中发现任何错误。不仅如此，他还会尽力去证明，自己的程序都是正确的——甚至于，即使他发现了重大的错误，他也会睁一只眼闭一只眼，对错误视而不见。这种从认知失调中解脱出来的方法，实际上每个程序员对其现象都非常清楚——当然，仅仅是对人而不对己。当程序员带着他的输出打印清单穿过门厅时，这些文档很薄。如果无法隐藏程序运行过程中的错误，程序员就会像下面一样的加上一段注释：“负责卡片穿孔的操作员又把事情搞砸了。”或者，“操作员把我卡片的次序弄错了。”或者，“什么时候我们的穿孔错误才能得到修正，并且可以正确的复制？”这类抱怨有几千个花样，然而有一句话尽管非常简单，我们却从未听到过：“我自己又弄砸了。”
       当然，在错误很轻微、还不至于根本就没有输出的时候，程序员解决认知失调的方法甚至会更加简单——只要对其中的错误视而不见即可——其实，这些错误无论如何都是无法忽略的。假设其中没有任何错误：从某种意义上讲，人类的眼睛几乎是万能的——只要主人不希望看到某样东西，它们的确就可以视而不见、熟视无睹。那些精通于调试他人程序的程序员，可以逐一地举出成千上万的例子，来作为这个论断的佐证。如果注意力只是集中在他们自己的程序上，那么即使是输出中再明显不过的错误，也会被程序员忽略掉；而旁观者则可以一眼看出这些错误。所以，即使是来自自然的、难以接受的反面证据，人们也往往会认定自己的程序完全正确。其实，这种倾向是再正常不过的了。如果我们想要解决阻碍程序开发质量提高的那些问题，如果我们想要从满足功能要求这一基本层次出发，那么我们将不得不对此有充分的认识。
无私式程序开发
       针对上面提到的在程序开发中的唯我独尊问题，我们应该采取什么措施呢？管理学方面的资料通常都会建议，主管应该规劝手下的每一个程序员，要求他们加倍努力地查找自己程序中的错误。也许，主管每天都应该在程序员之间来回巡视，不时地要求某个程序员介绍一下他自己发现的程序错误。但是这种办法难以奏效，它带来的后果，与我们的心理学知识所讲的完全相反；因为，一般的人会把这种检查视为对个人的一种考察。此外，也不是每个程序员都有一位相应的经理——或者即使有主管，这位主管在看见某行程序被用红色突出显示后，至少应该能够明白是什么样的错误。
       不，解决这个问题的方法，并非单刀直入式的着手处理——因为这样的进攻只会引起程序员的抵抗，而这种抵抗正是我们希望戒除的。确实，为了解决唯我独尊问题，必须重组社会环境；然后，通过这种方式，在这个环境中重新建立程序员们的价值体系。在讨论具体的方法之前，让我们先来看一些例子。这些例子将告诉我们，在采用这些方法之后，可能会发生什么情况——它们对程序员本人及其程序会有什么影响。
       首先，请不要把这种重组看作是社会理论学家们象牙塔式的梦想。有一些程序开发组，确实已经克服了程序员的唯我独尊风气；实际上，远在计算刚刚成为可能之初，就已经有程序开发组能够解决这个问题。John von Neumann很早就意识到，他在检查自己工作方面，确实能力不够，他也许是能够认识到这一点的第一位程序员。那些与他相识的人们回忆说，von Neumann总是跟别人讲自己是多么蹩脚的程序员，而且不厌其烦的请别人阅读自己的程序，期望发现其中的错误与纰漏之处。然而在今天人们的心目中，von Neumann 一定是位无与伦比的计算天才——他浑身上下每个毛孔都应该是完美无缺的。当然，von Neumann的天才丝毫不容怀疑。然而他对自己作为一个人所具有的缺陷非常清楚，他的这种自知之明，也使他远远超过当今的一般程序员。
       通过培训，凡夫俗子也能意识到并接受其自身人性的方面——亦即，他们无法与计算机相比的那些能力——并且对其作出正确的评价，从而在与同伴们共同工作过程中，能够尽量对此加以控制，以保证开发工作的圆满完成。Bill G. 是早期空间跟踪系统的一名成员。他负责的工作，是编写一个模拟器，对整个网络中的空间跟踪站以及实时的输入进行模拟。他的系统要求，即使没有连到全球网，也能够实时的对系统中的其他部分进行检查。这个模拟器的核心，是一个非常微小而紧凑的循环；实际上，它只有13条机器指令。Bill在这个循环上花费了很多时间后，自己终于觉得有些信心了，但他还是希望找到一些要求苛刻的人，对程序做吹毛求疵式的检查——在他所在的程序开发组，这是一项必须做的工作。
       Bill找到了Marilyn B.，她愿意仔细读他的程序，他也细读她的程序，两人相互交换。在他们的程序开发组中，这是再平常不过的事；确实，没有人会在没有请旁人做这样仔细推敲的情况下，就急于到计算机上运行程序。只要有可能，就会以这种交换的方式进行互评，这样当事人就不会感觉到，自己正在受到别人的批评。但是对于Bill来说，由于他在这种方面已是训练有素，所以没有必要用交换的形式来保护自尊心。关于程序开发这一过程，他的价值观念认为，隐秘的、不与人分享的程序开发方式很不好，只有开放的、共享的程序开发方式才是好的。在他编写的（不是“他的”，这里的字典中没有这个词）程序中，可能发现的错误是人人可见的简单事实，曝露出这些错误，不过是为了将来更好的改进，所以并非对他个人的攻击。
       在这个特定的例子中，Bill 经历了他的“程序开发生涯中糟糕的一天”。经过反复的检查，Marilyn在他的代码中发现了很多错误；随着错误一个接一个地不断被发现，Bill反而变得越来越开心。要是Bill受过的训练和我们大多数程序员一样，那她肯定早就与他们一样，开始忙着为自己开脱责任了。最后，在他们的一次学术会议上，他向全世界公布了一个令人瞠目的事实：在他短短的13行代码中，Marilyn成功地找出了17个错误。只要你愿意听，他就会不厌其烦地向你解释，这是怎样一回事。实际上，经过这次演习后，他只是认定那天并非他编写程序的“良辰吉日”。在那天剩下的时间里，他干脆把程序放到一边，然后一而再、再而三地到处向周围的人讲述这个小插曲中的每一个令人捧腹的细节。
       而同时，Marilyn并没有因为自己在这件事中起的作用，而感到暗自窃喜；她能够正确地对待这件事，她也能清醒地意识到：如果在程序中发现了17个错误，那么可能还有更多的错误。她特别清楚，虽然没有亲手起草这段代码，但是在对这段代码进行了相当长时间的修改之后，自己与Bill此前一样，已经把这段程序内在化了——也就是说，她自己的观念已经融入于其中了。因此，她同样需要找一位批评者。那天下班前，一边是Bill继续向同事们讲述这件快事，而在另一边，Marilyn和其他人一起又发现了三个新的错误。
       作为这个故事的尾声，我需要指出的是，当最后这段程序被加载到计算机上后，哪怕是经过任何“恶魔式的”测试，也没有再发现任何错误。实际上，这个模拟器已经被至少10个计算中心用于实时操作，并且在至少9年之内没有发现其他错误。对于每个发现的错误，Bill并不是视之为对其自尊的伤害——事实上，这种自尊恰恰体现出一个人的愚蠢；否则，请设想一下，这个故事的结尾会是如何的不同。
       这个故事并非只是一次孤立的事件，故事中的开发组也并非绝无仅有。然而，为什么这种程序开发组不是那显山露水？为什么“无私式程序开发”没有得以更加普遍地推广？人们似乎都认为这类开发组是凤毛麟角，大家之所以会有这种印象，与很多因素有关。首先，众多成功的软件公司，其实都建立在这种交流方式的基础之上，但是这些公司通常只是把这方面的知识看作是有价值的专有信息，除非你面对面地询问，他们才会承认。其次，采用这种方法的程序开发组都会及其自我满足和稳定，因此我们所见到的那些为工作而徘徊于个计算中心之间的程序员，不大可能来自于这类程序开发组。而且，为了保证工资能够持续地增加，这些“吉卜赛的”（吉卜赛人以过游荡生活为特点）程序员必须制造这样的神话：只有天才的头脑，才能编写出最好的程序；除此之外，别无其他可能。
       是的，没有任何人验证过，采用无私式程序开发方法与那些程序员各自为战的方法相比，完成工作的质量的差别。这类方法之所以没有为更多人所知的另一个重要的原因。关于影响程序员生产效率的因素，虽然有很多实验做过研究，但是这些实验的设计大都存在缺陷——它们过于重视程序开发过程机械的一面，而忽略了其社会性的一面。比如，某项研究中可能会对分时系统与批处理系统进行比较，也可能对比一下A语言和B语言，其目的则很可能是，有人试图证明：他建立一个分时系统或者开发B语言的一个编译器的设想是合乎情理的。进行这些实验的人，似乎都想当然的认为：程序开发自然是以单独的个体为单位进行的。他们之所以这么认为，是因为这是他们通常最可能的工作方式。此外，对多个个体进行研究，问题会复杂得多。如果你在对X和Y两个系统进行比较分析之后，发现实验数据90%的偏差都属于不同程序员个体之间的差异，那么有谁还会愿意徒增困难和成本，去研究程序开发组的表现呢？
       如果程序员对他们各自需要实现的目标（高效率编写程序或者快速完成工作）理解不同，他们编写的程序也会很不一样。为了评估这种差异，我们进行过很多研究。在对方法进行讨论的一章中我们曾经简要介绍过另一则有趣的轶事，这件事可以用来说明其中一个方面。与通常一样，我们雇用的测试者都是相互独立的，实际上他们都是选了一门为期三个月的课程的学生。但是，其中有一名测试者来自于一个采用无私式程序开发的开发组。又一次他前来找我，告诉我说，他的工作已经初具规模，现在是需要有人来对他的工作进行检查的时候了。鉴于这些实验的目的并非研究集体工作与个体工作之间的差异，我只好违背自己的信条，要求这位测试者在没有外部协作的条件下继续工作——因为否则，就会引起实验数据中的偏差。
       作为这个故事的一点间接说明，我们必须指出：虽然参加实验的程序员解决的是同一个问题，但是根据评估员的意见，这名程序员的工作，显然要比另外四个人的工作组织得更好，而且运行得也更好。当我们和他讨论这个问题时，他解释说，在实验期间他保持了他在自己原来的程序开发组里的一贯工作风格——始终注意保持程序的整洁和易于理解，以便将来终有一天别人来阅读这个程序。促使人们采用无私式程序开发方法的最初的也是最强烈的目的，仅仅是为了检查程序中的错误。然而透过这个例子，我们可以领悟到，无私式程序开发方式的优点，还远远不止这些。实际上，参照好的程序开发方式所应具备的四个因素，依照该方法对这些因素的影响对我们自己做一检查，将是大有裨益的。
       在满足功能定义方面，这种方法的价值显而易见。就开发进度而言，虽然其对程序完成平均时间的影响并非一目了然，但是从我们所举的调试模拟器的例子可以看出，其对程序完成时间偏差幅度的影响却是显然的。如果说在编写程序的过程中，程序员的运气是由日期决定的话（似乎很多资料都支持这一观点），那么在手背的那天编写出来的程序，就需要一个特别长的调试周期。就Bill的程序而言，可能需要好几个星期，才能将20个错误完全排除。而且，非常可能出现的情况是，即使在该程序已经与其他程序集成起来之后，还有至少一个错误会漏网并残留在系统内部——这将会造成系统其他部分开发的返工，或者至少其进度将难以预测。
       不仅是调试时间的偏差幅度减少了，而且由于每段程序都有不止一个人熟悉，所以对实际的工作进展作出客观的估计，就是一件很容易的事情了。这样，就不必仅仅依赖于某个人的判断；否则，很难保证这一个人能够不带某种偏见。同时由于我们确定，至少有两个人能够理解该程序，所以程序的适应性也将得到提高。在某些特定的程序开发环境中，这意味着无限的提高。另外，在程序员中很可能发生的情况是，有关的某位程序员生病了、怀孕了或者找不到了。现在，即使出现这种情况，整个网络的运转也不容易受到影响。这不仅减少开发进度的偏差，而且在将来的某一天，一旦需要对程序进行修改，也会更容易找到一个了解它的人。
       关于效率的问题，我们很难做出严格和迅速的说明。但是几乎可以肯定的是，通过这种方法所开发出来的程序，没有任何理由会比通过其他方式开发的程序效率要低。尽管程序整体的效率通常主要取决于最初确定的结构，但是通过请别人帮忙阅读程序，我们至少更有可能将最低效的方面消除掉。
       这种方法的最后一个好处就是，它对阅读他人程序的人自己也有积极的影响——因为如果我们能够正确理解阅读程序的重要性，那么通过阅读他人程序这种实践，他必然会成为一位更出色的程序员。在有关程序员培训的章节中，我们还将就此问题做进一步的探讨。即使缺乏专门的教育措施，我们仍确实可以看出，这些程序开发组的整体能力和水平会自行提高。
建立与维护程序开发的环境
       如何营造如我们所描述的这样一个令人向往的环境呢？这个问题，与在该环境建立后，如何维护它的问题很不一样。相对而言，维护是一项容易得多的工作；而在建立这种环境的过程中，程序开发组现有的原则和观念需要转变，往往伴随着与其社会结构中诸如“锁定”或“凝固”等现象的斗争。某些条件所导致的环境，将反过来有利于该条件自身的保持，而一旦出现这种条件，凝固现象就会发生。比如一个调频广播的调谐器，可以将它设计成自动搜索到调谐旋钮范围内的最强信号处。一旦这个设备捕捉到了某个电台的频率，只有通过一个更强的变化才能解除它；否则，任何微小的变化都会由于调谐器的自动补偿而被抵消。这种锁定现象可能发生在任何系统中——生理系统、电子系统、生物系统，尤其是在我们正在研究的社会系统中。
       社会系统中锁定现象的一个典型的例子，就是各个计算中心对某种语言的接受倾向。一旦某种语言已经被接受了，其他新的语言就很难再进入其中——因为只要多数人使用原来的语言，沿着大家常走的道路将会带来更多的好处：如果需要帮助，你可以更容易获得；如果需要子程序，你更容易找到现成的；使用大家常用的语言，计算机更易于制订运行的计划；由于提交的代码类似，打孔机出现的错误将更少；使用原有语言编写的程序，其开发过程更顺利，效果更好。
       与在程序语言方面的凝固现象一样，在一个计算中心里同样会建立起一个整体的社会环境，对于无私式程序开发方式，这种环境要么积极提倡，要么一味抵制。当一位新的程序员加入到这个环境后，通过与其他“原住的”成员的交流，他对待问题的态度将会被渐渐地重新塑造。比如要是有一次他向别人请教，但是却因为其程序中的错误，被人耻笑为愚蠢，那么他恐怕就不会再尝试第二次了。反过来，如果有别人来找他，请他帮助审阅自己的程序，那么这个人就会当这他的面，委婉而含蓄地对他的能力大加吹捧，于是在下次需要向比人请教的时候，曾经被奉承过的这个人心里就会有一种威胁感。在很大程度上，我们的行为方式会在不知不觉中，趋同于我们周围人们的行为方式，因此，任何一个正在运转的程序开发组，都会倾向于将每个新加入的成员，纳入该开发组的程序开发指导原则的轨道之上。
       在有新成员加入的时候，程序开发组固有的指导原则自然会受到一些影响；但是有的时候，他们还需要面对来自其他方面的威胁，这类威胁要远比由一两个新成员构成的威胁更大。来自组织内部领导高层的干涉，总是不断地威胁到无私式程序开发的原则。主管们倾向通过“积极进取的”方式脱颖而出，同时他们也不会承认这样一个事实：在对金钱和名誉的追求方面，其他人的观念与他们并不完全一致。本来，只要在对个人才能的互相尊重以及为了共同的事业而进行合作的基础上，程序开发组就可以顺利地开展工作。然而，这些却尤其令主管们不知所措，因为他们不能理解其原因何在。恰恰相反，他们总是认为别人都和他们一样——之所以要工作，仅仅是为了金钱，或者是由于感到威胁。
在程序开发组中，积极进取的主管与温顺服从的或超然的程序员之间，常常会发生一些冲突。在一家计算机制造公司的软件部门发生的一件事，就是一个特别恰当的例子。这个部门的一个程序开发组一直担当着团队的任务，在开发某个全新的、具有很大市场销售潜力的系统时，该开发组取得了非凡的成功。鉴于该开发组的成绩是如此显著，公司的领导层决定为该开发组颁发奖金。根据通常的管理模式，他们要把这笔奖金颁发给领导该开发组的主管。但是这名主管却告诉上级领导，除非这笔奖金是颁发给全体成员，否则他不会接受这笔奖金。你可能设想的出来，当时上级领导们会对他的这一做法如何不解。
       其实，只要他们能认识到，这项工作的成绩是属于整个开发组这一集体的，就会认为该主管的反应非常正确，而不是无法理解的。然而有的领导居然认定，这只不过是他为谋求更大数额奖金而使的一个花招；而有的领导则猜测，他领导的这个程序开发组正在变成一个“狂妄自大的”集体。无论如何，他们还是勒令这名主管接受这笔奖金，同时也促使该开发组解体——这种想法实在有些龌龊。主管领到奖金后，立即平分给开发组中的每个成员；然后，该开发组全体成员一同离开了该公司，转而投向另一家独立的软件公司。
       在这次事件中，该开发组通过在接受奖金后辞职来保护自身，以避免遭受来自外界的威胁。要是公司的高层领导们能够懂得应该给该开发组什么样的奖励，或者要他们在处理问题时更加灵活，完全应该可以找出一个可行的解决方案，并且使该开发组能够对其他开发组的工作产生有益的积极影响。但是高高在上的领导们总是认为：任何工作之所以能够完成，完全是由于某位领导出众能力的直接结果，因此，这些领导很难找到解决此类冲突的办法。即使有些领导能够承认工作是由整个开发组完成的，但是在其他方面却又不一致——比如，他们不会认为开发组的产品是整个开发组共同的财产，更不会认为这个产品中凝聚了每个成员的汗水和心血。
       在另一个有趣的例子中，有一个由10名程序员组成的开发组，集体加入到一家制造飞机机身的大型公司，隶属于其中的一个程序开发部门。在此之前，他们已经共同为另一家公司工作了2年，但是那家公司却准备将其数据处理部门，搬迁集中到国内很远的另一头。这些程序员并不愿意搬迁。他们每人都得到了好几家公司提供的要求，而且待遇丰厚，他们最后之所以决定前往这家公司，是因为该公司愿意雇佣他们中的所有人。程序开发组的这种大规模集体搬迁，并不是很少见的事情。尽管高层领导们往往认定这是他们集体玩弄的阴谋诡计，但是他们的目的并不是希望借此获得巨大的物质利益。实际上，他们只不过是为了一个愿望能够得到满足：大家可以继续共同工作——有些工作环境之所以极具吸引力，其强大的魅力正在于此。
       就在这个开发组投向这家飞机机身制造公司的几个月后，在一次计算机会议上，该开发组的新任主管遇到了它的前任主管，并向这位前任主管询问，他手下现在是否还有更多这类优秀的程序员。在得知整个开发组都已经加入了自己的公司之后，新任主管又接着询问，能招募到这些程序员的诀窍是什么。前任主管怎么也想不出当时有什么特别之处——其中的一位女士是主修意大利语的应届毕业生，一位先生在一所高中教了7年的数学，另一位先生是专业的工程师，还有一位女士毕业于一所商学院，并从事执行秘书和会计工作有好多年了。前任主管感到不解：你为什么会问这些问题呢？
       “我只是不清楚这些问题。”的确非常困惑的新主管回答道：“但是自从他们加入我们的部门，我发现只要有任务需要保质保量、按时完成，我就会交给他们中任何一个人。我的手下另外还有300名程序员，但是如果我希望事情能办好，我却只能委托给这个开发组。这些人应该都是些天才。”很显然，这位新任主管的看法带有其浓重的固有观念的色彩，正因为如此，他无法参透一个简单的道理：每次当他给一个成员分派了任务后，他们都会按照自己通常的方式，由整个开发组共同来完成。但是当这个开发组向主管解释这个道理时，他就是不相信——他总是错误地认为：工作肯定是由其中的个别人完成的，但是开发组成员企图掩盖这个事实，因此在汇报的时候把其他人也捎上了。所幸的是，该主管并没有因为搞不清楚该开发组工作如此令人满意的原因，就强行拆散他们。但不幸的是，由于他无法领悟出该开发组的成功之道，所以错过了将这种方法推广到其他开发组的机会。也因为如此，该开发组得以保留下来，虽然对外界仍然如一个封闭的口袋。最后，该开发组再次全体跳槽——当然，这次是一个更能理解他们的新环境。
       当然，那些在程序开发过程中秉承个人主义原则的开发组，同样有其保持自身风格的办法——正如那个飞机机身制造公司的程序开发部门中的其他开发组一样。实际上，在一个如此大型的程序开发组中，任何一个新成员，甚至一个新的开发组，无论对自己的做事方法如何自信，都不可能改变整个开发组原有的社会系统；即使是其中的一个新的子开发组，也没有这种机会。如果他所加入的开发组成立已有时日，那么很可能他最终会放弃自己的方式，渐渐转向大多数人的方式——尽管他需要为此承受来自心理方面的痛苦，这种痛苦之严重，以至于没有人愿意承受。但是在更多时候，程序开发组可能新近才成立，或者是临时由多个独立的部分拼凑起来的。这种时候，其中的成员可能还会努力争取，企图根据自己的观念来塑造整个开发组。当然，其结果往往是他不得不悻悻地卷起铺盖走人。
       还有一个与此对应的例子。其中的主人公名叫Jim A.，他在纽约的一个计算中心工作。有一次，他被调往一个在芝加哥刚成立的项目。他被分配到的那个开发组有两名主管，他们都是成长于有良好的无私式程序开发传统的环境，而且他们决定在这个项目中推广这种方法。这个开发组中除了两名主管和Jim外，还有四名实习生。在开发组成立的当天，两名主管就开始向其他成员推广他们的工作方法。他们提出，从第一天起，无论是哪一位成员完成的哪一项任务，在上机运行程序之前都必须至少经过另一名同事的签名。他们希望通过这种稍微正式一点的办法，来保证开发组成员能够养成一些好习惯，比如在工作中做到未雨绸缪。
       在第一天的会议上，Jim一言未发。但是等到实习生们离开后，他对开发组主管说：“你们的想法很有意思，这可以帮助那些实习生掌握窍门。” “是的，”主管们很有耐心地解释道，“但这些规定并非只限于实习生，而是适用于我们每个人，这样我们才不至于一开始就染上坏习惯。” “你们还是不要那么认真吧，”Jim笑道，“我的经历比你们要多两年。所以，根本不需要任何人来审阅我的工作。难道，我还需要这些实习生来教导？”
       和众多的预言一样，这句话最后居然也兑现了——Jim竭尽全力地不让任何人通过任何方式看到他那“神圣的”程序。没过多久，他在开发组中明显地就只有帮倒忙的份了。看到实习生们不断地向难道更大、更有挑战性的任务进发，而自己只能在角落里孤军奋战，他只能一味地讥笑他们缺乏独立工作的精神与独立思考的能力。他编写的程序，在质量上与组内其他人的工作距离越来越远。最后有一次，主管终于忍无可忍，把他的一个程序转给一名实习生进行整理；但是，Jim宣称该程序已经调试完毕（或者“基本上”调试完毕），就是硬撑着不认输。
       在这个例子中，这个开发组的社会环境非常强大，足以改变实习生们的工作方式；但是，它还没有强大到足以抵消Jim的“两年经验”。另一方面，Jim的个性也不是很强，还不足以根据他自己的观念，将整个开发组引向他自己心中的方向。因此，最终的结局只能是令人难以忍受。也许，如果该开发组的主管更聪明或者更有经验一些，他们就会在一开始就把Jim清除出去，但为了这“两年经验”，他们不得不咽下失败的苦果——在其他领域，非常缺乏经验的人也会由于对经验的渴望而导致这类问题。
作者评注
       工作空间被不断划分成小隔间的情况仍在继续，如果说有什么可以证明在位的主管们没有把心理学的研究放在心上的话，这就是一个有力的例证。我原来以为，Demacro和Lister在他们的《人件》（Peopleware）中向人们阐述过这个问题之后，它们就应该不会再出现了。也就是说，要是我不曾了解到管理心理学将社会地位凌驾于生产效率之上的做法，我确实会这样认为。Brian Pioreck对这种现象是这样评价的：我确信，这个问题较之社会地位更加深刻。我搞不懂为什么《人件》会成为一本畅销书……在我所遇到的主管当中，很少有人通过阅读而对其产业、管理理论或者心理学有所了解，根本没有。在过去曾经相信，关于自己的专业工作，他们所掌握的信息已经足够了；但是坦诚地讲，就其工作的要求而言，主管们仍然缺乏培训，或者是自我培训。就社会地位而言，IT行业的主管们本身就是开发人员，他们在所就职的组织中被剥夺了任何地位，所以与来自其他领域的同级人员相比，这对于他们将更为重要。我弄不明白，为什么有些信息主管总是热衷于在办公室的角落里为自己建造一个个人王国。
       与许多国王一样，主管们也通过分而治之的策略来管理手下的臣民。但是，每个程序员都离不开与其他程序员之间的沟通。我在1971年曾经预言：由于远程系统的改进和推广，程序员之间缺乏沟通的问题将越发严重。当时，我只说对了一半。在一些管理糟糕的组织中，程序员日益感到孤独的情况确实会出现，但是我却过于低估了人类对与同类沟通的渴望。程序员们也许不会愿意在一家他们本不该呆的公司里虚度光阴，但是他们总是能够找到充分的理由面对面地聚到一起。
       “是的，没有任何人验证过，采用无私式程序开发方法，与那些各自程序员各自为战的方法相比，完成工作的质量的差别。”
       在论述无私式程序开发时，我是这样写的。经过25年的岁月，这个方面的情况已经有所改善，这方面的证据现在比比皆是，比如：通过技术复查（审查或其他形式），可以开发出更加可靠的代码，而且其成本会更低，一致性更好。另外，的确，作为开发过程的一个标准的组成部分，现在有更多的软件开发组织有规律地应用各种形式的技术复查。但是并非全部——无论从何种意义上讲。
       所以，我已经学会一些东西：如果你不希望自己的程序接受别人的检查，而又说不出什么合乎逻辑的理由，那么就无法通过逻辑论证的办法来改变你的工作方式。另外，如果你在自己的专业工作中根本不使用逻辑，那么你的专业水平必然会受到极大的限制。
       不幸的是，关于建立与维护程序开发环境的论述材料虽然已有几十年的高龄，但是在今天看来仍没有丝毫的过时。有些主管仍然会与高效的程序开发团队发生冲突，并进而又以各种毫不相关的借口，将这些团队解散。而有些主管虽然还是搞不清楚这些团队的运行方式，但是他们却至少懂得应该容忍这些团队的存在。另外，关于团队集体在软件开发过程中的价值，还有个别人仍然没有认识到。
       或者，也许他们确实认识到了，但是受制于其对个人职位的患得患失，他们的做法总是南辕北辙。现在对软件开发主管们的考评，很大程度上仍然是根据其已有的成果多少，而不是看其是否有能力建立能够创造出更多成果的团队，或是看他们的成果质量。在这样的压力下，主管们就会极尽其能事，编造种种相互矛盾的甜言蜜语去哄骗其属下，以期得到更多成果——当然，这些成果大多是短期的。他们的下属也可能悟出这个游戏的原理，于是也会效仿起这种伎俩，去欺骗他们的下属……这样一直下去，直到他们也成为这样的主管。这种主管根本不屑于去建立团队，也开发不出什么高质量的成果，而只会带出更多像他一样的下属——有朝一日这些人又将成为下一代被这样误导的主管。

《程序开发心理学——程序开发组》相关推荐

ComeFuture英伽学院——2020年全国大学生英语竞赛【C类初赛真题解析】(持续更新)
视频:ComeFuture英伽学院--2019年全国大学生英语竞赛[C类初赛真题解析]大小作文--详细解析课件:[课件]2019年大学生英语竞赛C类初赛.pdf 视频:2020年全国大学生英语竞赛 ...
ComeFuture英伽学院——2019年全国大学生英语竞赛【C类初赛真题解析】大小作文——详细解析
视频:ComeFuture英伽学院--2019年全国大学生英语竞赛[C类初赛真题解析]大小作文--详细解析课件:[课件]2019年大学生英语竞赛C类初赛.pdf 视频:2020年全国大学生英语竞赛 ...
信息学奥赛真题解析（玩具谜题）
玩具谜题(2016年信息学奥赛提高组真题) 题目描述小南有一套可爱的玩具小人, 它们各有不同的职业.有一天, 这些玩具小人把小南的眼镜藏了起来.小南发现玩具小人们围成了一个圈,它们有的面朝圈内,有的 ...
信息学奥赛之初赛第1轮讲解（01-08课）
信息学奥赛之初赛讲解 01 计算机概述系统基本结构信息学奥赛之初赛讲解 01 计算机概述系统基本结构_哔哩哔哩_bilibili 信息学奥赛之初赛讲解 02 软件系统计算机语言进制转换信息 ...
信息学奥赛一本通习题答案（五）
最近在给小学生做C++的入门培训,用的教程是信息学奥赛一本通,刷题网址 http://ybt.ssoier.cn:8088/index.php 现将部分习题的答案放在博客上,希望能给其他有需要的人带来 ...
信息学奥赛一本通习题答案（三）
最近在给小学生做C++的入门培训,用的教程是信息学奥赛一本通,刷题网址 http://ybt.ssoier.cn:8088/index.php 现将部分习题的答案放在博客上,希望能给其他有需要的人带来 ...
信息学奥赛一本通提高篇第六部分数学基础相关的真题
第1章快速幂 1875:[13NOIP提高组]转圈游戏信息学奥赛一本通(C++版)在线评测系统第2 章素数第 3 章约数第 4 章同余问题第 5 章矩阵乘法第 6 章 ...
信息学奥赛一本通题目代码（非题库）
为了完善自己学c++,很多人都去读相关文献,就比如<信息学奥赛一本通>,可又对题目无从下手,从今天开始,我将把书上的题目一一的解析下来,可以做参考,如果有错,可以告诉我,将在下次解析里重 ...
信息学奥赛一本通（C++版）刷题记录
总目录详见:https://blog.csdn.net/mrcrack/article/details/86501716 信息学奥赛一本通(C++版) 刷题记录 http://ybt.ssoier. ...
最近公共祖先三种算法详解 + 模板题建议新手收藏例题：信息学奥赛一本通祖孙询问距离
首先什么是最近公共祖先?? 如图:红色节点的祖先为红色的1, 2, 3. 绿色节点的祖先为绿色的1, 2, 3, 4. 他们的最近公共祖先即他们最先相交的地方,如在上图中黄色的点就是他们的最近公共祖先 ...

《程序开发心理学——程序开发组》

《程序开发心理学——程序开发组》相关推荐

最新文章

热门文章