推荐电子书：《Shape Up：Stop Running in Circles and Ship Work that Matters》

这是由 Ryan Singer 编写的一本电子书，讲述了 Basecamp（著名的项目管理与协作工具团队）在产品开发与团队协作上的独特方法论和实践经验，主要面向中小型软件开发团队，帮助他们高效地完成有价值的工作，而不是陷入无尽的拖延和混乱。

Shape Up 提出了一个独特的产品开发框架，专注于如何有效规划、执行和交付项目，核心分为三个阶段：

1. Shaping（塑造阶段）
在这个阶段，领导者和产品负责人会提前设定项目的 边界、问题 和 解决方案的大致轮廓。目标是将项目定义得足够清晰，同时又保持一定的灵活性，让团队有空间去实现目标。

2. Betting（下注阶段）
公司会基于业务目标和团队资源来“下注”——决定哪些项目值得团队投入时间和精力。

3. 项目会被分配一个 固定的时间周期（例如 6 周）。
如果在规定时间内完成，则项目交付；如果未完成，则项目被丢弃或重新评估。
Building（构建阶段）
这一阶段由工程师和设计师执行项目。他们专注于实际的交付，团队按照之前的“塑造”进行构建，但在实际执行中有自主决策的自由。

这种方法的核心理念有些类似于 Scrum 里的时间盒子 Time box，通过设定明确的时间边界，确保项目不会无限拖延。在时间有限的情况下，团队会优先解决最重要的部分，逐步收敛项目范围。

开发团队在预先决定的六周周期内集中精力实现成型阶段定义好的目标与界限，不接受中途变更或新增需求。完成周期后，会有约两周的“冷却期”，团队在此期间可进行回顾、维护、学习和为下一个周期做准备。这种“6周冲刺 + 2周缓冲”的节奏帮助团队持续产出有质量的功能和产品迭代。

这本书发布于 2019 年，和主流的敏捷开发还是有些不太一样，但确实抓住了精髓：谋定后动，想清楚做什么再做项目，将发布时间定死；倒逼着选择最重要的事去做；6 周的迭代中不接受需求的变更，这也让需求范围也在某种程度上不会扩大，从而能做到定时发布（或失败）。

这种开发模式可能适合Basecamp在当时的阶段，但未必适合很多团队，对于很多产品来说，6+2周的开发周期是有点长了，6周无法发布就算失败对于很多团队来说也是难以接受的，最重要的是这种开发模式要给予团队足够的空间，由团队自己决定如何实现目标，而不是对团队进行微管理。

不管怎么说，这本书还是值得一看。
英文版阅读地址：https://t.co/5pACpfpncK
中文翻译地址：https://t.co/bzxh8XPuBi

点击图片查看原图

点击图片查看原图