《极客与团队》一隐瞒是有害的

隐瞒是有害的

极客与团队
假如你一直都是单打独斗的话,你其实是增加了自己失败的风险,而且浪费了自己成长的可能性。

首先,你怎么知道自己选的路是对的?

假设你是一名狂热的自行车设计师,有一天你想到了一个绝妙的主意,设计出一个具有颠覆性的换挡装置。你订购了零件,然后在车库里泡了好几个星期来制作原型。当你的邻居(他也是自行车爱好者)问你最近在忙什么的时候,你想还是先保密好了。在这个设计完善之前,你不想任何人知道它的存在。几个月以后,你遇到了瓶颈,没有办法令原型正常工作,但由于这个项目是保密的,所以也没办法向你的机械师朋友们寻求帮助。

直到有一天,你的邻居从他的车库里推出一辆自行车,上面有一个全新设计的换挡装置。其实他也一直在建造一个和你的设计类似的东西,只不过他有自行车行的朋友帮他的忙。这时你一定非常窝火吧。你把自己的东西拿给他看,他立刻就指出了你在设计上存在的缺陷——要是你早点拿出来的话,搞不好这些缺陷在一开始就修复了。

这里我们可以得到好几个教训。真正做出产品之前不愿分享好创意实际上是一场很大的赌博,你很容易在一开始就犯下很基本的错误,你有可能是在重新发明轮子1。还有你完全丧失了合作的好处。注意到你的邻居和别人合作后进展有多快了吗?这正是为什么人们在跳进泳池前会拿脚趾试试水的原因:你需要确定自己在做的事情是对的,方法也是对的,而且不是重复劳动。一开始就踏错步的概率总是很高的,越早征求意见和反馈,就越能把风险降低2。记住这句久经考验的原则——“确保失败尽早发生,尽快发生,经常发生”——我们会在本书稍后详细讨论失败的重要性。

尽早分享不仅仅可以防止一开始就步入歧途和检验创意,它还可以强化所谓的“公车因子”。

公车因子(名词):一个项目里,需要有多少人被公车撞到才能令其完全瘫痪。

你的项目里知识的分散程度是多少?假如只有你一个人理解原型代码是怎么工作的,那么或许对你的职位的安全程度来说是很高,但要是你被车撞了的话,对项目本身来说就是灭顶之灾了。但如果有一个朋友和你合作的话,公车因子就可以翻倍。要是有一个小组一起设计制作原型的话就更好了——项目不会因为某位成员的消失而完蛋。记住:这里只是比喻,并非真的是被车撞,而是指任何生活中都会发生的意外情况,比如结婚、搬家、离职或是照顾生病的家人等。你若想要确保项目有一个光明的前景,就一定要把公车因子纳入考量。

除了公车因子之外,还有整体进展的速度。人们往往会忘记单独工作通常都是很艰辛的,进展有时会慢得令人难以接受。独自工作能让你学到多少东西?你的进展如何?网络虽然是观点和信息的大熔炉,但是它是替代不了人与人之间真正的交流的。直接和别人一起工作能潜移默化地提升集体智慧。每次遇到事后觉得可笑的障碍时,你浪费了多少时间才走出死胡同?想想如果有同事在旁边帮你一把的话会有什么不同——他们会立刻指出你哪里弄错了,该怎么解决它。这就是软件公司里团队通常都是坐在一起(或是在一起结对编程)的原因:你需要一位旁观者。

再打一个比方。想想你是怎么用编译器的。当你编译一个有一定规模的软件的时候,你会花好几天甚至好几个星期坐在那里写代码,然后在全部写完确保一切完美后才第一次进行编译么?肯定不会啦。你能想象一口气编译50 000行代码会有什么后果么?程序员是最需要不断反馈的:写一个新函数,编译,加了一个测试用例,再编译一下,又重构了一部分代码,再编译一下。这样就能在生成代码的时候尽快地改正笔误和 bug。我们的每一步都离不开编译器,好像僚机一样。有些开发环境甚至能在我们打字的同时进行编译。正是依靠这种方式我们才能保持高质量的代码并确保软件在正确的轨道上演化。

这种快速反馈不仅在代码层面,对整个项目来说也是必不可少的。有抱负的项目都必须快速演化并不断适应环境的变化。项目可能会遇到意料之外的设计瓶颈,或者行政上的阻力,又或者只是发现事与愿违。需求总是在往意想不到的方向变化。你要如何通过反馈来发现自己的计划和设计中需要修改的地方?答案是:团队合作。埃里克·雷蒙说过,“只要有足够多双眼睛,就能发现所有的bug,”而更好的说法是,“足够多双眼睛可以确保你的项目保持正确的方向。”闭门造车的结果往往是当实现最初的创意后,却发现世界已经完全改变,原本的产品已经失去意义了。

工程师和办公室

20年前的传统看法是工程师需要自己独立的办公室,关上门安静工作才会有生产力。这样才能保证他有大把不受干扰的时间可以专心编程。

而我们却认为把绝大多数工程师3关在独立办公室里不但毫无必要而且还很危险。今时今日,软件业已经不是个人英雄的行业了,它需要团队的合作,保持沟通渠道的通畅甚至比随时在线的网络连接更重要。虽然得到了不受干扰的环境,但如果方向错了,那也只是在浪费时间罢了。走进任何一家21世纪以来创建的、快速成长的高科技公司,你会发现工程师都是围坐在共享的小格间(也叫“牛棚”)里,或是共用一张桌子,很少见到各自把自己锁在办公室里的情况。

当然啦,你还是需要找到办法来过滤杂音和干扰的,我们发现很多团队因此发展出一套自己的沟通技巧来表达自己现在很忙,有事等会再说。以前和我们合作过的一支团队就有这样一套语音中断协议:假如你有事找玛丽谈,你要说,“breakpoint 玛丽”。如果玛丽正好有空档可以停下来,她就会转过来和你谈。要是她正在忙,她会说“ack”表示知道了,然后你就先去忙其他事情吧,她那边忙完了就会来找你。

有些团队会给工程师发降噪耳机来解决背景噪音的问题——事实上在很多公司里,带着耳机实际上就表示“不是重要的事情就别烦我”。另外一些团队则会用在显示器上放置记号和玩具的办法来表示自己不愿被打扰。

请别误解我们——我们完全认同工程师应该有不受干扰的时间来全情投入编码之中,但是我们认为他们更需要团队之间高效通畅的沟通渠道。

因此用一句话来总结就是:本质上,单打独斗比合作风险更高。相比担心自己的创意被偷走或是被人笑话,你更应该担心自己是不是在错误的方向上浪费了大量时间。

令人遗憾的是,这种“创意要保密”的想法并非软件行业独有的,所有领域都普遍存在这个问题。就拿学术界来说,科学原本应该是自由开放、信息共享的。但是“不发表即灭亡”的迫切需求,以及对基金拨款的竞争却造成了反效果。学者们不再乐于分享。他们小心翼翼地保护着自己的想法,秘密地进行研究,把犯过的错误都掩盖起来,使最终发表的论文看起来似乎得来全不费功夫一般。其结果往往都是灾难性的:要么不小心重复了前人的工作,要么在一开始就不知不觉犯下了错误,最糟糕的是创造了一些原本有趣,但现在完全过时无用的东西。其中浪费的时间和精力都是无法估量的。

别再把自己变成上述统计结果的一部分。

时间: 2024-10-25 20:54:10

《极客与团队》一隐瞒是有害的的相关文章

《极客与团队》一导读

前 言 极客与团队 "工程问题都很简单.人际关系才是最难的." --比尔·库格伦,前Google工程部资深副总裁 生活中总是充满了离奇的转折,就好像我们俩从没想过会合作写一本软件工程的书一样. 和大多数电脑狂一样,大学毕业后我们发现自己的兴趣和热情(折腾电脑)居然也是不错的谋生手段.而和那个时代的大多数黑客一样,我们的整个20世纪90年代中期都是在干这些事情,用别人剩下的零件攒机,拿着一大叠软盘安装预览版的Linux,然后学着操纵UNIX机器.我们都是系统管理员出身,然后在互联网泡沫刚

《极客与团队》一为什么要关心它

为什么要关心它 极客与团队 简单来说,关心团队文化的原因就在于如果不努力营造它,那么团队最终会因为某个特别强势的人的出现而被注入他个人的文化基因.这种文化或许是生产力强劲的健康文化,能产出大量的优秀代码.但事实往往相反,你会突然发现自己在争执和争斗中浪费了太多精力,没有办法集中精神去设计和编写代码.不仅如此,团队拥有一个共同的价值观并愿意为之奋斗是非常重要的事情.要是团队不在意自身的团队文化,那么不仅构建强烈的团队认同感以及对自身工作的骄傲感会变得十分困难,而且会很容易受新人影响而引入糟粕. 大

《极客与团队》一团队才是王道

团队才是王道 极客与团队 现在我们来小结一下. 我们到目前为止一直在打磨的观点就是,在编程领域里,真正的独行侠是很罕见的--就算他们真的存在,他们的非凡成就也不是凭空而来的.这些改变世界的成就几乎都是集体智慧努力得来的结晶. 因此建立一支全明星团队才是真正的目标,不过想达成这个目标,难度高得惊人.最好的团队能充分利用好队里的巨星是没错,但是集体的力量一定是大于个体力量之和的. 用一句话来说就是:软件开发是集体项目. 乍看之下这个理念很难让人接受,毕竟这和我们心里的天才程序员幻想是相抵触的,所以先

《极客与团队》一文化和人

文化和人 极客与团队 编写软件和在流水线上简单地组装产品可不一样.有些工作只需要几天培训和一些基本的工具就可以完成,如果有工人退出或离职(或者就是学不会),你只需要替换为另一个工人就可以了.在流水线环境里,员工通常只要机械性地完成简单的任务即可,而不需要什么创造性思维或是解决问题的本领.但在软件行业里,产品工程师则需要大量的创造性思维1,这就是说如果你想要出色的产品,那么就离不开出色的工程师.而且如果你希望这些出色的工程师能做出漂亮的产品(并且留住这些优秀人才的话),你就需要为他们建立起一种团队

《极客与团队》一什么是文化

什么是文化 极客与团队 当我们听到"文化"这个词的时候,脑子里浮现的情景往往是某个晚上去歌剧院看演出,或是高中生物课上在培养皿里繁殖细菌的画面.工程师团队的文化其实和后者的差别并不大. 假如你吃过非常美味的发酵面包并且对烘培它的人感到好奇的话,你会发现这面包的关键就在于酵母.酵母是面粉和水里的酵母菌和乳酸菌.酵母菌能让面包膨大,而乳酸菌是让面包具有强烈酸味的秘密.然而并非所有乳酸菌都是一样的,有些乳酸菌产生出来的风味更好吃,所以当面包师找到味道一流的酵母(即含有恰当酵母菌混合比例的面团

《极客与团队》一帮我把代码藏起来

帮我把代码藏起来 极客与团队 过去6年来我们俩一直在各种编程大会上做演讲.由于我们是2006年发布Google开源项目托管服务的小组成员,所以我们收到了很多关于这个产品的问题和请求.到了2008年中的时候,我们注意到这些请求里出现了很明显的趋势. 能让Google Code上的Subversion隐藏某个分支么? 能不能实现这样的功能:先把新建项目隐藏起来,等到准备妥当的时候再公开发布? 我想推倒重来,能不能删掉整个历史记录呢? 你能看出这些请求之间的共同之处么? 这里的要害就是缺乏安全感.人们

《极客与团队》一每日进行的讨论

每日进行的讨论 极客与团队 假设大方向已经确定,接下来需要确定的就是每天团队用来协调的工具.这些工具很有用,但是可能会限制沟通的效果,因为它们常常缺乏面部表情以及身体语言这种辅助的沟通渠道.结果它们可能会导致沟通产生误解,从本质上对HRT造成威胁.不管怎么说,这些工具对绝大多数团队来说仍然是不可替代的,(只需要一点点努力)就可以大大提高生产力. 邮件列表 我们还没见过写软件不用邮件列表的人,不过这些技巧可以让你更好地利用邮件列表. 很多非常成功的项目都有好几个邮件列表,把开发讨论.代码审查.用户

《极客与团队》一说到底真正重要的还是代码本身

说到底真正重要的还是代码本身 极客与团队虽然这些文化和沟通的习惯看起来可能只是代表了笔者自己所偏好的工作方式,但其实它们没有你想象得那么主观.我们发现,只要在组建团队时为它培养强大高效的团队文化,并且在团队沟通上花点时间精力,这样的团队就会有更多的时间编写和发布产品,而不用老是去争论要写什么代码的问题. 强大的团队不是自发形成的,它们都是由团队的领袖和创始人培育起来的,他们对领导废柴团队编写软件所需的代价都有切身体会.所以从一开始就着手培养对创建自我选择的文化是大有裨益的,这样团队才有更多的时间

《极客与团队》一三支柱

三支柱 极客与团队到这里我们对于团队的观点已经立论了.既然团队合作才是开发成功软件的捷径,那么如何才能打造出(或者找到)这样优秀的队伍呢? 答案是很难.要达到合作无间的境界,你首先要学习理解所谓的社交技巧"三支柱".这三项原则不但是人际关系中的润滑剂,更是所有良性互动与合作的基本. 谦虚没有人是宇宙中心.谁也不是万能的,谁都会犯错.你必须不断地提高自己. 尊重你必须真心实意地关心同事.他们都是活生生的人,他们的能力和成绩都需要得到肯定. 信任要相信别人的能力和判断力,在适当的时候懂得放