“做T法则”，英文可译为 Do What Works（做有效的事）。它并非一套复杂理论体系，而是一种高度实用主义的执行哲学——在明确目标的前提下，以最小成本快速实现可验证成果，并在过程中持续修正方向。
在互联网产品开发、系统建设、甚至日常项目管理中，我们常被“预期管理”绑架：老板要看到PPT里完整的架构图，客户要提前确认所有交互细节，测试团队要求所有用例写完才开始测试……
这种“预期驱动”导致大量时间浪费在“预设场景”上，而真正的问题往往在真实用户行为中才浮现。
真正的高手不回避错误，而是提前为错误预留空间。做T法则将“错误”视为系统学习的必要输入，而非需要掩盖的失败。
心理学研究发现：人在“零容错”环境中会本能地回避风险，导致决策保守、反应迟滞。而容错环境能激发团队试错勇气，反而提升整体鲁棒性。
Gemba（现场）是日语“现场”的罗马音，指问题真实发生的地方。做T法则强调——所有假设必须在真实场景中验证，而非会议室脑补。
做T法则拒绝“一次性交付”，主张“增量式验证”。每次迭代只解决一个核心卡点，而非追求功能完备。
传统方案：先完成所有接口开发 → 集成测试 → UAT验收 → 上线（原计划8周）
做T方案：
▪ 第1周：用Mock服务搭建前端+核心开户接口
▪ 第2周：邀请10名员工内测，发现“短信验证码”延迟卡点
▪ 第3周：紧急优化短信通道，上线MVP版本
▪ 第4周：收集真实用户数据，迭代优化交互路径
结果：用户开户转化率提升32%，上线后0严重故障
卡点分析：原方案预设“支持所有图表类型”，导致需求膨胀
做T调整：
▪ 第1天：聚焦核心需求——“销售趋势折线图”
▪ 第3天：交付可操作的Demo（含数据导入+图表渲染）
▪ 第5天：邀请3个客户现场试用，记录操作卡顿点
▪ 第7天：仅修复3个高频卡点，发布V1.0
结果：客户满意度92%，后续迭代均基于真实行为数据
传统困境：各部门数据标准不一，反复开会协调
做T破局：
▪ 第1天：选定1个高频场景（“出生证明办理”）
▪ 第2天：用Excel模板模拟数据流转（绕过系统）
▪ 第3天：邀请窗口人员现场操作，记录操作步骤
▪ 第5天：基于真实流程反推系统改造点
结果：3周内完成最小闭环，被纳入省级试点
有本质区别！做T强调“轻量级规划+快速验证”，而非完全放弃规划。例如：
▪ 规划阶段只需明确：
——核心目标（用户要解决什么问题？）
——验证指标（如何判断成功？）
——风险底线（哪些事绝对不能做？）
其余细节在迭代中补全。
不会！关键在“恰到好处的质量”：
▪ 核心路径必须高可用（如支付流程）
▪ 边缘功能可适当降级（如推荐模块）
▪ 通过“技术债看板”动态管理，避免债务堆积
可采用“分层交付”策略：
▪ 向上：用1页PPT展示目标+验证指标+风险预案
▪ 向下：用原型+数据埋点证明可行性
案例：某银行项目用“Excel模拟流程图”替代PRD，客户当场签字确认。
用数据说话：
▪ 对比A/B方案：方案A（6周完美版）vs 方案B（2周MVP版）
▪ 预测市场窗口期：若晚2周上线，可能损失20%份额
话术：“我们不是放弃质量，而是把资源从‘预设完美’转向‘真实验证’”
不适用场景：
▪ 法规强监管领域（如航天控制、医疗植入设备）
▪ 无验证条件的长期项目（如基础科研）
适用场景：
▪ 互联网产品、营销活动、内部工具等快速迭代领域
推荐组合：
▪ 原型设计：Figma + Flinto
▪ 数据监控：Mixpanel / GrowingIO
▪ 故障追踪：Sentry + ELK
▪ 协作管理：Notion（轻量级看板）
建立“验证闭环”机制：
① 每次迭代前明确：
——验证假设是什么？
——成功标准是什么？（量化指标）
——失败后如何退出？
② 每次迭代后复盘：
——数据是否达标？
——用户行为是否改变？
——是否需要调整方向？
相同点：
▪ 都强调快速反馈、小步迭代
不同点：
▪ 敏捷重流程（Scrum/Kanban），做T重目标
▪ 敏捷可能陷入“为迭代而迭代”，做T始终聚焦“是否解决问题”
采用“双轨制”：
▪ 业务轨：用做T快速验证短期价值
▪ 技术轨：用架构图+技术路线图保障长期演进
关键：每季度用1周时间做“架构健康度扫描”，避免技术债堆积
步走：
① 选一个小项目（如内部工具），强制自己用3天做出MVP
② 每天记录“卡点日志”，分析真实问题 vs 假设问题
③ 与团队约定“验证指标”，拒绝模糊评价
工具推荐：《精益创业》《用户故事地图》