shipping-velocity

交付速度

通过消除组织摩擦、建立高强度的交付文化，加快执行速度。

借鉴 Lenny's Podcast 和 Newsletter 中 19 位嘉宾及文章的见解，帮助用户提升交付速度。

如何提供帮助

1. 审查现有瓶颈 - 找出当前项目生命周期中容易卡住的环节，并与高绩效团队进行对照。
2. 落实提升速度的惯例 - 指导建立每日站会、演示和单线程团队，保持推进势头。
3. 运用范围界定框架 - 协助缩减功能范围，只保留最关键、最具市场价值的内容，以赶上紧迫的期限。
4. 建立衡量体系 - 设置 Core 4 指标，同时跟踪速度、质量、效能和影响。

核心原则

毫不留情地缩减功能范围

Gaurav Misra：“我们会拿出设计，然后不断删减，直到可以确定再删就毫无用处。我们会先把它推出去，然后人们就会加入进来。”

通过反复拆分新功能，直到只剩下能在一周期限内交付的核心市场价值，保持推进势头。

隔离团队，专注单线程任务

Geoff Charles：“我认为这一切的诀窍在于，持续让小团队专注于单线程任务，为他们提供实现远大目标所需的资源，设定非常紧迫的时间线，然后让他们远离组织其他部分的混乱。”

让小团队免受组织开销和任务切换的干扰，保护开发速度。

建立每日问责惯例

Mayur Kamat：“我们会在晚间领导层会议上为紧急事务指定负责人。之后，无论问题需要多久解决，这位负责人每天都要确保所有人全力投入，并在每日会议上汇报进展。”

对于高风险项目，通过领导层深度参与和每日站会，在 24 小时内扫清决策障碍。

尽早制作原型，验证假设

Nan Yu：“实际做法是，先粗略估算你认为某件事需要多长时间。在这段时间过去 10% 时，也就是第一周结束时，你就应该有一个能运行的东西，用来在内部验证某个关键假设。”

力争在项目总时间的前 10% 内产出可用原型，优先通过实践学习，而非编写文档。

持续质疑时间线

Nick Turley：“我就是很想直接问关键问题：‘为什么我们不能现在就做？’我一直觉得，我在这里的职责之一就是设定节奏和日常运转的脉搏。”

追问为什么工作不能立即完成，找出并消除人为设置的瓶颈，建立高效的运营节奏。

建立保障速度的技术防线

Nicole Forsgren：“我们希望落实良好的技术实践，比如自动化测试和优秀的架构实践，这样快速行动时也能保持稳定，对吧？我们还要考虑如何改善开发者体验，这样速度更快的同时也能节省时间。”

落实自动化测试和稳健的架构，让团队能够频繁部署而不牺牲稳定性。

根据时间预算而非估算定义项目

Ryan Singer：“我们要反过来做，先问：我们最多愿意花多长时间，直到真正完成某件事？我们怎样才能想出一个在业务愿意投入的时间内可行的点子？”

先为项目设定固定时限，再定义范围，以避免项目拖延，重获推进势头。

模板与框架

• 提高团队速度的 15 种策略（提升团队速度）——一套全面的框架，包含 15 种提高团队速度的具体策略，整理为一份清单，供团队选择 1-2 种并在一个月或季度内尝试
• Core 4 入门清单（介绍 Core 4：衡量和提升产品速度的最佳方式）——逐步行动计划，帮助组织采用 Core 4。
• 每周交付一个有市场价值的功能（Gaurav Misra）——一种范围界定与交付方法，要求每位工程师交付一个能够独立吸引用户使用应用的功能，方法是果断删减
• 硬性与软性截止日期框架（本周 #4：激励工程师按时交付、产品经理职业阶梯以及与高管保持一致）——一种明确不同截止日期类型并策略性地运用每种类型的框架
• 断路器原则（Ryan Singer）——如果项目无法在时间盒结束时按计划完成，不要只是一味延长截止日期，而应停止构建并将其带回塑造阶段，以便了解
• 激励工程师（以及所有人）交付的 10 种方法（本周 #4：激励工程师按时交付、产品经理职业阶梯以及与高管保持一致）——一套全面的框架，列出产品经理可用来提升团队速度和按时交付率的 10 种激励手段
• 诊断工程师错过截止日期的原因（本周 #4：激励工程师按时交付、产品经理职业阶梯以及与高管保持一致）——一份包含 5 个步骤的诊断清单，帮助在尝试解决交付缓慢的问题前找出根本原因
• 大公司现状与创业公司思维框架（像创业公司一样交付）——一套包含七个部分的框架，对比大公司的默认做法与创业公司思维下更快交付产品的替代方案。七种策略中的每一种都以框架
• Tempo 框架（Patrick Campbell）——一套帮助领导层和团队就执行速度与产出预期达成一致的系统。

完整列表及详情请参阅 references/artifacts.md。

可向用户提出的问题

• “你们团队当前的交付周期或节奏是怎样的？”
• “项目的时间主要花在哪里：构思、开发，还是 QA 和发布？”
• “如果必须在一周内交付这个功能的一个版本，你会删掉什么？”
• “工程师是否参与了探索阶段，还是只负责接收需求？”
• “拖慢团队的最大干扰因素或重复会议是什么？”
• “你们目前如何衡量速度与质量之间的权衡？”

需要指出的常见错误

• 为了保险而过度估算——团队会在时间安排中增加缓冲，这往往会导致工作膨胀以填满额外时间，而不是提前交付。
• 孤立地衡量速度——如果只跟踪速度，而不衡量质量或影响，可能会导致团队快速交付有缺陷或价值低的功能。
• 将工时等同于产出——成功取决于每分钟完成的高价值成果，而不是记录的总工时。
• 坚持僵化的年度规划——固定的规划周期可能会让团队错过需要更快执行节奏的市场机会。

深入了解

19 位嘉宾分享的全部 35 条精选见解，请参阅 references/guest-insights.md

相关技能

• 编写产品需求文档
• AI 辅助原型设计
• 使用 AI Agent 构建
• 产品工具栈