1
回答
O’Reilly创始人Tim O’Reilly谈领导力
利用AWS快速构建适用于生产的无服务器应用程序,免费试用12个月>>>   

领导力(Tim O’Reilly访谈录)
----------------------------------------------------------------------------------------------------------
Tim O’Reilly创办了O’Reilly Media, Inc.公司,《团队之美》以及我们另外几本书就是由这家公司出版的。我们两位编者对Tim和他所创办的公司一直都很钦佩,不仅仅是因为他对出版业产生的影响,而且因为他的影响力还扩展到了软件和软件开发领域。多年来我们和O’Reilly公司几乎每个部门的人都合作过,看到的是一个非常优秀的团队。我们想请Tim介绍一下他的思想,谈谈他是如何组建这个团队并能够让团队持续表现出最优秀的能力的。
----------------------------------------------------------------------------------------------------------
Jenny:在开始编辑《团队之美》时,我们注意到每个人对“团队”的定义似乎都有一些差别,后来发现书中讲述的一些内容明确地谈到了这个问题:团队总是由一些为了构建特定的项目而临时组织在一起的人组成?还是说一群素未谋面的人也能算是一个团队?

Andrew:我们用了一点小计策,提了一个让人易于发挥的开放式问题。我们想知道您是如何定义团队的?

Tim:我自己的经验主要是关于公司运营的,当然其中也包含了有关团队的经验。但我思考的大多是一个更具广度的问题,那就是如何发挥领导力。我先从重要的开始说起,谈几点有关领导力和管理的想法,这些都是整个团队事务的一部分。说到领导力与管理,我不是很清楚这方面的内容与团队的分界线在哪里。

首先我要引述两句别人说过的话。第一句出自Harold Geneen,即第一家现代化联合大企业ITT的创始人。他说:“管理的技巧就是通过其他人的工作实现你的目标。”这是一个有趣的看法。但问题是实现风格可以有很多种,其中一些完全是命令式的。比如典型的“经理”是这样的:分析一下需要完成什么,需要由什么样的人来完成,然后找到这些人组成团队。他们做的就是诸如此类的事情。

我完全认同这种观念,因为管理的技巧确实就是通过其他人的工作实现你的目标。同时,我还总是使用另外一句引语所表达的意思。那句话实际上是关于写作的,是Edwin Schlossberg说的,是我刚参加工作时从他发表在杂志上的一篇文章中看到的,那句话深植于我的脑海之中,算得上是对我影响最大的一句话了。他说:“写作的技巧就是创造一个能够激发其他人进行思考的环境。”

Jenny:那您是如何把“创造一个能够激发其他人进行思考的环境”的思想应用到软件团队中的?

Tim:我来谈谈我的看法,这和我所说的“参与的架构”(architecture of participation)有关。我们在1998年出版了一本叫做《Open Sources》的书,采访了一些在开源方面写过文章的人。Linus Torvalds在采访中说过一句话,这句话最后没有放到书中,但是让我印象非常深刻。他说:“对于Windows,我没有办法取得像Linux那样的成就,就算给我Windows的源代码也没用。它的架构不是那样的。”这句话让我对开源项目的架构开始了一系列的思考。例如,那些架构是如何设计的?为什么能够让人们自由、即兴地进行创作?成功的背后必定有一些规则在起作用。

Andrew:还有Linus做不到的事情?真有意思——这让我想起了SourceForge.net,上面有很多不知所终的开源项目。

Tim:我想某些项目之所以失败,是因为与这些项目搭配使用的系统有问题。系统必须具备这样一个基本特征:每个任务都很小,人们能够独立完成。比如有人说他们想按照维基(Wiki)的方式出书,我想可能就是这个原因,但是这种想法并没有实现。为什么呢?因为书的内容很多、很复杂,并且只有一条叙述的主线。而维基百科词典是一组页面,每个单元的内容都很少,个人凭一己之力就能完成,其他人可以更新或稍作调整。

整部词典都是由许许多多这样的小部分组成的。我想,某些类型的工作本身就适合于这种协作活动—它们在开始时的设计方式就是让各部分易于整合,所以更为自由。

UNIX的设计方式就有点像乐高积木,它的设计原则是有一些可以彼此连接在一起的“凸起”和“凹槽”。想一想管道、过滤器等类似的东西——人们完全可以利用自己的知识编写独立的实用工具。大多数程序接受标准化输入和输出,所依据的只是几条简单规则。

类似地,每一个独立的小部分都有一个指南页。我常常想,如果可以在遵守某种开源许可协议(比如GPL)的Windows系统和每一段代码都有一个指南页的Windows系统之间做出选择,我能够在这套系统上替换或更改一些什么内容?是的,开源许可的确重要,但是只有许可证是不够的。相反,有指南页就足够了,虽然你可能会侵犯某些人的版权。

Andrew:您的意思是,为了成功运作项目—开源项目或其他项目,关键是将项目分解**们易于理解的小块?

Tim:我说的是需要有一个可以激发人们创造力的体系,还要有一整套原则。我来讲一个具体的事例。在1998年的时候,我组织了一次后来被称为开源峰会的会议。这个故事讲述的是发生在开源界的真实事情。其他人也在谈论开源界的事情,特别是Eric Raymond,他在此前编写了《The Cathedral and the Bazaar》。一年前我刚组织了Perl会议。我们都是在同时考虑几件事。Netscape刚刚将浏览器开源,轰动一时。我注意到一个问题,在Eric Raymond和其他人讲述的标志性事件中,完全忽略了BSD领域。他们讲的全都是Linux,全都是GPL的软件,全都是自由软件的理想。

同时,我看到了另外一种已经存在很长时间的开源方式。我在看到那种开源时说:“真没想到,这种开源的影响力要大得多。”我见人就问:“你知道Internet上的最好的5种程序都有哪些吗?”他们开始挠头思考。我告诉他们:“第1名是BIND(Berkeley Internet Name Daemon)。你们每个人的网站都依赖于这个程序,它是由红杉市一位留着长头发的程序员维护的。第2名是sendmail或Apache。75%的网上电子邮件都是由sendmail发送的。”你可以接着往下数,都是Berkeley的软件。人们却看不到这一切。

Jenny:我记得在那时候,对于选择开源协议有很多争论,即选择GPL还是BSD。听说是您设法解决了争论并引导大家达成了共识。当时是什么情况呢?

Tim:我把GPL的人和Berkeley的人都召集在一起,然后说:“我们必须找出共同之处。我们必须要讲点东西。5点钟有一个记者发布会,我不知道该跟他们说些什么,但在5点钟的时候一定得跟他们说点什么。”我隐约感到将要发生一些非常有意思的事情,但我不知道那天在20个人对问题纠缠不清的情况下应该怎么办。Eric进来说道:“我们几个星期前开过类似的会议,Christine Peterson提出了一个名字,叫‘开源’(Open Source)。”

Cygnus公司的Michael Tiemann说:“我们也一直在考虑‘自由软件’(free software)这个名字的问题。”Linus Torvalds说:“我没有意识到‘free’这个单词在英语中有两种含义(译注1: free在英语中有自由的意思,也有免费的意思。free software既可以理解为自由软件,也可以理解为免费软件,有歧义)。”Michael Tiemann接着说:“其实我们一直在用‘sourceware’这个词。”

于是我们投票表决。我们说:“我们大家都同意使用一个名字,以后都要开始使用这个名字。”我们在sourceware和Open Source之间进行投票,Open Source最终胜出。记者发布会在5点钟召开,后来的事情就尽人皆知了。

Andrew:真有意思。我和Jenny曾撰文说明人为的截止期限可能对团队产生各种负面效应。没想到这种方法却帮了你们大忙。

Tim:我们经常将一些短期合作的人召集到一起。我感觉会做出一些事情来,但不是很清楚它会是什么形式的,或者应该是什么形式的。但是我知道要把它变成现实。于是团队的原则之一就是创建一个人为的截止期限——比如说:大家注意,我们在5点钟要开记者发布会,这可能会成为一个有力的工具。但是,现在很多公司和很多人却在滥用这种做法。我看到有些项目经理在截止期限的问题上对他们的团队撒谎,想要人为制造一种紧迫感。这违背了诚信原则。

但是如果能够正确使用,获得那种紧迫感还是很好的。这有点像亚历山大·蒲柏在谈论诗歌创作时所说的:狭缝令创造力如喷泉般涌出。

说到团队,我还想说一下的是团队成员优势互补带来的威力。在O’Reilly公司,现在有一位能力很强的首席运营官,她发挥着巨大作用。我们俩像是硬币的两面。我专注大事,花在内部事务上的时间很少,这样可以做更多的事情。而她则专注于日常业务运营,比我两手都要抓的时候要好得多。能够认识到优势互补的力量是非常重要的。

Andrew:我提一个问题。我和Jenny前不久为ONLamp写了一篇题为“企业项目应当向开源项目学习什么”的文章。随后,我们又做了一次题为“开源项目为什么能够成功”的讲座。我们重点关注的是他们使用的实践方法,因为我们过去一直在做这方面的工作。

您讲了很多关于团队、个性、互补的力量、如何与人们一起工作的事情。但是我们发现一个问题,如果看一看最成功的、我们都了解并热爱的开源项目,像Apache、Linux和Emacs,会发现那里有很多优秀的实践方法。开源项目的开发人员、程序员和其他人都自愿贯彻执行,但是如果回到办公室环境中,同样是那些方法却让他们感到窒息,比如很严格的构建和发布过程、持续集成、测试驱动开发等。

Jenny:还有大量的代码评审。我们把同样的实践方法应用到公司环境中就会很费力,同样是那些人,他们甚至会抵制这些做法。您觉得为什么会存在这种情况呢?

Tim:嗯,让我这么说吧。骑过马的人都知道,要想骑好马,秘诀在于让马认为它做的是自己想做的事情。同样,当人们感到是别人命令他们应该怎么做时,就会产生抗拒了。如果他们认为那是他们自己想做的,他们立刻就会接受了。

两千五百年前,中国思想家老子就说过:“悠兮,其贵言,功成事遂,百姓皆谓:我自然。”最好的领导就是能够让人们自觉自愿地去做事。

当人们抱着审美的观点去创作一些奇妙无比的东西时,这种现象就更明显了。我们既然有了iPod,怎么还会想到有不带触摸屏的设备呢?我记得第一次拿起Kindle的时候,我在屏幕上按了几下但没有反应,还以为出了什么问题。实际上Kindle有它自己的特点,比如支持EVDO连通。“是的,它就应该是这个样子的。”

Andrew:真没想到您在谈论一个产品应当做成什么样子。我参加的大多数关于开源的讨论都是争辩一些像GPL、BSD许可协议和Creative Commons许可协议孰优孰劣的问题,我想人们有点纠缠于细节了。但您认为开源软件是实现愿景的一种非常独特的方式,我从来没有这么想过。

Tim:必须承认,人们总以为开源的关键在于其许可方式。它当然重要,但就像你们刚才说的那样,实践方法远比许可方式重要。在回顾O’Reilly在行业中取得的成就时,我首先想到的就是所有的书籍都是由用户编写的。大多数产品的创作者都不是我们公司的职员。我们必须提出一个和产品相关的、可信的想法,然后又得去找一个会说“嗯,这主意不错,我也想那么干”的人。我们给他们指导,从公司内外找来很多其他人评审他们的工作。我们必须要有一套管理制度,尽管这套制度常常很松散。这些事情可以通过很多种方式完成,我之所以非常喜欢Larry Wall的Perl口号“完成的方式不止一种”,这也是原因之一。因为我认为答案不止一个。

Andrew:特别是在Perl中。

Tim:是的。看看《Programming Perl》那本书。我可以花上6个月时间把这本书按照我的想法进行改造。或者,我也可以说:“写成这样已经很好了。”虽然这本书如果让我来写,我是不会按照这种方式写的。我会祝它好运,然后送去出版。

我还记得我们出版这本书的情形。真是很遗憾,编辑的精力全都用来把它改造成另外一本书,她花了两年时间和几位作者一起工作,或教导或强迫或哄骗,让他们不要以他们开始时设想的方式写书。她不知道如何让作者放手去写。于是我说:“那也是一本书,只不过和你想象的不一样。”她回答说那几个人写的完全是一些内容上没有联系的片段。

我说:“你只要给他们介绍一些写书的基本情况就够了。”

Jenny:我们团队很多人都说《Programming Perl》是他们读过的最好的编程书之一。你得到的书和你所期望的不一样,但却更好。

Tim:那是特例。你怎么能够发现事物的本质呢?我想这可以算得上是悟性之源、万物根基了。悟性有多种。其中一种基本上是有关算法和操作的:给你的是所有这些数据,你很善于操作它们。有些人在某些方面确实很聪明,但是在其他方面却很笨拙。比如说他们对很明显的道理视而不见,没有一点常识。还有另外一些人,他们不善于符号操作、不会拼写也不会做算术,但在审时度势、理解事物本质方面却是天才。最聪明的人同时具备这两种特质。他们能够以全新的视角看待世界,他们的领悟能力很强:“我知道它可以成为什么样的。”

现在再回到刚才说的那本Perl书上,编辑接受过所有的培训,知道一本书应当是什么样的,应当怎么写。这种培训对她形成了障碍,她无法再以新的视角看待那本书。她无法理解的是,如果帮助作者按照他们所希望的方式写书,进展会更顺利。

Jenny:您认为一名编辑或者任何一个团队负责人都不应当逼迫作者或团队向着一个特定目标前进?

Tim:经验告诉我,多数情况下,领路人不一定要做团队成员。领导的大部分工作是对人员的指导,我指导的方式就是尽量少做。要实现这个想法,就需要看到团队成员的长处,遇到事情可以说:“这是我们能够处理的。”

<无标签>
举报
hzbook2010
发帖于8年前 1回/264阅
顶部