编者按：Basecamp的产品哲学是小而美。这种哲学不仅体现在他们的产品上，也体现在他们的管理上。鉴于经常有人问自己公司是如何决定做什么以及如何决定怎么做的，CEO Jason Fried决定写一篇文章专门来谈这个：项目以6周为限，团队临时组建，最大规模不超过3人，每次周期都可以灵活组合，不设专门项目经理，不跟踪时间进度……跟典型的公司组织和项目管理方式相比称得上是小清新了，也许初创企业可以好好借鉴一下他们的做法。当然，这种做法本身也需要与时俱进，Jason Fried说得很好：把公司当作产品来对待，你就会时刻考虑对它进行更新换代。

我经常会收到这样的问题：“你们这帮家伙是怎么工作的？你们是怎么选择做什么的？你的团队有多大？你的工作是怎么组织的？”我已经在一些小型研讨会或者一对一面谈时讲过这方面的细节了，但是全面阐述需要专门腾出时间来写一篇文章。

经过10年的优化之后，我们开始着手这件事情。就像我们的产品迭代一样，我们公司的运作方式也在不断更新。我们把自己的公司也看成是一个产品。当你开始把公司视为产品时，你就会开始以全新的方式对它加以改进。我感觉“我们是怎么工作的？”这个产品我们现在正处在的5.2版（注：这样的话大概每2年就换一版）。

我们是怎么工作的呢？下面就来看看：

以6周为一个周期

我们大概每6周就开始新的产品工作周期。这个周期包括有两种类型的项目：

• 大项目（Big Batch）：大项目是规模较大的功能或者东西，可能需要整整6周来完成。6周的周期里面我们一般要做1、2个大项目。

• 小项目（Small Batch）：小项目做的东西规模较小，往往是调优、小调整，添加容易，应该1天到2周之内就可以完成。在一个周期里面我们一般要做4到8个小项目。

为了让大家感受一下什么样的项目是大项目和小项目，这里有一个我们内部项目周期发布的具体例子。

一旦6周的周期结束，我们都要用1、2周的时间修补一下东西，或者选个自己想做的宠物项目做一做，然后在开始下一个周期之前修整一下。给环境切换留出充分的时间。我们还会利用这段时间梳理下一个周期要处理的问题。主要是这些事情。

注意，这不是sprints（冲刺）。说实话我很鄙视这个词。Sprint和工作走不到一起。这不是要你有多快跑多快，而是要你冷静工作，保持节奏，然后在这个过程中做出明智决策。不要搞暴力破解，不要到头来让所有人都累得够呛。

6周……如果做的东西太大6周的时间不够用怎么办？

我们相信几乎所有事情6周的时间都可以出一个版本了。当然，偶尔也会有少量事情会突破这一限制——比如深度的研发项目，我们此前没有碰到过的全新技术等。但我们已经发现几乎所有重要的事情都可以在6周或者更少的时间内完成。而且可以做得很好。

这件事情可能做成的秘密是我们所谓的范围锤炼（scope hammering）。面对手上的一大块大理石，我们要考虑如何进行雕刻，用凿子把不必要的东西凿掉，尽可能做出最好的6周版本。一切都与仔细审视功能，找出真正的精髓有关。不是它可以变成什么样，而是应该变成什么样。

在把任何项目纳入产品周期之前，我们已经搞清楚了这个6周时间做出的版本应该是什么样的。规划并不在这个周期的时间范围内——所有的规划和考虑都是在pitch阶段进行的。也是在一支团队准备要开干之前完成的。这样的话这整整6周的时间都是用来实施和执行。没有一分钟是花在巨大的不确定性上面——我们试图确保在开始之前所有的大东西都已经了解透彻了。

谁来干？

每一个大项目都要分配一个团队来完成。所以如果某个周期我们有两个大项目要进行的话我们会让一个团队负责其中一个项目，然后让另外一支团队负责另一个项目。小项目全部都是由一个团队来完成。在整个周期内所有团队都是一起工作的。

视工作类型不同，一支团队由2、3个人组成。要么是一个程序员加上一个设计师，要么是2位程序员跟1位设计师搭配。就这样。没有4、5、6人组成的团队。我们要做的所有事情必须由最多3人组成的团队来完成。

我们认为3这个数对于大多数事情来说都是最理想的——超过这数字会导致复杂性的指数增长。

而团队都是临时组建的。在一个周期开始之前，我们会询问每一个人未来6周他们喜欢干什么样的工作。团队要么是围绕着兴趣领域组建，要么根据他们的优先选择来分配人。在一个周期结束之后团队往往就会调整，这样每个人都有机会跟不同的人共事，但有时候他们也会一起工作好几个周期。这方面并没有什么严格的规定。

我们有没有专门的项目经理？

没有。项目由团队的设计师领导，但是设计师与程序员之间有着非常紧密的工作关系。所有事情都是一起干的。

不管角色如何，每一个人都在同一个地方工作，在同一个地方沟通等。对于我们来说这个地方就是Basecamp 3。当所有人都在同一个地方时，每个人都知道东西在哪里，事情到底怎么回事，而且每个人都可以自给自足。把工作、沟通和管理分散到不同工具/产品进行会1）非常低效；2）对于整个团队来说很难看到全局情况。

我们跟踪时间吗？

不。我们不考核效率，不进行实际与估计时间的对比。我们有6周的时间来完成一件事情。这段时间内怎么来完成这件事情完全由团队自己决定。

重要的是我们不会等到最后才发现时间不够用了。我们会一直关注做了什么事情，还剩下什么事情，还有多少时间。范围总是在变——如果时间不足的话我们就把范围缩小，如果时间比我们预想要充裕就把范围扩大点。这是一个协商的过程。这中间的流动性很大。不变的是截止期限——启动6周后必须交作业。

想法从何而来？

我们没有专门腾出时间去想点子。也没有专门的一群人去想点子（注：大企业往往有企业发展部或者企业策划部）。所有点子都来自我们，来自我们的客户。想法总是动态的。我们时刻都会有新想法冒出来。在这个创意的海洋里有些想法会漂到岸边。这时候我们就会更加仔细地留意一下。

推销创意

当一个想法感觉足够成形了，接下来就要把它推销（pitch）出去。Pitch是对问题的完整定义，也是对问题解决的初步建议。

下面是一个pitch的实际例子，通过它你可以看看它的一般形式。我们不会自己来讲——我们的pitch都是写出来然后发布到Basecamp上面供大家评审的。

为什么我们的pitch不是口述的形式？理由有以下几点：

• 我们觉得把东西完整写下来更好一些。这样的话做pitch的人才不会被打断。他们的故事才可以如自己所愿得到完整的展现。

• 此外，我们认为把东西写出来可以让你对它有更深入的考虑。

• 我们是异步通信的忠实信徒（注：这一点可以参见《群聊的正确使用方式》，Jason Fried在里面详细讨论了Slack半同步半异步机制弊端）——先写下来，再给别人一点时间去消化。实时的沟通，不管是面对面还是虚拟的，这种同步性的安排其实效率是非常低的。

• 最后，虽然这是以消息的形式在Basecamp上面发布的，但所有的回复和随后问题都是自动附在原始帖子后面的。这使得围绕着pitch的所有沟通全部都是集中在一个地方，在一个页面上的，这样每个人都能看到同样的故事。事实只有一个版本。

你们怎么决定做哪个项目？

每个人对此都很好奇。说实话，这更多是艺术而不是科学。想法从各个地方冒出来，但把想法变成产品周期的最终决定权落在我（CEO）、David（CTO）以及Ryan（战略）3个人手上。在周期开始前的1周左右，我们会对Basecamp上面发布的所有pitch进行评审，同样也会分享我们的一些看法，往往还会对项目选择进行激烈讨论。然后我们通常会进行30分钟左右的会议（在Skype或者Hangout上面进行），再吵一轮，然后做出最终决定。

点子能否过关取决于很多变量——pitch的完整程度如何，客户的痛点在哪里，我们想要尝试的新点子在哪里，什么地方做的还不行需要修订，我们要做的商业案例是什么等等。但无论决定该如何，好消息是6周过后我们又可以开始新一轮的工作。所以如果这次pitch没有入选的话，1个半月之后还有再次被考虑的机会。

产品周期是如何发布的？

一旦周期确定下来，并且所有工作都编排到大小项目里面了，我就会写一篇公告发布到Basecamp内部的“Building BC3”项目上。Building BC3项目是Basecamp相关的高级产品工作的主项目。是我们讨论全局性事务、分享pitch、讨论想法、安排产品周期等的地方。这里是一个产品周期通告的例子。

实际工作是怎么组织的？

每一个大项目都会有自己的Basecamp项目。这里是一个大项目的模板例子。注意：Blackburn是本次产品周期的名字（我们用山来对周期进行命名）……

有关Template是模板的每一项任务、讨论、注释、公告、期限、笔记以及聊天都在一个项目内进行。

而一个周期内的所有小项目都放到一个Basecamp项目内。以下是Blackburn周期的小项目例子：

每一个小项目都以独立待办事宜清单的形式进行管理。下面就是Blackburn周期的4个小项目：

每一项设计任务、变成任务以及QA事务都放到一个待办事宜清单里面，清单以我们要做的功能名字命名。这样的话整个团队，无论其角色是什么，都可以知道是什么意思。

你们QA是怎么做的？

我们的QA团队有两个人：Ann和Michael。他们会到处看看进行中的不同项目，或者接受团队邀请来对东西进行检查或者复检。我们发现，他们介入得越早越好。QA一样是6周的时间窗口，这样的话才不会到最后一分钟才发现问题。所以我们不会等到最后才开始QA。至少大部分时间不会。

你和David如何参与？

几乎每一个面向客户的项目或产品更新我和David都会有一定程度的参与。

在早期我会跟设计师一起探讨想法，然后在项目过程中帮助提炼和简化。文案方面我也会帮设计师一起考虑，确保我们的措辞有意义。设计评审不是批判，而是解决问题的讨论。

David帮助程序员制定进攻计划——考虑模型的问题，保持我们对性能和速度的关注，并且协商技术妥协，从而保证6周的时间窗口不会超时。

如前所述，我们还参与到在产品规划阶段——也就是想法介绍以及确定特定周期的工作。我们跟Ryan密切配合，仔细考虑每一项功能，全面审视产品，确定该做什么以及什么时候做。

当然，事情不仅这些……

我已经试着把主要的东西都列出来了，但不敢保证没有纰漏。遗漏的地方当然会有——产品工作有很多视情况而定的时刻。但希望这里所列东西已经足以让你对我们在Basecamp是怎么工作的有了基本了解了。

本文转自d1net（转载）