-
"正常人在8小时内可以把事情做得很好。加班是管理失败的症状，而不是勤奋的标志。" ——DHH，《重来》（Rework，2010）
-
"好的软件是迭代出来的，不是设计出来的。你不可能在纸上设计出完美产品，然后按照图纸施工。" ——DHH，Basecamp博客，2014
-
"测试不是信仰。测试是工具。如果测试阻碍了你的开发速度，那测试就变成了问题。" ——DHH，Twitter/X，2014-2019期间对TDD文化的批评
-
"我们拒绝的功能比接受的多10倍。大多数功能提案在第一天就被否决了。" ——DHH，Basecamp团队采访，2018
-
"Ruby on Rails不是为了改变世界而创造的。它是因为我厌倦了当时写web应用的痛苦，我想让那种痛苦消失。" ——DHH，Rails创始人访谈，2015
实战模板（3个）
模板一：功能评估检查（足够好模式）
功能提案：[描述]
日期：[今天]
评估人：足够好模式
问题一：这个功能解决的是真实问题吗？
- 有没有用户明确要求？（vs PM/老板觉得用户需要）
- 这个问题有多痛？（1-10）
- 如果不做这个功能，用户现在怎么解决这个问题？
问题二：这个功能需要多少开发资源？
- 预估工时：[X]天
- 机会成本：这X天如果做别的能做什么？
- 复杂度评分（1-5）：[复杂度越高越要谨慎]
问题三：最小可行版本是什么？
- 能不能用更少的代码/功能达到80%的价值？
- 能不能先做一个"看起来像"的版本验证需求？
- 最坏情况：如果没人用，损失是多少？
问题四：增加复杂度评估
| 维度 | 影响 | 严重程度 |
|------|------|---------|
| 代码量增加 | [X]行 | 高/中/低 |
| 维护负担 | [增加什么维护工作] | 高/中/低 |
| 学习成本 | [新人要学多久] | 高/中/低 |
| 依赖复杂度 | [引入了什么依赖] | 高/中/低 |
足够好评估：
□ 做最小版本（1-2天能完成的核心功能）
□ 不做（问题不真实或复杂度太高）
□ 以后再做（等更多信息）
□ 合并到别的功能里（不要单独加功能）
决策：[具体行动]
理由：[为什么这个决策是"足够好"的]
模板二：技术选型评估（固执-灵活模式）
技术选型：[X技术]
日期：[今天]
第一步：形成观点（固执）
- 你对这个技术的立场是什么？（强力支持/强力反对/中立）
- 你的立场基于什么依据？
- 你有没有深入使用过这个技术？
第二步：反向证据
- 最强的反驳证据是什么？
- 有没有使用这个技术失败的案例？
- 什么情况下这个技术不是最佳选择？
- 你有没有可能是错的？[诚实评估]
第三步：评估场景匹配度
| 维度 | X技术 | 当前需求 | 匹配度 |
|------|------|---------|-------|
| 规模 | | | |
| 团队大小 | | | |
| 维护能力 | | | |
| 时间约束 | | | |
第四步：决策树
- 如果X技术失败，最坏情况是什么？能不能承受？
- 有没有"后悔药"？（能否平滑迁移）
- 如果不用X，有没有备选？
固执程度评级：
- 10 = 强烈信念，几乎不可能改变
- 7-9 = 较强信念，会被强力证据说服
- 4-6 = 中等信念，容易被说服改变
- 1-3 = 开放态度，以实际证据为主
最终建议：[做/不做/继续观察]
置信度：[X%]
模板三：发布决策清单（MVP模式）
发布版本：[版本号]
日期：[今天]
发布内容：[简述]
第一步：必要检查
□ 核心功能能正常工作吗？（不是所有功能，是核心）
□ 用户能完成主要任务吗？（端到端走一遍）
□ 崩溃率在可接受范围吗？（<1%？）
□ 性能在可接受范围吗？（首屏<3秒？）
第二步：回滚计划
- 能不能一键回滚？（还是需要手动修复）
- 回滚需要多少时间？
- 什么情况下应该立即回滚？
第三步：灰度策略
- 能不能先发布给5%的用户？
- 有没有监控能看到异常？
- 负责人能第一时间收到告警吗？
第四步：信息同步
- 运营/客服知道新功能了吗？
- 知道如何处理用户问题了吗？
- 有没有准备好FAQ/公告？
第五步：发布后验证
- 发布后1小时内检查什么指标？
- 发布后24小时内检查什么指标？
- 什么指标表示功能成功？
MVP检查结论：
□ 可以发布
□ 需要修复才能发布
□ 需要缩小范围才能发布
发布负责人：[X]
发布时间：[具体时间]
应用场景
场景一：评估要不要加某个功能
当产品经理提议"我们加一个X功能"：
- DHH三问：真问题吗？代价多大？有更简单方案吗？
- 最小版本：能不能用最小的方式验证这个需求？
- 减法原则：加上这个功能的同时，有没有可以移除的功能？
- 拒绝的力量：DHH团队拒绝90%的功能提案——不是每个好主意都要现在做
场景二：技术选型（要不要引入新技术）
当团队讨论要不要用某个新框架/工具：
- 真问题吗：当前技术的痛点是什么？是真实痛点还是"用新技术"的冲动？
- 复杂度评估：引入这个技术的总代价（学习+维护+迁移）值得吗？
- 固执-灵活：你对不用这个技术有多固执？你愿不愿意被实际证据说服？
- DHH版：你们的问题是不够大吗？如果不是微服务规模，用Rails可能更好
场景三：发布节奏和迭代策略
在决定发布节奏时：
- MVP优先：先发布一个能用的最小版本，不要憋大招
- 快速反馈：发布后立即收集用户反馈，用真实数据修正方向
- 接受重写：DHH："我们在每个版本都会重写一部分代码，因为学习本身就是设计"
- 足够好的发布：不是"完美才发布"，而是"够用就发布，然后迭代"
场景四：处理"技术债"
当开发者说"我们需要重构，需要2个月"：
- 真实影响：这个技术债导致的额外工作量是多少？（量化）
- 机会成本：这2个月如果做新功能，业务价值是什么？
- 渐进式：能不能在不重写的情况下逐步改善？
- DHH的回答："大部分技术债是开发者给自己的借口，想重写不是因为真的需要，是因为想用新技术"
反模式
反模式一："完美主义瘫痪"
症状：总觉得代码不够好、架构不够完美、功能不够完整，永远不发布。
后果：竞争对手发布了类似但"不完美"的产品，抢占了市场；团队士气低落，看不到产品上线。
DHH的解药："完美是完成的敌人。发布一个80分的产品，然后迭代到90分，比永远等待100分更有价值。"
反模式二："过度工程"
症状：提前设计"能服务5年"的架构，使用"未来可能需要"的设计，引入"这个很流行"但实际不需要的技术。
后果：系统越来越复杂，没人能完全理解；维护成本指数级上升；新人上手需要几个月。
DHH的解药："如果你的团队只有10个人，不要用微服务。大多数'过度工程'是为了让架构师感觉良好，不是为了解决实际问题。"
反模式三："TDD原教旨主义"
症状：必须100%测试覆盖才敢发布，必须先写测试才写代码，测试失败就不能部署。
后果：开发速度变慢，创新被压制；当测试本身有bug时，整个系统被误判。
DHH的立场：测试是工具，不是信仰。测试的目的是让你有信心快速迭代，不是为了满足"100%覆盖率"这个虚荣指标。
反模式四："功能通胀"
症状：每个版本都在加功能，产品越来越臃肿，但活跃用户不增长；团队忙于维护旧功能，没时间做新功能。
后果：用户体验下降，产品失去焦点；维护成本吞噬开发资源；团队失去方向感。
DHH的解药：加每个功能的同时问：有没有可以移除的功能？坚持"减法原则"——最好的新功能往往是去掉的功能。
反模式五："加班=努力"
症状：项目紧就加班，上线前通宵，节假日赶工，把加班当成解决问题的默认方式。
后果：短期产出增加，长期效率下降； burnout；代码质量下降引入更多bug；创新能力和判断力受损。
DHH的数据：Basecamp团队坚持每周4天工作制，他们的产品质量和产出效率在行业内名列前茅。"正常人在8小时内可以把事情做得很好。"
DHH思维框架的核心：完美是完成的敌人，足够好才是行动的开始。固执但不僵化，迭代优于完美计划，简约设计比功能堆砌更有力量。最重要的决定往往不是你做什么，而是你不做什么。