越简单越好!

GitHub如何运作管理的

发表于 2013-07-09 16:35 | 1707次阅读 0次点赞   杂七杂八

一、时间并不决定一切

弗雷德里克·温斯洛·泰罗在1911年写了一篇有关管理和效率的惊世之作:《科学管理原理》。他是用科学方法阐述工业生产中最优效率的第一人。时间就是金钱。效率越高越好,时间越多越好。

“时间决定一切”不适用于我们

在很多行业中,时间是评判效率的准则,但不是我们的标准。在创业公司工作是完全不同的。你不可能花太多时间来解决一个问题。编程是一件需要创造力的事情,你需要在最佳状态才能编出高质量的代码。

想想上次你消沉或愤怒时候,你的效率如何?再想想上一次你真正高效的时候吧,代码好像从你的指尖飞出来的,你编码不仅速度快,代码的质量也高。在状态好的时候编码远远超过机械式的敲键盘。

我们希望雇员们更多的处于最佳状态,但规定上班时间会影响他们进入这种状态。如果强迫我早上九点钟上班,我将不会达到最佳状态。但GitHub一半的同事在早上工作都是最高效的。

如果创造一个更随意的工作时间,程序员会更积极工作,最终会促进程序员工作更久,更加高效。他们甚至会周末工作,晚上工作,因为他们感觉在做的事并不是别人要他们做的工作。

在GitHub的一天

每个在GitHub工作的人的时间安排都是不一样的。我没有平均计算过每一天的时间,但大致是这样的:

1. 早上10点起床,查看Campfire日志,处理过夜支持请求

2. 坐巴士上班,在十二点或一点钟左右吃饭

3. 从下午一点开始工作,直到下午六点或晚九点下班

4. 回家工作或休息到凌晨两点钟。

我们有同事早上七点来到办公室(简直是疯子),也有人下午三点来。有一些同事在家里工作更有效率,如果你不喜欢来办公室,你不需要每天都来(尽管大部分同事每天都来)。

为什么我们的每一天都如此“松散”?这是因为:

1. 我们可以随时随地用聊天室来交流,

2. 我们想创造一个让所有人都高效的环境。

没有一个工作时间是适合每个人的,所以我们没有强制工作时间。

强制工作时间

我们现在有35个雇员,队伍在不断壮大。上班时间灵活随意,对我们的团队来说运作的非常好。但是经理们喜欢规定时间是有原因的:这样做可以给他们一个错觉,工作时间的长短可以转化为评判表现的标准。

经理们如果不看雇员们的工作时间,就得看他们其他方面的表现。他们代码的质量如何?他们修复了错误吗?他们在专心工作吗?更大的灵活性是否让他们更消极?

确实很难将以上这些评判标准进行量化。但是程序员的价值远比一天工作十小时要高。如果你认为时间决定一切的话,那么程序员在乎的将只是时间,而不是代码的质量。

二、异步工作

这是到目前为止我在GitHub工作最喜欢的方面:每件事都是异步的。

聊天

GiHtub在最初的两年没有办公室。我们用聊天室(Campfire)来沟通。现在我们已经搬到了第二个办公室,但仍然使用Campfire。这是因为聊天可以是不同步的。

用这种异步的交流方式,我可以出去吃饭,然后当我回来的时候我仍能跟得上对话;我可以问同事一个问题,不用担心会打扰到她,因为当她有时间的时候她自然会回复;我可以去Minnesota的乡村,也可以同平常一样好像在办公室工作。

Pull Requests

(编注:“Pull Requests”是GitHub上的一种讨论形式,有关代码讨论、代码审查、管理代码的变化。Pull Requests = 代码 + 问题 + 代码注释。)

我们的开发工作流程中涉及Pull Requests,我想在以后的博客中更加详细的讲述这一流程。现在我只想表达我对这种方式的喜爱之情。以前那些需要进行复杂的分支操作的日子一去不复返了,取而代之的是只需要自己对着屏幕查阅代码的简洁方式。

如果我想增加一个新功能,或者会修改代码,我会将代码push到一个新分支,并且新建一个Pull Requests。如果我的代码会影响我同事的代码,或者他们对我的代码感兴趣,或者他们时间充裕的话,他们可以查看我的代码。这时我们可以将那个分支发布到其他机器上,调试新功能,如果一切正常的话,就可以将这个分支合并到主分支去。

有了Pull Requests的工作方式,我就不需要特别去开个会,方便了每个人。还有个原因:

开会是有害的

37signals在《Getting Real》一书中讨论过“开会是有害的”这个主题。相对于37signals,我对于开会的厌恶是有过之而无不及,我讨厌开会。

往往你正在忙的时候,就要开会了。他们还经常会请一些不相关的人开会。即使你对会议的主题很感兴趣,你也会最终被搞得懊恼。因为开会,你不得不停止手头的工作,而开会却是跟你“谈论”你正在的工作。开会期望你提前在白纸上设计出完美的系统,而显然push一个分支,查看diff,基于diff来修改代码更简单些。

除此之外,开会的内容很容易被遗忘。即使你做了会议记录,你也不能保证你能记录所有内容。有某些你没有来得及记下来,你想会后再补上记录。但是三个星期过去了,你回忆起好像某些东西没有记录下来,显然那次讨论才是更重要的。如果采用聊天记录的方式,就不存在这个问题。另外文字沟通的方式也减少了开会时开小差的情况。

我们在GitHub也会开会,但是过去的一年半中开会的次数屈指可数。

最佳状态

你想要你的雇员处于“最佳状态”。但是如果他们只能在那种状态下工作一个小时就要开会了,这将打乱他们。

我们发现,如果让那些负责任的人按照他们自己的时间来安排工作,他们不仅能完成重要的工作,也能保证其他工作的高效率。

三、创新很重要

我们想创造一个创新的环境。员工做项目的时候会爱上这样的环境,它让人振奋,振奋是容易感染人的,可以从一个项目传递到另一个项目。甚至如果我们没有在一个项目上赚到钱,而振奋感仍旧会带入到能够让我们赚钱的项目中去。

酒精

在GitHub有相当多的人喜欢喝酒,这已经不是什么秘密了。我的意思是,我们在每个办公室的储物柜里都有四种啤酒随时可以取用。但酒精并不只是能使人上瘾,它还有更多其他的用途。

聚会。在我们的赞助酒会上,我们要和来自旧金山和世界各地的友人会面。啤酒能让人们为我们的产品感到激动,员工会感到为GitHub工作是一个很激动人心的事情。(和某人喝上几杯,在一个气氛轻松的环境下雇佣员工,比靠大规模紧张的面试的方式更可靠些。)

建立友谊。我们在一起工作,我们不仅是工作伙伴,还是朋友。我们在工作中建立友情。很难区分开我们是在讨论工作还是在聊天。这不单是自我感觉良好。当你和某人关系很好时,你会对他更诚恳。如果别人有了个点子,那么你直接告诉他们你的想法,帮助他们改进。这正是社交的一方面,所以说酒精被称作社交润滑剂。

头脑风暴。酒吧是个适合做假设分析的场所。不要太具体化–可以谈谈工业发展方向,能否应用到你的产品上,我们三年后会发展成什么样。我们许多的产品功能都来源自于旧金山酒吧里不太具体的讨论。

求同存异

我们为没有实战经验的程序员在办公室里设置了Arduino商店。GitHub每个月都会组织健身活动。我们会为谁能在Twitter上赢得最多的粉丝而展开激烈的哲学辩论。我们鼓励员工讨论任何事情,可以是晦涩的编程难题,可以是爬山。

鼓励员工对不同领域感兴趣,激励他们,让他们用完全全新的方式去思考。这样不仅提高了个人,也帮助改善了公司。

创新意味着自我引导

最初Chris问我的一个问题,也是我写这篇博客的原因,就是因为我相信,很多人都不能只是自己想做的产品,这是事实。

当然有些事情更加紧迫,例如在事件表影响到整个网站前就修改它,这比创建一个新的footer重要,但是在GitHub,最重要的在于自我引导,如果你对某一件事情感兴趣,那么就做最感兴趣的吧。往往伟大的作品都出自对作品本身有热情的人之手。

我们能够这样做是因为我们更多的讨论的是我们的产品,每个人都有机会参与。Pull Requests给了我们一个平台,我们可以在产品发布出来尝试我们的新想法。我们做不同的尝试,避免哗众取宠。如果你真的对某个点子感兴趣,就去做吧。我们会跟着你的原型去做。这个方式很棒,催生出很多产品。

原文链接:

http://zachholman.com/posts/how-github-works-hours/
http://zachholman.com/posts/how-github-works-asynchronous/
http://zachholman.com/posts/how-github-works-creativity/

译文链接:http://blog.jobbole.com/6492/


返回顶部 ^