We're sunsetting PodQuest on 2025-07-28. Thank you for your support!
Export Podcast Subscriptions
cover of episode Seven Shipping Principles

Seven Shipping Principles

2025/1/8
logo of podcast REWORK

REWORK

AI Deep Dive AI Insights AI Chapters Transcript
People
D
David Heinemeier Hansson
J
Jason Fried
K
Kimberly Rhodes
Topics
Jason Fried: 37signals 的软件发布流程注重软件质量,而非速度。即使一个功能大部分完成,如果存在一些小问题,也不会发布。发布的产品必须是一个完整且高质量的,而不是仅仅达到最小可行产品(MVP)的标准。在设计软件时,应该关注用户需求,而不是仅仅关注技术实现。应该考虑多种方案,选择最优方案。软件设计应该简洁明了,避免出现隐藏规则或特殊情况。当遇到困难时,应该重新审视问题的本质,先简化问题,再优化解决方案。 David Heinemeier Hansson: 37signals 只发布高质量的软件,宁可推迟发布也不愿发布质量不高的软件。'好'的软件标准很高,这意味着有时需要拒绝发布未达到标准的软件。'好'的软件是一个整体的评价,而不是部分功能的简单叠加。团队成员应该有权阻止不符合质量标准的软件发布。不应追求100%的发布率,部分工作达不到标准是正常的。发布的软件必须是高质量的,而不是仅仅达到最小可行产品(MVP)的标准。单纯的测试覆盖率数据并不能衡量软件的质量和可靠性。测试的严格程度应该与问题的严重程度相匹配。对于不同严重程度的问题,应该采取不同的测试策略和标准。信心水平应该与问题的关键程度成正比。信心水平是一个主观判断,需要根据经验和上下文进行调整。对软件质量的信心水平应该与法律判决中的证据标准类似,根据问题的严重程度进行调整。大部分软件开发工作属于中等关键程度,不需要过于严格的测试。对于关键性系统(如计费系统),需要更高的测试标准和更严格的审查。避免对所有工作都采用相同的测试标准,应该根据问题的关键程度调整测试策略。对简单问题采用复杂的测试方法是浪费资源。信心是一个主观判断,需要经验的积累。初级程序员倾向于过度测试,这会影响开发效率。程序员需要根据问题的关键程度来调整测试策略,在效率和质量之间取得平衡。在测试和效率之间找到平衡点,避免过度测试或测试不足。在保证质量的前提下,适当的冒险是必要的。 开发人员应该对发布后的问题负责。如果开发人员对发布后的问题不负责,他们会变得不那么谨慎,导致软件质量下降。开发人员需要从实际反馈中学习,才能提高软件质量。最终目标是发布无缺陷的软件,而不是仅仅满足测试指标。在发布后留出时间来修复bug和处理客户反馈,这有助于提高软件质量。在开发周期中留出冷却时间,以便开发人员处理发布后的问题。如果开发周期安排过于紧凑,会导致开发人员没有时间处理发布后的问题。开发人员没有时间处理发布后的问题,会影响团队合作和效率。开发人员应该参与到软件的整个生命周期中,才能更好地学习和改进。开发人员应该对自己的工作负责,并从实际反馈中学习。避免过度追求完美,而忽略了核心功能的实现。完美是好的敌人,应该追求'好'而不是'完美'。应该优先考虑核心功能的实现,而不是过度追求细节的完美。应该优先考虑核心概念的清晰度,而不是实现的复杂程度。在有限的时间内,应该优先考虑核心概念的清晰度。一个巧妙的实现可能掩盖了核心概念的缺陷。不要为了赶进度而降低软件质量标准。不要将'比没有好'作为软件发布的标准。应该对自己的工作充满信心,并以更高的标准来要求自己。根据自身能力和资源来决定软件的发布范围和时间。

Deep Dive

Key Insights

What is the first shipping principle of 37signals, and why is it significant?

The first shipping principle is 'We only ship good work.' It is significant because it sets a high bar for quality, ensuring that the software is not just 'okay' but genuinely good. This principle allows the team to say no to shipping subpar work, even if significant time has been invested. It emphasizes the importance of delivering software that the team is proud of, rather than rushing to meet deadlines with mediocre results.

Why does 37signals critique the concept of MVPs (Minimum Viable Products)?

37signals critiques MVPs because they believe the 'minimally viable' bar is too low. Testing incomplete or half-baked ideas often yields poor feedback, which doesn't help in evaluating the true potential of a feature. Instead, they advocate for shipping complete, well-thought-out ideas, even if they are smaller in scope, to ensure the feedback received is meaningful and the product is of high quality.

How does 37signals determine when they are confident enough to ship a product?

Confidence in shipping is determined by the criticality of the problem being solved. For less critical issues, a lower burden of proof is acceptable, while for high-stakes features (e.g., billing systems), rigorous testing and reviews are required. The team avoids applying the same level of rigor to all tasks, instead calibrating their confidence based on the potential impact of bugs or failures.

What does the principle 'We own the issues after we ship' mean at 37signals?

This principle means that the person or team responsible for a feature must also handle any issues that arise after it is shipped. They monitor error trackers, respond to customer feedback, and fix problems. This approach ensures accountability and provides developers with real-world feedback, helping them improve their work and avoid isolating themselves from the consequences of their decisions.

Why does 37signals avoid shipping features that 'aren't right'?

Shipping features that 'aren't right' can lead to hidden rules, awkward user experiences, and unsatisfactory explanations for edge cases. 37signals prioritizes solving the root problem effectively, even if it means stepping back and rethinking the approach. They avoid shipping incomplete or flawed solutions, ensuring that the final product aligns with their high standards and provides a seamless user experience.

What does 'We ship to our appetite' mean in the context of 37signals' shipping principles?

'We ship to our appetite' means that 37signals avoids overextending themselves by pursuing ideas beyond their capacity or interest. They focus on delivering good work within their six-week cycles, avoiding 'gold plating' or over-decorating features. This principle ensures that they prioritize clear, impactful ideas over perfection, maintaining a sustainable pace and avoiding burnout.

How does 37signals balance the trade-off between perfection and practicality in their shipping process?

37signals balances this trade-off by focusing on delivering good work rather than perfect work. They prioritize clear, impactful ideas and avoid over-engineering solutions. For example, if a feature is technically clever but based on a flawed premise, they will step back and rethink the approach. This ensures that their solutions are both practical and aligned with their high standards.

Shownotes Transcript

How does 37signals decide when software is ready to ship? In this episode of The REWORK Podcast, 37signals’ co-founders Jason Fried and David Heinemeier Hansson discuss the company's Seven Shipping Principles). They dive into when a product update is good enough to ship and the importance of making updates to solvethe trade-offs between serious flaws and functional imperfections, emphasize the importance of fully realized product ideas, and underscore the need 

Key Takeaways:

  • 00:11 – We only ship good work.
  • 03:36 – The problem with MVPs
  • **04:41 **– We ship when we're confident.
  • 10:08 – We own the issues after we ship.
  • 13:41 – We don’t ship if it isn’t right.
  • 17:11 –  Making sure your solution tackles a real problem
  • 20:00 – We ship to our appetite.

Links and Resources:

  • “Seven Shipping Principles”) from the 37signals website
  • Books by 37signals)
  • 30-day free trial of HEY)
  • Sign up for a 30-day free trial at Basecamp.com)
  • HEY World | HEY)
  • The REWORK podcast)
  • The Rework Podcast on YouTube)
  • The 37signals Dev Blog)
  • 37signals on YouTube)
  • @37signals on X)