我们在Basecamp如何组织工作和团队

原文: https://m.signalvnoise.com/how-we-set-up-our-work-cbce3d3d9cae#.uwvu65vwu

cover

编者按:作者Jason Fried,Basecamp创始人兼CEO。《Getting Real》、《Remote》以及《重来》等书的共同作者。

「你们这些家伙到底是怎么工作的?你们怎么决定到底做什么?你们团队多大?你们如何组织工作本身」这些问题我整天看到。我已经在一些小型的研讨会上分享过一些细节,是一对一的分享,考虑是时候写点东西跟大家详细的分享一下了。

我们现在使用的工作流程是经过十年的提炼而成的。就像我们一直迭代我们的产品一样,我们也在一直迭代我们公司的工作方式。我们把我们的公司也当成一个产品。当你开始把你的公司当作产品来对待的时候,你就可以用新的方式来改进它。我觉得我们正在使用「我们如何工作」v5.2版本。

让我们看一下:

我们以六个礼拜为一个周期进行工作

大概每六个礼拜我们就开始一个新的产品迭代周期。每六个礼拜的迭代周期中包含两种类型的项目:

为了让你能够对项目大小的定义有个认识,这儿有一篇内部文章介绍了在迭代周期里边要做的事情

当为期六个礼拜的迭代结束之后,我们会暂停日程表中的项目,拿出一到两周的时间给每个人独立支配,这段时间可以用来修复一些问题,做一些自己感兴趣的小项目,通常情况下是在开始下一个迭代周期之前放松放松自己。给大家足够的时间来进行工作切换。我们也会用这段时间来坚定我们下个迭代要做的事情。通常做这件事会比较多。

注意:我们不用冲刺(sprints)。我讨厌冲刺(sprints)这个词。冲刺和工作是相互冲突的。我们不是以最快的速度奔跑,而是以合适的速度冷静的工作,并且在工作过程中出明智的决定。我们不会用蛮力,不会使我们团队疲于奔命。

六个礼拜…如果有的事情所需的时间超过了六个礼拜怎么办?

我们相信几乎所有事情都可以提炼出一个六个礼拜的版本。偶尔会有事情超过这个时间限制 - 比如需要大力研发的项目,我们之前没用过的新技术,等等。但是我门发现几乎所有事情中的重要部分都可以在六个礼拜左右完成。而且完成的不错。

能实现这个的奥秘我们内部称为范围锻造(scope hammering)。我们会先审视一个很大的需求,把这个功能提炼成一个在六个礼拜内能实现的最优版本。主要的工作就是审视这个功能,了解它的本质。问题的关键不是这个功能能做成什么样,而是应该要做成什么样。

在迭代开始之前,我们对项目为期六个礼拜的版本是什么样子已经心里有数。迭代周期不包括计划所花的时间 - 所有计划和思考在讨论(pitch)阶段完成。这个事情必须在团队启动前完成。如此一来这六个礼拜都可以用来实现功能和执行。不会有时间会被浪费在处理未知的大坑上 - 我们尽量在启动之前确保所有重要的事情大家都明了。

工作如何分配?

每个Big Batch项目会分配给一个团队。所以如果我们在一个迭代周期内要处理两个Big Batch项目,我们将会用一个团队处理其中一个项目,然后另一个团队处理另一个。Small Batch项目都由同一个团队完成。在整个迭代周期内所有团队都会并肩作战。

一个团队两到三个人,大小取决于工作的性质。一个程序员和一个设计师,或者两个程序员和一个设计师。基本就这样。不会有四个、五个或六个人组成的团队。我们处理的所有事情都是由三人团队完成的,人数不会超过这个。

我们认为3是所有事情的理想大小 - 超过这个大小事情的复杂度将会呈指数型增长。

团队都是临时组建。在迭代开始之前,我们会询问每个人接下来的六个礼拜他们想做什么类型的工作。团队按照员工的兴趣自由组建,或者我们会把成员按照他们的喜好分配到一个团队中。团队在迭代完成之后一般都会发生变动,所以每个人都有机会跟不同的人一起工作,但是有的时候团队在几个迭代中都没有变化。对此没有硬性规定。

我们有专门的项目经理吗?

没有。团队中的设计师领导这个项目,但是设计师和程序员(们)之间有着非常紧密的工作关系。他们在每件事上都一起处理。

项目角色不重要,每个人都在相同的地方追踪工作、沟通等等。对于我们来说这个地方就是Basecamp 3。当所有的事情都放在一个地方,每个人都知道事情在哪,进展如何,并且可以自给自足。把工作、沟通以及管理通过不同的工具或产品割裂开来:一非常低效,二团队成员想了解项目的整体情况非常难。

你们会跟踪时间吗?

不会。我们不会去度量效率,不会把实际情况和计划做比较。我们会在六个礼拜内完成一些事情。在这段时间内如何完成它由团队自己来决定。

重点是我们不会一口气跑到终点然后发现我们超时了。我们会一直留意什么已经完成了,什么还没完成,还剩下多少时间。工作范围永远都在变化 - 如果我们时间不够了就缩小一些,如果我们发现我们的时间比想象的要多就扩大一些。这是可以协商的。这个过程非常弹性。但是deadline不能有弹性 - 从我们启动向后数六个礼拜。

想法从哪里来?

我们没有单独的时间用来讨论想法。也没有单独的人来提出想法。想法来自所有人,并且可以随时提出。它们来自于我们自己,它们来自于客户。想法是一直在变的。我们会一直有一个由想法组成的泡泡海洋。当一有泡泡从海洋中浮出落在岸边,这时我们会开始审视这个想法。(译者:比喻手法)

阐述(pitch)一个想法

当一个想法足够成熟之后,就可以拿出来进行讨论了。pitch的意思是对问题进行全面的定义,同时也包括预期的处理方案。

这有一个真实pitch的例子,所以你可以了解一下它们的一般形式。我们不会亲自pitch - 我们都是把pitch写下来,然后发到Basecamp上用来review。

为什么我们不亲自pitch?有几个原因:

  1. 我们觉得完整地写下一些事情更好。这样可以保证正在进行pitch的人不会被打断。他们能够随心所欲的完整的表达他们想说的。
  2. 除此之外,我们相信把东西写出来能够让你对事情有更高程度的认识。
  3. 我们是异步交流的忠实信徒 - 先写下来,然后其他人在他们有空的时候会去看的。面对面实时沟通或者强制按照日程安排来做非常低效。
  4. 最后,当问题以消息的形式发到Basecamp上的时候,所有反馈和相关的问题会自动添加到原始问题上。这保证了和pitch相关的所有的沟通都在同一个地方进行,所以每个人访问到的内容是一样的。

你们如何决定到底要做哪个项目

大家都对这个很好奇。真相是感性胜于理性。想法来自于所有人,但是在迭代里边做什么最终由我 (ceo), David (cto), and Ryan (战略官)来决定。提前一周或者在接近迭代开始的时候,我们会review Basecamp上所有的pitch,也会分享一些我们自己的想法,并且通常会激烈讨论到底做什么。之后我们经常会开30分钟的电话会议(Skype or Hangout) ,再做一些讨论,然后做出最终决定。

最终的决定取决于很多因素 - 之前pitch完成度如何,客户痛点,尝试新的想法,员工觉得有的功能不好用需要优化,潜在商业机会,等等。但是无论决定是什么,好消息是六个礼拜后我们又可以重新开始新一个迭代的工作。所以如果有些事情这个迭代没加进去,一个半月之后就可以继续评估。

如何向团队宣布本迭代的计划?

一旦这个迭代定义好了,并且要做的事情已经分到了Big Batch和Small Batch工程中之后,我会写一个声明并发布到Basecamp上的「Building BC3」项目中。Building BC3这个项目是与Basecamp相关的高级产品工作的主项目。我们会在那里谈论大的远景,分享pitch,讨论想法,规划迭代,等等。这有一个迭代声明的例子(这个跟之前我在链接中给出的是一样的,如果你之前没看到可以在这里看)。

实际工作是如何组织的?

每个Big Batch项目都会对应一个Basecamp项目。这里有一个Big Batch项目的模版。注意:Blackburn是这个迭代的名字(我们以山脉命名迭代)…..

001

(每个任务,讨论,评论,声明,截止日期,注释,以及围绕着模版进行的聊天都在这同一个项目中进行。)

一个迭代中所有的Small Batch项目都放在同一个单独的项目中。这有一个例子,包括Blackburn迭代中所有的Small Batch:

002

每个Small Batch项目通过一个独立to-do列表来管理。下面是Blackburn迭代中的四个Small Batch项目:

003 (每个设计工作,编码工作,以及QA内容都放在一个独立的to-do列表里边,列表以我们正在进行开发的功能的名称来命名。这种工作方式整个团队 - 不管什么角色 - 都知道事情进展得怎么样了。)

QA如何工作?

我们QA团队有两个成员:Ann和Michael。她们在正在进行的项目之间游走,当有的团队希望验证一些功能的时候会邀请她们加入。我们发现她们越早介入越好。QA也适用六个礼拜的时间窗口,所以不会由于在最后一分钟发现一大堆bug而导致延期。这就是为什么我们不会等到最后才启动QA。至少大多数情况下是这样。

你和David如何参与?

David和我(Jason)以某种程度参与到几乎每个面向用户的项目以及产品更新。

我和设计师一起探索早期的想法,然后帮助提炼和简化我们将要做的事情。我也和设计师一起处理文案 - 确保我们使用的词句别人看得懂。Design review不是用来批评谁的,而是用来解决问题的。

David帮助程序员制定开发计划 - 思考数据模型,把团队精力聚焦在性能和速度上,并协商做一些技术妥协,以便技术工作在六个礼拜内能够完成。

再提一句,我们也都会参与产品规划 - pitch 想法,决定下个迭代要做什么。我们和Ryan紧密合作,思考每个功能,并且从整体上审视产品,找出最佳的行动时机。

当然还有很多没聊的

我尝试过把主要的内容列个提纲,但是我确信这样做肯定会存在信息沟通不畅。这是毋容置疑的 - 产品工作很大程度上依赖于灵感。当然,希望这里提供的信息能让你对Basecamp的工作方式有一个大体上的印象。

如果你有一些具体的问题,或者希望了解一些我上面没讲到的东西,请留言,然后我们会尽最大能力回答大家。感谢阅读 - 我知道文章挺长的!

(全文完)
comments powered by Disqus
Powered by Github  &&  Jekyll
Fork me on GitHub