我曾经是个"不靠谱"的人。
有一次，领导让我做一个数据导出功能。我闷头做完了，上线那天才发现——客户要导出的数据量是百万级，内存直接爆掉。
领导问我："你怎么没问清楚数据量？"
我说："你也没说要导出多少数据啊。"
领导看了我一眼，没说话。但那个眼神我记到现在。
后来我才明白：靠谱不是"你说什么我做什么"，而是"确保事情被正确完成"。
对结果负责 = 让对方有掌控感
事前问清楚、事中有反馈、事后有确认，而不是丢一个结果出来，让对方惊喜或惊吓。
事前
- 问前因后果，搞清楚需求的背景
如果不问清楚，只是听从对方的语言，那大概率要有雷。
案例：
产品说"加个导出功能"，你闷头做了。到上线那天才发现，客户要导出的数据量是百万级，内存直接爆掉。
如果当时多问一句："大概多少数据？导出的格式有要求吗？什么时候要？"就不会踩这个雷。
2. 预期管理：开始前明确"什么叫做好"
别等到交付才发现双方理解不一致。
案例：
客户说"系统要快"。你优化了接口响应时间，从200ms降到50ms，自觉很快了。结果客户不满意——他说的"快"是页面秒开，你优化的只是接口。
"快"太模糊了。要问清楚：是接口响应时间？是页面加载时间？是首屏可交互时间？具体指标是多少？
事中
- 有阻碍，提前说
别等到截止日期到了，才说搞不定。
案例：
周二接到任务，周五交付。周三你发现有个技术难点搞不定，但你没说，想着自己再试试。到了周五，你跟客户说"还要两天"，客户炸了——他周三已经把牛吹出去了。
如果周三就告知客户："有个技术点需要额外时间，能不能周五先交付核心功能，其余周一补上？"客户虽然也会不爽，但至少有准备。
- 提供选项：遇到问题时别说"做不了"
而是给出A/B方案让对方选。
案例：
客户要加一个实时推送功能，你说"做不了，架构不支持"。客户很不爽。
换一种说法："做实时推送有两种方案：A是引入WebSocket，改动较大但体验好；B是用轮询，改动小但有延迟。我们可以根据预算和时间选一个。"客户感觉自己有选择权，问题从"做不做"变成了"选哪个"。
3. 主动反馈进度：别等别人问
定期同步进展，让人心里有数。
案例：
客户周三问"做得怎么样了"，你说"还行，周五能交"。客户心里没底，周四又问，周五又问。你觉得烦，客户也焦虑。
主动一点的画风："目前完成了70%，核心功能都好了，还有一些边界情况在调。预计周四下午可以内部测一把，周五上午正式交付。有问题我会第一时间同步。"
客户一看进度可控，就不追着问了。
- 不找借口：出了问题先想"怎么办"
不是"谁谁谁的错"。
案例：
上线出了bug，客户投诉。你说："这是测试没测到"或者"环境配置有问题"。客户不在乎是谁的错，他只在乎什么时候能好。
靠谱的说法是："我们正在定位，预计2小时内出修复版本。先把影响范围控制住，您那边先别急，有进展我马上同步。"
5. 闭环确认：做完不是结束
要明确问一句"这样行吗？"
案例：
你把功能做完了，在群里发了一句"已上线"。然后就不管了。客户第二天说"这个交互不对啊，不是这样的"。
靠谱的做法是：上线后主动问一句："X总，功能已经发布了，您方便的时候看一下，有问题随时说。"确认对方满意了，这事才算闭环。
事后
- 记录和复盘：做完后记一笔
哪些沟通容易踩雷，下次避免。
案例：
每次项目做完，花10分钟记一下：哪些需求理解有偏差？哪些问题反馈晚了？哪些承诺超预期了？
积累几年，你就有一套"防雷手册"。新项目来了，先翻一眼，上次踩过的坑，这次就别踩了。
最后
靠谱不是能力多强，而是让人放心。
把"意外"降到最低，把"掌控感"给到对方。做到这一点，你就是个靠谱的人。
