「Shape Up」 适合中小团队的一种工作方式

VS Code 这三年，用户量增长二三十倍，但是团队大小几乎没有变化，依然保持了稳定的产出。为了同时达成高速增长与稳定产出这两个目标，我们是有一套团队运作方法的。虽然我也多次受邀去分享我们的工作经验，但我心中一直有个疑惑，就是这套工作方式是否能真正在其他团队中落地。

直到最近我读了 Basecamp 的产品方法论 Shape Up: Stop Running in Circles and Ship Work that Matters 。这份文档介绍了 Basecamp 是如何保证，一个想法通过层层把关，在一个自由的工作环境中，最终准时变成产品发布出去的。

你可能对 Basecamp 这家公司不太了解，但你一定听说过他们的产出：Ruby on Rails、Rework 和 Remote。
Shape Up 现在只有在线版，可以免费阅读，估计之后 Basecamp 会将其出版。到时候可能会像 Remote 和 Rework 一样获得广泛关注。

虽然 Shape Up 是在讲如何推进产品，但我更愿意称它为一种工作方式，因为产品最终是由人来推动的，而它本身也就是在讲对团队和成员应该进行哪些约束，又该创造哪些自由空间。

当我阅读这份文档时，过去这三年的工作经历在脑海中快速闪过。我们的工作方式跟 Basecamp 有非常多的共同点，而且团队大小也在一个数量级上（20 – 50）人。但同时，我们的产品形态、公司规模、团队组成又有着很大的不同。这意味着，这一种工作方式是具备一定的普适性的。

这篇文章里我会尝试对 Shape Up 做一些梳理，同时结合我的工作经验做一些解读。发布
重要的事情最先说，整个文档的核心目标就是发布。这些年大环境的熏陶下，大家都明白了 “Ship it”，重要的是把产品发布出来，因为一个产品没有问世见到客户，一切都是空谈。“Ship it” 很难，努努力总是可以达到的，没达到的团队就死了。

相比之下，更难的则是产品发布后，持续的发布迭代。为了确保每个 release 计划的新功能都能够发布出去，Basecamp 的第一个准则就是小步快跑，六个礼拜一个 release，把 deadline 作为严格标准，其他事情都得为 deadline 做让步。

六个礼拜的时间是 Basecamp 实践后找到的最合适他们的产品发布周期。VS Code 也差不多，通常一个 release 持续四个礼拜或者五个礼拜。
 
Shaping
 
既然我们确定了六个礼拜后会发生什么，那么在一个 release 周期最开始做计划的时候就要格外小心了，任何错误的估计都可能导致无法按时交付。

回想一下，你有没有什么时候跟老板说这个任务两天就能搞定，结果搞了一个礼拜加班加点才勉强完成的？
对一个存在很多未知数的需求进行工程量的分析是非常困难的。Basecamp 决定在这个上面下功夫，在开始工作前，对需求进行探讨、分析，给出解决方案的雏形，预估风险。Shaping 完成之后，再执行这套方案。他们称这个过程为 Shaping。

Shaping 结果则要求满足三个条件

• Rough 这个计划必须是简单粗浅的，只设计大框架，而不深入细节。这里 Shape Up 提了个观点非常有意思，计划越详细，最后要花的时间越多，因为一旦你把细节都设计好了，团队在执行的时候，可以做的 tradeoff 越少，反而会投入更多的时间
• Solved 这个计划必须是可以执行最后产出结果的，这要求了计划必须考虑清楚潜在的坑（rabbit hole）
• Bounded 这个计划必须是有边界的，既要知道什么可以做，也要知道什么不能做，到哪里止步。

 问题来了，谁能保证 Shaping 的质量呢？Basecamp 用了一个巧妙的方法，Shaping 由专门的资深团队来做，这个团队做完 Shaping 把方案雏形交给其他团队来执行。

也就是说公司实际上分成了两种团队

• 第一种团队进行需求分析，制定方案框架。这个团队人数很少，但是对每个成员的要求都非常高，分析能力、设计能力、表达能力都得是一流的。
• 第二种团队负责执行。这种团队相对较小，由个别设计师加工程师组成。

 VS Code 团队是每个人自己做 Shaping，如果成员比较 junior，一般老板也会参与。不过 Basecamp 的双轨制更适合大部分团队，团队种不一定人人都是顶尖好手，但几个资深工程师还是有的，让他们做 Shaping 的工作。
你可能会问，如果计划都订好了，那执行团队的工作会不会太“无脑”了？执行团队是否永远无法变得“资深”？Shaping 规则要求了要 Rough，是给执行团队提供了一定的空间的。
 
如果你仍然比较担心，我觉得有几个方案可以解决这个问题

• 资深工程师也可以参与到执行中，让执行团队有机会跟资深工程师一起工作。
• Shaping 团队可以预留个把位置给初级工程师，每个 release 轮换，给他们参与 Shaping 的机会锻炼锻炼。

在 Shaping 完了后，Shape Up 还要求要计划写成文案（pitch），这个文案要介绍

• 想解决的问题
• 项目的大小，small batch 还是 big batch。Small batch 需要在一两周内完成，Big batch 则是六周内完成
• 解决方案
• 潜在的坑
• 有哪些功能是不要做的

文案出了之后，接下来就是拿着他们去说服老板，通过评审后，交给执行团队。这个挺像微软以前开发项目前必须做的 Design Spec 的，只不过想在全面投向敏捷，已经不做了。没想到 Basecamp 六个礼拜一个发布周期依然能够继续做这个重的计划工作（当然，这个代价就是得有一个专门的团队做 Shaping）。

更多的关于 Shaping 怎么做，有哪些发现坑的技巧，如果确定项目的时间，如何砍功能，还请阅读原文，原文有实战的例子。https://basecamp.com/shapeup/1.1-chapter-02
而在 VS Code ，我们制定好计划后，都会发布一个 iteration plan https://github.com/microsoft/vscode/issues/8059，这个 plan 也就是类似于 Shaping 的结果，分配到人，然后大家各自按照这个计划来执行就行了。
 
执行

交给执行团队后，接下来就是按照计划来完成了。由于计划其实是非常 Rough 的，设计师跟开发该怎么协作，第一步做什么，怎么集成，这些完全都是交给执行团队的。

Shape Up 对此的定义也很有意思，他们认为交给执行团队的是一个项目 Project，而不是任务 Tasks。该怎么完成项目，是这个团队自己决定的。

Shape Up 也提供了一套工作执行方案，没有太多新鲜的知识。比如开发者不一定非要等设计出设计稿了再动手，可以先用一个 placeholder ，样式也可以不计较，等等。我相信大部分团队都有自己的开发节奏，不必完全照搬。只要 deadline 和方案定了，怎么适合自己怎么来。

不过这个章节提到了一非常重要的规则，能不能保证计划最终发布，很大程度上靠它：拒绝干扰。一个执行团队如果开始这个项目了，那么任何事情都得靠边站。无论你突然有了一个什么爆炸的想法，还是用户找你吐槽一个 bug，都得靠边站。

这一条要想在国内的团队落地，难度相当大，如果没有大老板拍板决定此套工作方式，很难想象在六个礼拜内 PM 不会跑出来加需求。哪怕在 VS Code，我们也是相对松散的，如果有比较紧急的事情，手里的活是可以放一放的，当然出现的次数相对较少。
 
Debt/Bug Fixing

细心的话你会发现，上面的工作计划，完全没有涉及到修 bug。难道说 Basecamp 人人有如神助，写出来的代码没 bug？这当然是不可能的。为了保证 bug 有时间修，技术债有时间还，Basecamp 会在六个礼拜的 iteration 之间，增加两个礼拜的自由时间，在这段时间团队可以修 bug，优化架构等等。

这么算来，其实 Basecamp 的一个 iteration 是八个礼拜。而 VS Code 就紧凑的多
 

• 第一个礼拜主要负责 debt
• 一到三个礼拜做功能
• 一个礼拜测试、发布

 VS Code 也会做类似的 housekeeping，不过我们现在的节奏是一年做一次，一般都是在年底，花一整月大幅度削减 issue 数量。

以上就是我阅读全文后的总结和感受。这个文档中，除了从 Shaping 到执行这条明线外，还有一条暗线，那就是想法到底重不重要？
 
全文一直在强调一下几点
 

• 想法不重要
• 一个让人激动万分的想法，不重要
• 不需要把想法记录下来
• 对一个新想法的默认答案是，不

 你可能会问，如果是这样对想法视而不见的话，产品如何创新呢？Basecamp 的解释说白了就两条

• 首先，好的想法一定会不断地出现在你的脑海里的，根本不用记
• 不管多好的想法，我们等这个 release 结束，自由时间里我们再进行讨论

只有这样，才能保证项目开发不受任何的干扰，保证最终的发布。对此我的感受是，这个团队还得有一个特质，那就是冷静，极度的冷静。想法和界限
我们中的大部分人，应该都会有过那么几次感觉自己发现了个碉堡了的想法，然后立刻动手开始尝试，随着坑越开越大，最后要么弃坑了，要么交付出去个半成品。只有极少数把那个碉堡了的点子，快速变成了碉堡了的产品。
这里不是说你的 “碉堡了” 的想法不好，相反，越好的想法问题越麻烦。因为好想法通常是不收敛的，你可能从一个简单的点出发，最后爆发出成百上千的好点子。

问题是，我们的 release 是有时间限制的：六个礼拜。如果 Follow Your Heart，那么六个礼拜后我们能看到什么结果是不可预期的。遗憾的是，就经验而言，这种做法最后带给我们的产品，往往都是达不到发布的标准的。
知道了这点后，我们在计划的时候，就要时刻保持冷静，尽可能的不要对想法感到过于激动。这听起来挺难的，而且很反人性。我们常说，最加法简单，做减法很难。

其实加法越挺难的，Basecamp 把这种风险规避在了 Shaping 的阶段。由头脑冷静，经验丰富的工程师，对想法进行推敲，最终变成可执行的方案。
 
局限
这种工作方式，在 Basecamp 和 VS Code 团队的效果都很好，但也有很大的局限性。这种局限性来自于 Basecamp 和 VS Code 团队的特质，那就是高度自治。Basecamp 不用说，四五十个的团队，全公司都执行此套方案。而 VS Code 的开发，则几乎是由团队自己推动的，极少收到外界的干扰，这在大公司实属罕见。
要执行此套方案，要求推动者能够获得较大的产品控制权，这个 20 – 50 个人的团队，要高度自治。如果达不到这点的话，无论是需求分析阶段（Shaping）还是执行阶段都无法按照上面的方案进行。

这套方案的核心就在于

• 资深团队、成员分析需求，将想法变成可执行的方案
• 掌舵者和资深团队一起审议，挑选优先级最高的方案
• 执行团队无干扰推动进展
• 一切以发布为首要任务

 说服大团队落地这个工作方式应该是比较困难的，没法一口吃成大胖子。建议可以在小团队内先尝试，一个 tech lead，加几个执行能力强的工程师就足够了，作为 Manager，剩下的就是给他们足够的空间了。