软件随想录(local.joelonsoftware.com/wiki)-2000年03月19日 两个故事 - Two Stories

2000年03月19日 两个故事 - Two Stories

 

The Joel on Software Translation Project:两个故事

From The Joel on Software Translation Project

Jump to: navigation, search

两个故事

作者：周思博 (Joel Spolsky)
译：Paul May 梅普华
Sunday, March 19, 2000
属于Joel on Software, http://www.joelonsoftware.com

我要说两个故事，都是我过去工作时发生的。我认为这两个故事足以清楚阐明，管理良好的科技公司与一团乱的科技公司间有何差别。最终的差异在于相信员工并让他们把事情做好，还是把他们视为作业员对待，必须不停监视控制以免偏离主题并造成破坏。

我首次工作是在微软，第一份任务是要想出一套新的Excel宏语言策略。很快的我就写出第一份"Excel Basic"规格初稿(后来发展成Visual Basic for Applications，不过那是后话了)。不知怎么的，微软里有个叫「应用架构组」的神秘小组听到这份规格。由于他们认为自己就是负责集语言策略之类的东西，当然得关心这份文件。于是就要求看看我的规格。

我到处问应用架构组是什么来头，不过似乎没有人认为他们是玩真的。原来这个组只有四个人，是最近才请来的博士(这就微软而言很罕见)。我把我的规格印了一份给他们，还去跟他们开会看看能否听到什么有趣的东西。

其中一个说：「哇啦哇啦！」另一个又说：「哇啦哇啦，哇啦哇啦哇啦！」我不认为他们讲得出什么有意思的东西。他们非常迷恋子类别继承(subclassing)，似乎认为在Excel写宏的人会用到大量的子类别继承。无论如何，最后其中一个人说：「不错，这些全都很有意思。再来还要做什么？要找谁批淮你的规格呢？」

我笑了。虽然我在微软只待了几个月，也知道没有什么「某人批淮我的规格」这种事。惨啊，没有人有时间读我的规格，更别提批淮了。程序员每天都在催我多写出几页，让他们能多写点程序。我的主管(还有他的)已经讲得很清楚，没有其他人懂宏或者有时间去做这件事情，所以不管我做出什么东西，最好是正确无误的。而在微软这个怪研究小组工作的博士却假设事情会更正式一点。

我很快就明白，应用架构组对宏的了解比我还少。至少我还和几个宏开发人员和Excel老前辈谈过，知道实际上大家是如何用Excel Basic的，不外就是每天重新计算某张试算表，或者依照某个模式重新安排资料等等。不过应用架构组认为宏只是个学校习题，也不知道实际上大家都是用宏在做什么。其中一位感受到压力，就提了一个想法：既然Excel已经有底线和双底线功能，可能会有人想写一个宏去做三底线。是啊，真低级。于是我开始尽可能的婉转地忽视他们。

这似乎惹恼了应用架构组的头头Greg Whitten。Greg好像是微软员工代码六号的元老。他从盘古开天起就在这里了；没有人能明确指出他做过什么事，不过他常常跟比而盖茨吃午饭，而GW-BASIC是依他的名字命名的。Greg召开了一个「大」会议，开始抱怨Excel团队(指我啦)如何恶搞宏策略。我们逼他提出明确的原因，不过他的论点就是没有说服力。我这个大学刚毕业的菜鸟和六号老员工争论而且显然赢了，感觉真是不错。(你能想像这种事会在那种穿灰法兰绒西装的公司发生吗？)当然很重要的原因是程序团队(由现在已经是微软副总的Ben Waldman带领)的全面支持，因为程序团队负责写程序，所以他们对于做事的方法有最终的决定权。

我很乐意让事情到此为止。不过如果应用架构组需要人关心想再吵架也没关系。他们想要我就会奉陪，只要能让程序员专心做事就好了。不过后来发生的事情更有意思，而且让我很感动。我跟几个同事在Redmond的晴空下吃午饭，Pete Higgins朝我走过来。当时Pete是Office部门的总经理。我当然知道他是谁，不过不认为他会了解我。

「约耳，怎么回事？」他说：「我听说你跟应用程序组有点过节。」

「哦，没有啦。」我回答：「我都可以搞定。」

「不用多说，我了解了。」他说完就走了。第二天就有谣言传回来：应用架构组解散了。还不只这样，小组的成员都分散到微软不同的部门，而且离得很远。我再也没有听到他们的事了。

我当然是非常的感动。在微软这家公司里，如果你是Excel宏策略的项目经理，即使来公司还不到半年也不要紧，你就是Excel宏策略之神，连员工代码六号的老员工也不能挡你的路。事情就是这样。

这件事传递了一个非常强烈的讯息。比如说它让大家对自己的工作更有责任感。也不能再用「管理阶层批淮了规格」这种想法来当借口，因为管理阶层并不会仔细看他们的规格。管理阶层只管雇用聪明人并安排工作给这些人做。另一个意义是表示这里是个绝佳的工作场所。有谁不想成为所属领域的王者呢？软件本质上就很容易分割成小块小块的元件，所以总是可能分割出人员间的责任，让每个人拥有一个领域。这可能正是软件人喜欢在微软做事的原因。

---

过了几年我换去Juno工作。这是一个在线服务和免费电邮的供应商。这次的经验和在微软工作时正好相反。我底下有两个程序员对我负责，可是我的直属主管却一直在破坏我的(很少的)权力，他跳过我直接分派工作给我下属，而且常常没通知我。连休几天假这种小事，他都认为应该由他决定淮假与否。

进Juno几年后，我去处理新的使用者登入功能。我要负责翻修整个Juno 3.x(一个重要的改版)的登入流程。当时我已经是技术团队里相当资深的成员了；我的考绩很好而且主管们似乎也欣赏我的工作成果。不过他们就是没办法信任我。大概是命令与控制那套老想法的缘故吧。

登入过程中有个地方要求使用者输入生日。Juno的登入程序很长，大约有30个画面，要使用者填收入、喜好运动、有几个小孩、年纪多大还有其他一百个左右的问题。生日只是其中很小的一部份。为了想让登入程序再简单一点点，我想把生日栏改成不限格式，这样就可以输入"8/12/74"或"August 12, 1974"或"12 Aug 74"或其他內容。(你曾经用过Outlook吗？这就像Outlook一样，随便打什么日期它都可以接受)。

我的主管并没有深入了解就决定他不喜欢这个作法。对他来说这变成自尊心问题。他先吼了处理这个画面的设计师(根本没先告诉我)又再骂我。然后每天都提醒我一定要把它改成他要的样子。接下来他找公司执行长来评估，还开批斗大会让执行长批斗我的新设计。事实上连Juno的执行长都非常乐意干预公司最底层完成的工作。真是一脉相传的标准作业程序啊。

我当然是很生气。这其实只是件小事，不过是喜好而已。某些人会喜欢我的作法，而某些人喜欢他的。不管怎样讯息已经很明确的：你他X的照做就是了。这是非常命令与征服式的心态，像是在比谁比较勇而不是在讨论使用介面设计。

我并不是说这是我离开Juno的原因，不过它的确解释了我离开Juno的理由：不管你多么努力工作又有多聪明，也不管你是否在「负责」，你对再微小不过的事都没有权力。把你该死的点子训练以及聪明睿智放一边，把那些让我们付钱请你的一切东西通通都丟到一边吧。而且Juno的经理很多，大概占总员工四分之一，所以他们有的是时间可以到处乱伸手指，确定他们能掌控。在微软却是副总自己从九号大楼出来找你，确定你有权力能把事做完。这对比还真是强烈啊。

就某种程度而言，无能至极的管理流程是Juno之所以是一个纽约市公司而非西岸公司的因素之一，所以还不太能深入现代的管理风格。这也是Juno经理人经验极度不足所导致的问题，而源头则是在最上层，一位只待过D. E. Shaw的29岁执行长。他会干预每件能插手的大小事，连出状况时错误讯息的字句也要管；这位执行长会定期大声责骂敢质疑其睿智的部属，然后部属再把气出在程序员身上，程序员只好回家踢狗发泄。相较之下，在微软事情都是由最底层完成，大多数经理的工作好像只是到处闲逛，把家俱搬开不要挡到路，好让大家可以专心工作。

这些网页的內容为表达个人意见。
All contents Copyright © 1999-2006 by Joel Spolsky. All Rights Reserved.