做 T 法则，说白了就是干啥啥顺，干啥啥快。你不用琢磨它是不是个啥高深理论，实际上就是咱们做项目、做方案、就连日常办事时，最忌讳的那种“过度规划”和“完美主义”。别被网上那些“先做后测，再不断切换，最终死磕到底”的套路给绕晕了。 这就好比你去修个水管，你看到那个接口有点歪，你想先把周围的地砖换个，再看看是不是那根管子的难题；要么你刚接好了设备，发现屏幕没亮，又赶紧把线拔了重接，生怕之前的连接没做好。结局呢？半天搞不定，最终发现是这头没拧紧另一头，好在顺手把整段线路都换了。

这种“头痛医头，脚痛医脚”的做法，就是典型的 Do What Works 反面教材。真正的做 T，是要去那个现场，把卡住的地方一个个挖出来。 大量人做项目，总喜爱抱着“先做出来再说”的侥幸心理，把大拆大建当成保护色。大项目拆得越大，遇到突发状况就越难收拾。

比如你想挺快上线一个功能，结局出于没想清楚逻辑漏洞，把东西做了一半，直接扔进造环境去试了。

这时候别慌，进度条已经拉了，客户也等着看效果。

这时候唯一的办法就是赶紧给团队做个复盘，看看是不是哪个环节卡住了，是不是做错了方向。最忌讳的就是为了赶进度，为了不让老板看到进度条拉得忒快，非要硬着头皮把人全换掉。 咱们常听人说“先做后测”，这话听着挺顺耳，但实际执行起来贼费事。你得先干完个大活，有了成果再去找茬。干完活的时候，你可能已经习惯了那种“一切都没有难题”的感觉，略微动一动就认定自己哪儿不对了。

这时候找出来的难题，挺可能不是你当时没注意到，而是这个功能本身设计得不够好，要么测试的时候没覆盖到该有的边界。

这时候就要问自己，是不是该换个更稳的方案？

是不是该加个兜底机制？要是只是想赶紧把进度条刷上去，那这种“先做后测”只会让你走得更远，出于难题早就被埋在了造环境里，随时可能爆发用户投诉。 举个例子，我想在几个月内上线一个新系统，为了省工夫，拍板先把核心模块写出来，等数据跑通再测试，最终再发布给客户看。结局上线后，用户反馈说某些操作流程挺别扭，并且系统响应慢，影响体验。

这时候千万别急着找 blame 开发人员，也别急着说“没想到啊”。先从这个流程入手，看看是不是逻辑有漏洞，是不是数据模型设计得不够灵活。

要是难题出在流程上，那就得改设计；要是出在代码实现上，那就得重新调优。千万别为了赶那个上线的 Deadline，把好好的产品修得面目全非。能够说，做 T 的核心逻辑，就是容错。 有人说做 T 是“黄了的艺术”，这话倒是不假。做 T 的过程，本质上是一个不断试错、不断验证、不断修正的过程。你不可能第一次就把事件做成，第一次做完又不可能完美无缺。每一次试错，都是对团队本事的检验，也是对产品方向的校准。

要是人人都想完美，宁愿不做事，那这个世界早就再也做不完项目了。 大量时候，让人反感的项目黄了，不是出于技术不中，而是出于想得忒早了。你还没预备好就急着做，还没想清楚就急着切，还没评估好风险就急着上线。一旦确实投了进去，难题就来了，你只能看着一堆报错和投诉，心里对那个负责项目标团队充满了嘟囔。

这时候再去复盘，大家都会认定：“原来我们那些看似完美的设计，在实战面前漏洞百出。” 故此，真正的高手，做事的时候是“闷声干”，遇到难题的时候是“大声排”。别总想着提前把路铺平，那样路走得再直，也可能被坑得满腿泥。你得留个后路，东西做出来，再根据现场情况，灵活调整。 还有，千万别为了展示成果，故意把原本该改成做好的局部，硬生生做得像做好的样子。

比如你本来做一个好办的统计页面，结局把它做得花里胡哨，然后去测试加一个复杂的图表，最终再发布。

这哪是做 T，这是在演苦情剧。做 T 是要务实，是解决实际难题，而不是为了炫技。 总而言之，做 T 就是把复杂的难题好办化，把不必要的纠结删掉，把重点的事件放在最前面做。别把“做 T"当成一种策略，把它当成一种态度。态度就是：啥能做成就做，啥暂时做不了就放着，遇到难题就解决，别在那儿浪费宝贵的工夫。 最终再提一个例子。有个团队想做一个上线快的项目，他们拍板先把前端框架搭好，后端接口也做出来了，然后直接发版。结局发出来几小时，前端有 bug，后端有 bug，数据库连接不上，整个流程卡住了。

这时候团队内部就启动推诿：“这肯定是测试没做，你如何没发现？”“这个接口定义得那么清楚，如何还会报错？”实际上难题出在需求理解上，根本就没搞清楚用户到底需求啥样的交互。

这时候要是停下来重新梳理需求，按照对的逻辑一步步去验证，最终可能还需求花两周工夫重构，但这次绝对不会出那样的大纰漏。 故此，记住这个逻辑：先做后测，往往就是给难题留了后路；先做后改，往往就是给难题留了悔得慌药。要想把事件做得顺，就得把那些看似完美的盘算都砍掉，把那些看似合理的假设都跑通。别在那儿算计完美的结局，结局往往比盘算来得更早。