3 章节1: 简介
雷欧雷欧 保存 显示目录
这本书既是 Basecamp 的开发指南，也是一个存满了技巧的工具箱，你可以用自己的方式去充分利用它们。
无论你在团队中是创始人、CTO、产品经理、设计师还是开发人员，你都可能遇到所有软件公司共同面对的一些挑战。
成长的烦恼
随着软件开发团队的发展，他们往往会遭遇相同的困境：
- 团队成员感觉他们的项目永无止境。
- 产品经理无暇从战略角度审视产品。
- 创始人开始反思：我们为什么不能像以前那样推出新的功能了呢？
在 Basecamp 从 4 人发展到超过 50 人的过程中我们也同样面临过这些挑战。
Basecamp 诞生于 2003 年，最初是我们为自己打造的一个工具。当时我们是一家为客户设计网页的咨询公司。信息会在客户、设计师、项目管理者的电话网络中丢失。我们希望借助 Basecamp 打造为信息聚合地，各方都可以在这里查看工作进度、讨论项目、明确接下来的步骤。事实证明，许多公司都有这种「信息丢失」的问题。今天，数以百万来自各行各业的人都选择 Basecamp 作为他们共享的信息之源。
最初的版本是由我们团队中的三个人打造的。Basecamp 的创始人 Jason Fried 主导了设计。他的联合创始人 David Heinemeier Hansson 编写了程序（并创建了著名的网页框架 Ruby on Rails 作为副产品）。当时我是一名专注于可用性和用户界面的网页设计师。我遵循着 Jason 的设计方向设计了程序的关键功能，并和他合作完善了原型概念的许多细节。
从 2003 年 7 月 第一个原型诞生到 2004 年 2 月启动，在此期间，David 每周只有 10 小时的工作时间。我们很清楚，如果我们不谨慎地利用这 10 个小时，将会一无所获。我们高度专注于「锤炼」项目分区，使其能够充分利用这受限的时间预算。
随着业务的增长，我开始扩展自己的技能。和 David 在 Ruby on Rails 上的合作使我得以进入编程的世界。我学到了许多程序员用来驯服复杂问题的技巧：比如因数分解、抽象层级以及重心分离。一脚涉足设计的世界，一脚涉足程序的世界，我很好奇我们是否可以将这些软件开发的原则应用于我们设计和管理项目的方法上。
2009 年时，我们初次尝试了这个想法。那时的我们已经聘用了更多的程序员，并且提供四款独立的 SaaS 软件。我们希望将这些产品绑定在一起，变成一个支持单点登录并且统一付费的集合套件。这是一个庞大的工程，同时还面临着危险的用户流程。除了正确的底层架构外，我们还必须在用户使用产品时打断他们，让他们修改用户名和密码，而需要这么做的原因也难以解释。我在这个项目中担任设计师与产品经理，并且将本书中描述的面包版技术与区块划分技术制作出了原型，用以管理错综复杂的事物。
在 2012 年从头开始重新设计 Basecamp 2.0 版本时，初次尝试取得的卓越成果让我们决定再次使用同样的技巧，同样的有大量的洁面需要进行管理，同样的进展顺利。
到了 2015 年，我们的核心团队已经有了这些的经验并且进步显著。但是我们也发现对于新入职的成员，我们很难传达我们正在做什么。我们的产品团队扩张了四倍，所有的成员都在远程工作。这使得我们的工作更加难以意会，只能言传。我们需要用语言来描述我们正在做什么，并且还需要调整结构来适应我们团队的新规模。
为了充分调动这些新的生产力，我们将一次性项目线性长度转变为了循环周期（我们经过了一些实验才找到了合适的周期长度：六周。这点容后再叙）。我们将写安利和下注的过程正式化。我的角色也再次转变，从设计师与产品经理到产品策略。我需要类似于《塑造》这样的新语言来描述我们为设置边界以及将降低项目风险的前期设计工作。
随着我们越发善于向自己团队阐明我们的工作方式时，越来越多的朋友和伙伴开始询问我们是如何做到这点的。终于有一天，Jason 把我拉到一边说：我觉得你应该把这个写成一本书。
这本书就是最终成果。你可以把它看作两本书的结合。首先，它是一本关于基本现实的书。我希望你能从中学到如何更好的地语言来描述和处理产品开发时遇到的风险、不确定性和挑战。其次，这本书也概括了我们工作的具体流程。我们以当前规模在产品上实质性进展所采用的流程。
以下是本书核心观点的简述。
六周循环周期
首先，我们的工作周期为六周。要做出一些有价值的内容，六周足够长。同时又足够短，能够让所有人从一开始就感受到截止日期的压力，这样他们就会更加合理地利用这段时间。我么大多数的新功能都是在一个六周循环中开发并发布的。
我们的决定是基于在接下来六周对产品进行推进的，而不是对时间进行微观管理。我们不计算工时小时数或者见检视每天的工作成果。我们没有每日会议。我们不会每两周就调整一次项目规划路线图。我们的关注点在更高的层级。我们这样告诉自己：「没有什么比六周后项目成功发布更让人兴奋了。这是对我们所花费的时间的肯定」。因此我们承诺给予六周时间，让团队自行去完成工作。
塑造工作
其次，我们在将工作交给团队前会先对其进行塑造。一个小而精的高级工作组会和循环团队平行工作。他们会在我们对项目进行下注前划定解决方案的核心元素。项目会被定型在正确的抽象层级：足够的具体，让团队知道他们要做什么。也要足够的抽象，留出足够的空间让团队填充进有趣的细节。
在进行塑造时，我们更加关注我们的投入计划，而非对项目的预估。我们不会问要完成这些工作我们需要多少时间，而是问：我们想要投入多少时间？这个想法值得我们投入多少时间？塑造的任务就在于：简化问题，设计出符合我们计划投入的解决方案大纲。
将职责下放给团队
第三，我们让一个由设计师和程序员组成的小型团队全权负责。他们自己分派任务，对区块范围进行调整，并将产品逐一划分为切片进行开发。这与那些传统的方法不同，在传统方式中，管理者将工作切分后，程序员就像售票员一样开始对任务打卡。
将这些概念结合起来就可以形成一个良性循环。团队的自发性越高，主管们就需要花在团队管理上的时间就越少，就有更多的精力可以投入到产品中，也就能更好地塑造项目。项目塑造得越精巧，开发团队的开发边界就越清晰，从而又会回馈到工作自主性中。
关注风险
在过程的每一个步骤我们都会关注一些特定的风险：会导致项目不能按时发布的风险。这本书不讲述开发方向错误的风险。你可以在其他书中寻求到这类帮助（我们推荐《Competing Against Luck》）。在你改进你的探索过程前，首先要确保你能准时发布内容。如果不能付诸于行动，再好的策略也没有意义。
在本书中我们会讨论的风险包括：团队走进困境、被上一个周期的工作拖累、在意料外的突发问题上耽搁时间、无法自行安排明天的工作计划。
我们会在塑造阶段就要降低风险，在项目进入我们的时间线安排前我们就要把开放性的问题解决。我们不会把一个不够独立或者藏有无底洞问题的项目交付给开发团队的。
我们在规划阶段就会把赌注的时长限制在六周内，从而降低风险。如果一个项目超出了六周，我们默认是不会为其延期的。这种「断路器」的机制确保了我们不会在原有的计划投入上数倍的资源。
最后，我们通过早早地将设计与程序进行继承来降低开发过程中的风险。与其开发许多毫无关联的内容，然后在最后期限前期待它们能够完美地结合在一起。我们何不提早就开发一个个前端后端结合的有效部分然后重复这个过程呢。开发小组会将工作按照从最不确定到最无需担忧排列，并且有赖于提早进行了整合，可以第一时间了解到之前的成果是否过关。
本书构成
第一部分是关于塑造——我们在将项目加入到排期表前做的工作。从对原始构思进行投入规划，到拟出一个解决方案草图，再到为潜在的项目书写宣传安利，每个章节都会具体解释这个阶段的一个具体步骤。在这个过程中你将学到一些用于保证你的设计停留在正确抽象层级的特殊技巧，比如面包板和粗体记号笔草图。
第二部分是关于下赌注的，我们是如何在各种潜在项目中进行投注，从而决定接下来六周我们要做什么。
第三部分是关于开发，我们对于开发团队的期许以及他们用于探索工作任务的特殊技巧。我们将会了解到开发团队是如何确定他们要做的任务的，如何将设计与程序整合在一起，如何从已知的内容去追踪未知内容，以及他们在最后阶段为了保证项目能及时完成做出的艰难抉择。
最后，附录提供了一些你在公司进行调整所需的帮助。一些首次尝试循环迭代模式以及根据你的公司规模进行调整的建议。还有如何借助 Basecamp 实现塑造的具体指导。