这本书是关于我们在Basecamp进行产品开发的方法指南。它也是一个工具箱，包含多种技术方法，你可以根据自己的流程灵活运用。

无论你是创始人、首席技术官、产品经理、设计师还是开发者，你看这本书的原因大概率是因为遇到了所有软件公司都必须面对的一些普遍挑战。

成长之痛

随着软件团队开始增长，一些常见的挑战也随之出现：

• 团队成员感觉项目永无止尽，看不到尽头

• 产品经理难以抽出时间从战略角度思考产品

• 创始人自问：“为什么我们现在不能像早期那样快速推出新功能了呢？”

当团队从4个人增长到50个的时候，我们在Basecamp亲身经历了这些挑战。

Basecamp始于2003年，最初是我们为自己打造的一款工具。当时，我们是一家为客户设计网站的咨询公司。在客户、设计师和项目管理者的电话游戏中，信息常常丢失。我们希望Basecamp成为一个所有相关方都可以看到工作内容、进行讨论，并明确下一步做什么的集中场所。事实证明，许多公司都存在这种“信息损失”的难题。如今，各行各业的数百万人仍然依靠Basecamp作为共享事实源头。

我们中的三个人构建了第一个版本。Basecamp创始人 Json Fried（杰森·弗里德）主导了设计。他的联合创始人，David Heinemeier Hansson（戴维·海涅迈尔·汉森）负责编写（并且作为副产品创建了著名的网络框架Ruby on Rails）。当时，我是一名专注于可用性和用户界面的网页设计师。我执行Jason对应用关键功能的设计指导，并和他合作完善概念细节。

从2003年7月的第一个原型到2004年2月份的发布，David每周只能投入到10个小时在这个项目上。我们认识到如果不能有效利用这10个小时的编程时间，我们将一事无成。我们之所以如此专注于“敲定”范围，使其在给定的时间预算内完成，正是诞生于这些限制条件之下。

随着业务的增长，我开始拓展自己的技能。与 David 和 Ruby on Rails 的合作使我能够接触到编程的世界。我学习了程序员用来驯服复杂性的技术：例如分解、抽象级别和关注点分离。我一只脚踏在设计，另一只脚踏在编程，我想知道我们是否可以将这些软件开发原则应用到我们设计和管理产品的方式中。

这个想法的第一次测试发生在 2009 年。那时，我们已经聘请了一些程序员，并提供了四个单独的SaaS产品。我们希望将这些产品捆绑成一个无缝的套件，具有单点登录和统一付费。这是一项巨大的技术任务，涉及危险的用户登录界面流程。除了确保底层架构正确之外，我们还必须打断客户进入产品的流程，并让他们更改用户民和密码，原因并不容易解释。我在此项目中同时扮演了设计师和产品经理的角色，并创建了本书描绘的画板(breadboading)和范围映射技术(scope mapping techniques)原型，来管理复杂性。

结果很好，所以我们决定在2012年再次应用相同的技术，当时我们从头开始重新设计了Basecamp 2.0版本。同样，也有很多表面区域需要管理，而且过程再次出奇地顺利。

到2015年，我们拥有了一个核心团队，他们经过了这些过程并取得了显著的进展。但是我们发现很难向新员工阐述这种工作方式。我们的产品团队扩大了四倍，而且所有人都远程工作。这让我们很难传递我们的想法。我们需要一种新的语言来描述我们所做的事情，并需要在新的规模更具结构化。

为了管理这种新的能力，我们从项目长度不固定的模式转向了循环重复周期。（经过一些实验，我们找到了合适的周期长度——六周，后面会详细阐述。）我们规范化了提案和决策流程。我的角色再次转变，从设计和产品管理转向了产品战略。我需要新的语言，比如“塑造（Shaping）”，来描述我们将项目交付给团队之前，为设定界限和降低风险所做的前期设计工作。

就在我们在阐述自己的工作方式越来越得心应手的时候，越来越多的朋友和同行开始向我们请教，询问我们是如何做到的。终于有一天，Jason把我拉到一旁说：“我觉得你应该写本书来讲述这个。”

你现在看到的这本书就是成果。你可以把这个看成是两本书最终合成了一本。首先，它是一本关于基本真理的书。我希望它能为你提供更好的语言来描述和处理应对产品开发过程中出现的各种风险、不确定性和挑战。其次，本书概述了我们当下规模下，为推动产品实质性进展所采用的具体流程。

下面，简单概述一下本书的主要思想：

六周作为一个周期

首先，我们以六周作为一个周期进行工作。六周的时间足够我们从头到尾构建一些有意义的东西，同时也足够短，让每个人从一开始就能感受到截止日期的临近，从而明智地利用时间。我们的大多数新功能都在一个六周的周期内构建并发布。

我们的决策是基于推动产品在未来六周内前进，而不是微观管理时间。我们不计算工时，也不质疑个人如何度过每一天。我们没有每日会议。我们不会每两周重新审视我们的路线图。 我们的关注点在更高层次。我们告诉自己：“如果这个项目在六周后发布，我们会非常高兴。我们会觉得时间花得值得。”然后我们承诺六周的时间，并让团队独自完成任务。

塑造工作

其次，我们在将工作交给团队之前会先进行“塑造”。一个由资深人员组成的小组与周期小组并行工作。他们在我们考虑给某个项目下注之前定义解决方案的关键要素。项目在合适的等级被合理抽象：具象到团队知道要做什么，同时也足够抽象，让他们由足够的空间自己解决有趣的细节。

在塑造过程中，我们较少关注估算，而更多地聚焦于我们的爱好。与其问需要花多少时间来完成某项工作，不如问：我们愿意花费多长时间？这个想法值多少时间？这就是塑造的任务：将问题范围缩小，并设计厨一个符合我们爱好约束条件的解决方案大纲。

让团队负责

第三步，我们会给一个由设计师和程序员组成的集成团队完全的责任权力。他们定义自己的任务，调整范围，并以其逐步构建产品的垂直切片。这与其他的方法论截然不同。在其他方法论中，管理者将工作分解，程序员就像检票员一样接下任务。

这些概念共同形成了一个良性循环。当团队更加自主，高级管理人员可以减少管理时间。在管理上花更少的时间，高级人员可以更好地塑造项目。当项目塑造得更好，团队有着更清晰的界限，因此可以更加自主地工作。

针对风险

在流程的每一步，我们都会针对一个特定的风险：无法按时交付的风险。这本书不是关于构建错误事情的风险。其他书籍可以帮助你解决这个问题（我们推荐 Competing Againt Luck）。改善你的探索流程应该在恢复交付能力在之后进行。你可以拥有世界上最好的策略，但如果无法付诸行动，那又有什么用呢？

这本书是关于卡住的风险，被上个季度的工作拖累，浪费时间在意外问题上，无法自由地做你明天想做的事情。

我们将项目纳入时间框之前，通过解决开放性问题来降低塑造过程中的风险。我们不会将仍有未解之谜或复杂相互依赖关系的项目交给团队。

我们通过将赌注限定在六周来降低规划过程中的风险。如果项目超时，默认不会获得延期。这个“断路器”确保我们不会在需要重新思考的概念上投入多倍于原始预期的资源。

最后我们在构建过程中通过尽早整合设计和变成来降低风险。我们不是构建很多互不关联的部分，并希望它们在最后一侧拼凑在一起，而是早期构建一个有意义的工作环节（端到端联通），然后重复执行。团队从最未知到最不令人担忧的部分依次安排工作，并通过尽早整合来学习什么有效、什么无效。

本书的组织结构

第一个部分是关于塑造 —— 我们在项目被认为可以启动之前的前期工作。每一章都解释了这个过程中的一个具体步骤，从为一个原始想法设定胃口，到勾勒出一个解决方案，再到撰写一个展示潜在项目的提案。再此过程中，你将学到具体的技术——如面包板和粗标记草图——以保持设计在合理的抽象层次。

第二部分是关于 下注 —— 我们如何在提出的项目中进行选择，并决定每六周做什么。

第三部分是关于 构建 —— 我们对团队的期望以及他们用来发现该做什么的特殊实践。我们将探讨团队如何确定该做什么，他们如何整合设计和编程，如何跟踪已知与未知的内容，最后如何做出艰难的决定以按时完成项目。

最后，附录为你提供了一些在公司需要进行变革时的帮助。有一些关于如何尝试第一个六周实验的建议，调整方法以适应公司规模的技巧，以及如何使用Basecamp实施 Shape Up 的具体指导。