Shape Up 阅读笔记（2）- 基本工作模式

Shape Up 的基本工作模式

Shape Up 中描述的关键工作包含三个部分

Shaping：对应一般软件研发产品需求分析阶段的需求分析过程

Betting：对应一般软件研发过程中的立项或需求排期决策过程

Building：对应一般软件研发过程中的开发实施过程

Shape Up 的时间安排

整个工作节奏，分为一个六周的 Cycle 和一个两周的 Cool Down

Shaping + Betting 和 Building 是并行的而非串行的

强制和承诺

整个公司不同产品线的研发工作，都强制使用同样的工作节奏。

原因：允许不同周期的项目并行，会导致资源的调配越来越复杂，最终项目管理工作变成了 Calendar 上的甘特图游戏，疲劳而无效。

Shape 选择了让需求的体量（后续其实叫赌注）配合实施项目全都强制一致，系统性的降低了全公司的项目管理成本。

承诺一个不被任何干扰打断的项目周期

Shape Up 理解每一个人最佳工作效率是怎么形成的，尽可能避免任何会干扰员工高效输出的因素。

从来都没有 just few hours 或者 one day 的工作，人类跳转与不同的工作之间是需要极大的心智负担，因此效率最高的流程，就是让员工持续工作不要被轻易打断的流程。

不轻易打断项目，是一种很难做到的管理承诺。

为什么是项目 Cycle 是六周？

6 周时间的长度是价值和投入之间比较合适的比例。

更短的周期会导致需求太过碎片，太频繁的「Planning」会导致项目管理成本太高。

太长的周期会导致 Deadline 太远，团队容易对进度失去足够的警觉和感知，导致项目逾期风险。

原文：Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely.

两周的 Cool Down 是什么？

自由时间，员工可任意支配。

用来消化项目和项目之间的微小需要，如小的优化，调整

用来修复已知的或者觉得值得修复的 bug 们

用来思考和总结。

用来自己做 research，尝试和创新

浪费吗？

我觉得不浪费。任何产品都存在不可描述的缝隙，需要工程师们自驱的去填满；任何项目都不会是完美的，需要持续的雕刻。

极端的情况，我见过连修复 bug 都需要立项审批否则没有资源的企业。

全公司资源 25% 的自由时间，事实上消化了上述这些工作以及「如果这些工作全都纳入正式管理需要耗费的管理成本和损耗」，性价比极高。

这需要管理者有极其深刻的技术理解和魄力，才能让这样的工作组织方式落地实施。