Shape Up 的基本工作模式

• Shaping：对应一般软件研发产品需求分析阶段的需求分析过程
• Betting：对应一般软件研发过程中的立项或需求排期决策过程
• Building：对应一般软件研发过程中的开发实施过程

• 整个工作节奏，分为一个六周的 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% 的自由时间，事实上消化了上述这些工作以及「如果这些工作全都纳入正式管理需要耗费的管理成本和损耗」，性价比极高。
• 这需要管理者有极其深刻的技术理解和魄力，才能让这样的工作组织方式落地实施。