oldwinter 交付速度
通过消除组织摩擦和建立高强度的交付文化来加速执行。
利用 19 位嘉宾的见解以及 Lenny 的播客和时事通讯中的帖子帮助用户提高发货速度。
如何提供帮助
- 审核现有瓶颈 - 确定项目在当前生命周期中陷入困境的位置，并与高绩效团队进行基准测试。
- 实施速度仪式 - 指导日常站立、演示和单线程团队的设置以保持动力。
- 应用范围框架 - 协助将功能范围缩小到最基本的、有市场价值的，以满足紧迫的期限。
- 建立衡量系统 - 设置核心 4 指标以同时跟踪速度、质量、有效性和影响。
核心原则
无情地削减功能范围
Gaurav Misra: "We take the design and we cut, cut, cut until we can really say that it's going to be useless if we cut anymore. We get that out and people come in."
通过反复切分新功能来保持势头，直到在一周的最后期限内只剩下基本的市场价值。
隔离团队以实现单线程焦点
Geoff Charles: "And I think the recipe for all this is constantly small teams have a single-threaded focus, give them the resources they need to execute big lofty goals, very tight timelines, and then shield them from the chaos that is the rest of the organization."
通过保护小团队免受组织开销和任务切换的影响来保护开发速度。
建立日常问责仪式
Mayur Kamat: "We would pick a owner for something really urgent at the nightly leadership call. Then that owner would be expected to have all hands on deck for however long that problem is every single day and then report the updates on the daily call."
利用领导层的高度参与和每日站立会议，在 24 小时内为高风险项目排除决策障碍。
尽早测试假设的原型
Nan Yu: "What it really looks like is you have some rough time budget for how long you think something's going to take. By the time 10% of it has passed, after week one, you have something that works that tests some kind of key hypothesis internally."
目标是在项目的前 10% 时间内制作出可行的原型，以优先考虑功能学习而不是文档。
不断挑战时间表
Nick Turley: "I just really want to jump to the punchline, "Why can't we do this now?" I always felt like part of my role here is to just set the pace and the resting heartbeat."
询问为什么不能立即完成工作以识别和消除人为瓶颈并设定较高的运营节奏。
筑牢速度技术护栏
Nicole Forsgren: "We want to implement good technical practices like automated testing, good architectural practices so that when you move fast, you are also more stable, right. We want to be thinking about improving the developer experience so that when we are faster, we are also saving time."
实施自动化测试和强大的架构，使团队能够在不牺牲稳定性的情况下频繁部署。
通过兴趣而不是估计来定义项目
Ryan Singer: "We're going to go the other way around and we're going to say, what is the maximum amount of time we're willing to go before we actually finish something? How do we come up with a idea that's going to work in the amount of time that the business is interested in spending?"
在定义范围之前为项目设置固定的时间限制，以避免项目拖累，从而重新获得动力。
模板和框架
- 提高团队速度的 15 种策略（提高团队速度）- 提高团队速度的 15 种具体策略的综合框架，以菜单形式组织，可供选择 1-2 项并在一个月或夸脱的时间内进行试验
- Core 4 入门清单（Core 4 简介：衡量和提高产品速度的最佳方法）- 在组织内采用 Core 4 的分步行动计划。
- 每周一个可销售的功能 (Gaurav Misra) - 一种范围界定和交付方法，每个工程师都必须提供一项可以独立吸引用户使用应用程序的功能，这是通过无情地削减来实现的
- 硬期限与软期限框架（本周#4：激励工程师按时期限、PM 职业阶梯并与高管保持一致）- 一个透明期限类型并战略性地使用每种类型的框架
- 断路器原则 (Ryan Singer) - 如果一个项目没有按计划在其时间范围结束时完成，不要只是延长最后期限 - 停止构建并将其带回塑造模式以了解
- 激励工程师（和任何人）交付的 10 种策略（本周#4：激励工程师按时完成任务、PM 职业阶梯以及与高管保持一致）- PM 可以使用的 10 个激励杠杆的综合框架，以提高团队速度和遵守最后期限
- 诊断为什么工程师错过最后期限（本周#4：激励工程师按时完成任务、PM 职业阶梯并与高管保持一致）- 一个 5 步诊断清单，用于在尝试解决交付缓慢问题之前了解根本原因
- BigCo 现状与初创公司思维框架（如何像初创公司一样发货）- 一个由七部分组成的框架，将 BigCo 的默认行为与初创公司思维替代方案进行对比，以更快地交付产品。七个策略中的每一个都是框架
- 节奏框架 (Patrick Campbell) - 一个用于协调领导层和团队执行速度和产出期望的系统。
有关详细信息的完整列表，请参阅 references/artifacts.md。
帮助用户的问题
- “您团队当前的‘静息心跳’或交付周期节奏是多少？”
- “项目在哪里花费最多的时间：构思、开发，还是 QA 和发布？”
- “如果你必须在一周内发布此功能的一个版本，你会削减什么？”
- “你们的工程师是参与发现阶段还是只是接收需求？”
- “最大的干扰或重复会议拖慢你的团队的速度是什么？”
- “您目前如何衡量速度和质量之间的权衡？”
标记的常见错误
- 高估安全性 - 团队在时间表上添加填充，这通常会导致工作扩展以填补额外的时间，而不是提前交付。
- 单独测量速度 - 在没有质量或影响指标的情况下跟踪速度可能会导致快速交付损坏或低价值的功能。
- 将时间与产出等同 - 成功来自于每分钟高价值成就的密度，而不是记录的总时间。
- 维持严格的年度计划 - 固定的计划周期可能会导致团队错过需要更快执行时钟的市场机会。
深入探讨
有关 19 位嘉宾的全部 35 条见解，请参阅 references/guest-insights.md
相关skill
- 写产品
- AI辅助原型设计
- 与AI代理一起构建
- 产品工具栈