要说项目里什么词最让人心里发毛，我觉着“TBD”这三个字母肯定能排前三。以前我刚入行那会儿，对这玩意儿压根儿没当回事。领导或者同事说哪个模块功能“TBD”，我就觉得，待定嘛以后再定呗，反正现在还没到时候。每次看到文档里、需求里一堆TBD，我也就稀里糊涂地过去了，心想着到时候自然会有人搞定。
本站为89游戏官网游戏攻略分站，89游戏每日更新热门游戏，下载请前往主站地址:www.gm89.icu
可就是这种稀里糊涂的态度，有一次可把我折腾惨了，差点儿把整个项目都给拖黄了。也就是从那时候起，我才真的把TBD这玩意儿给琢磨透了，搞明白它背后藏着多大的雷。
第一次栽在TBD上的坑
那是前几年，我刚开始负责一个不大不小的前端项目。当时需求文档下来，好多地方都写着TBD。比如，某个第三方接口的对接方式TBD，用户支付流程里的某些细节TBD，甚至连报表里的一些具体数据口径也是TBD。我当时觉得，这些都不是我前端的活儿，后端或者产品会去定的，我就先按着确定的部分往下开发。反正我把我的部分先干完了，剩下的自然会水到渠成。
我带着我的小团队，闷头就开干。那阵子也真是拼，经常加班到半夜，总算把大部分界面和交互都给撸出来了。我们都觉得，这项目按时上线那是板上钉钉的事儿。结果，等到了要联调测试的时候，问题一下子就全冒出来了。
我们信心满满地去对接第三方接口，结果发现接口文档还没出，后端同事告诉我：“这个还在跟人家谈，具体怎么调还没定，TBD。”当时我心里就咯噔一下，这不是开玩笑嘛我们前端的逻辑都写好了，就等着接口数据进来，现在接口不定，我咋测？
这还只是个开始。更要命的是支付流程，产品经理之前说会定一个标准流程，我们也按照预期的流程先做了UI。结果临到头，产品那边突然说，因为供应商技术能力有限，之前的支付方案走不通，要换个新的，整个流程都要大改。你知道那种感觉吗？就像你辛辛苦苦盖了一半的楼，突然有人告诉你地基不行，要推倒重来。我当时真是想骂娘的心都有了。
还有报表数据口径那事儿，因为“TBD”，后来定下来的口径跟我们前端展示的逻辑完全对不上，又是一大堆改动。那段时间，我们整个团队真是焦头烂额。白天改改改，晚上还要开会扯皮，讨论这些TBD到底是谁的锅。产品怪技术没提前评估，技术怪产品需求不定，销售怪产品跟不上市场。大家互相推诿，没人想承担责任，项目进度眼看着就一天天往后拖。
项目还是延期了差不多一个月才勉强上线。那一个月，我们每天都像打仗一样，身心俱疲。很多同事都熬出了黑眼圈，我也因为天天沟通协调这些破事儿，嗓子都哑了好几次。奖金扣了一大截不说，还背上了项目延期的黑锅，那滋味儿真是别提多难受了。
TBD，压根儿就不是什么“待定”，是“待解决”！
从那次之后，我就彻底明白了，TBD这三个字，绝对不能再稀里糊涂地放过去了。它压根儿就不是什么“待定”，而是“待解决”，而且通常是“待紧急解决”的问题！它就像个定时炸弹，你现在不处理，到时候肯定会炸得你措手不及。
每次看到TBD，我就条件反射地警惕起来。我开始强迫自己和团队，对项目里的每一个TBD都要刨根问底，把它当成一个实实在在的问题去对待。
- 第一步，挖出来。我要求团队在项目初期，就把所有标注TBD的地方全部列出来，一个都不能漏。不管它是在需求文档里，还是在技术方案里，或者某个邮件里提了一句，都要像侦探一样把它找出来，记录下来。
- 第二步，定人。每个TBD，都必须明确一个负责人。你不能说“待定”，然后就没人管了。必须有个人负责去推动这件事的解决，无论是去沟通接口方，还是去协调产品和业务方。没有负责人，这个TBD就永远是空气，永远不会落地。
- 第三步，定时。光有负责人还不够，还要给他一个解决的期限。不能让TBD无限期地TBD下去。比如，这个第三方接口文档，最晚下周三必须出来；支付流程的最终方案，这周五必须敲定。有了时间限制，负责人才能有压力，才能真正去推动。
- 第四步，拆解。如果一个TBD太大了，不容易在短时间内解决，我就要求负责人把它拆分成几个小任务。比如，“第三方接口对接TBD”可以拆成“联系第三方拿到联系人”、“与第三方初步沟通接口规范”、“拿到接口文档初稿”、“确认接口文档终稿”等等。这样，每个小任务都有明确的进展，TBD的状态也从“未知”变成了“进行中”。
- 第五步，跟踪。我把所有TBD都单独拉出来，放到我们的项目看板上，或者每周例会上单独拿出来讨论。每个TBD的进展、当前状态、遇到的困难、预计解决时间，都要清清楚楚。一旦发现哪个TBD迟迟没有进展，我会立刻跟进，跟负责人一起想办法，甚至直接上报给项目经理或者更高层的领导。
- 第六步，预案。对于一些关键的、风险高的TBD，我还会要求团队准备一个备用方案。万一它真的在规定时间内解决不了，我们还有没有Plan B？有没有其他的替代方案？比如，如果第三方接口实在卡壳，我们能不能先用一套模拟数据跑起来，确保项目主流程不受影响？
刚开始推这套方法的时候，团队里也有一些不理解的声音，觉得我太较真了，一个小小的TBD有必要这么大动干戈吗？但慢慢地，大家发现，当我们把这些TBD都提前挖出来、解决掉之后，项目进行得真的顺畅多了。联调的时候没那么多意外了，测试的时候也少了很多反复修改，整个团队的节奏都稳了下来。
我发现，当你对每一个TBD都保持高度警惕，并且有计划地去推动它解决的时候，你就是在主动规避项目的风险，而不是等风险爆发了再去救火。现在我的项目再也不大会出现因为“待定”而延期的情况了，因为我们把所有的“待定”都变成了“待解决且有计划解决”的问题。这种掌控感，真的让人踏实很多。