技术人最大的误区：不是说得不够多，是说了太多
技术人最大的误区：不是说得不够多，是说了太多
电梯里，老板随口问了句：”最近那个项目怎么样了？”
你的大脑瞬间进入高速模式——B+树索引、gRPC迁移、Redis集群——全涌上来了。你开始讲。老板开始点头。电梯开始上升。
30秒后，”叮”。门开了。老板说了句”听起来不错”，走了。
他什么都没听懂。你什么都没传达到。30秒，你讲了一堆正确的废话。
你不是”不会说话”，你是搞混了两件事
被老板打断说”说重点”的时候，大部分程序员的第一反应是：我表达能力差。
不是。
你跟同事讲API细节的时候，逻辑清楚得很，什么入参出参、错误码、并发控制，讲得头头是道。你的表达能力没问题。
问题出在你把”精确描述”和”有效沟通”当成了一回事。
技术讨论里，精确描述是美德。你跟同事说”我们用了B+树的复合索引”，对方秒懂，这叫高效。但你跟老板说同样的话，他脑子里只有一个念头：所以呢？这跟业务有什么关系？
精确描述面向的是同一个知识背景的人。有效沟通面向的是不同知识背景的人。
程序员最常犯的错误，就是对谁都讲同一种话。你把老板当成了你的code reviewer，但他其实是你的用户。你在做技术答辩，他在等一句人话。
用户不关心你的实现，他只关心你的接口。
一个让30%工程师改了项目方向的实验
Amazon内部有一条规矩：每个新项目启动前，必须写一份”新闻稿”。不是给工程师看的技术方案，是给外部客户看的——用普通人能读懂的语言，说清楚这个项目到底在做什么，为谁解决什么问题。
这就是Jeff Bezos著名的”逆向工作法”。
有意思的是结果。当工程师被迫放下术语，用”人话”重新描述自己的工作时，有30%的人修改了项目方向。
不是因为项目本身有问题，而是翻译的过程暴露了他们自己都没发现的逻辑漏洞。
你以为你在做”用户体验优化”，写到一半卡住了——用户体验到底哪里变好了？说不上来。你以为你在做”系统性能提升”，写到”提升了多少”的时候笔停了——你其实只跑过一次压测，还是在自己笔记本上。
说不清楚，往往不是表达的问题，是思考的问题。
如果你不能用一句话说清楚你做的事，大概率你自己也没想清楚。
好了，道理你都懂了。但具体怎么把”说人话”变成一个可操作的技能？这里有一个程序员专属的思维模型——
你的技术汇报，就是一份写反了的API文档
这个类比每个程序员都能秒懂。
一份好的API文档长什么样？第一行写的是endpoint description——这个接口干什么用的。然后是request和response——怎么用。最后才是implementation notes——内部怎么实现的。
为什么？因为看文档的人首先要知道”这东西对我有没有用”，确认有用之后才关心”怎么调用”，至于内部实现，99%的用户根本不看。
现在想想你上次跟老板汇报的顺序：
“我们重构了缓存层（implementation），把Redis集群从3节点扩到了5节点（更多implementation），现在P99延迟从3秒降到了800毫秒（终于到response了），所以用户搜索体验会更好（这才是endpoint description）。”
完全反过来了。
你先讲了implementation notes，再讲了response，最后才提到endpoint description。这就像一份API文档把源码贴在第一页，接口定义藏在附录里——谁会看？老板听了前两层就已经走神了，等你讲到他真正关心的那句话时，他已经在想中午是吃沙县还是麦当劳了。
你的老板想看的是endpoint description，不是implementation notes。
把顺序倒过来，你的汇报立刻就不一样了：”用户搜索更快了，等待时间减少了70%。我们优化了缓存架构，这是技术细节，需要的话我发你文档。”
两句话，讲完了。老板听懂了，你也不累。
PREP框架：30秒，四句话，搞定一切汇报
光知道”结论先行”还不够，你需要一个足够简单的框架，简单到能贴在显示器旁边。
PREP——四个字母，四句话：
P - Point（结论先行）：我们把查询速度提升了60%。
R - Reason（给个原因）：因为旧的索引策略在大数据量下跑不动了。
E - Example（摆个证据）：上周高峰期，P99延迟从3秒降到了800毫秒。
P - Point（再敲一遍）：用户再也不用盯着加载动画发呆了。
全部讲完，不超过30秒。
这不是什么演讲秘籍，这是信息压缩算法。你把一个可能讲20分钟的技术方案，压缩成了四句话的摘要。老板接收到了关键信息，如果他感兴趣，他会追问细节；如果他不追问，说明这四句话已经够了。
你可能会担心：四句话太短了，老板会不会觉得我没干活？
这恰恰暴露了一个认知误区——你把”汇报时长”等同于”工作量”了。
想想你平时写代码。一个初级工程师写了500行解决一个问题，一个高级工程师重构后只剩80行，功能一模一样。谁的水平高？答案显而易见。汇报也是同一个道理：信息密度比信息量更重要。
那些汇报半小时的人，老板心里真正在想的不是”他干了好多活”，而是”他到底想说什么？为什么我听了这么久还是没抓到重点？”
代码越短越高级，汇报越短越清楚。
一个你今天就能开始的练习
别等下次在电梯里碰到老板才临时抱佛脚。有一个练习成本几乎为零：
每周五下班前，花5分钟，用PREP写下”本周我做的最重要的一件事”。
四句话。发给自己的微信”文件传输助手”就行。
举个例子。你这周修了一个线上bug，过程堪比侦探小说——翻了三天日志、怀疑过网络抖动、甩锅给过运维，最后定位到是上游服务的超时设置问题，改了配置还做了灰度验证。如果按你的本能汇报，能讲四十分钟。用PREP写出来是这样的：
- P：修复了影响3万用户的搜索超时问题
- R：上游服务超时阈值设置不合理，高峰期请求堆积
- E：修复后搜索成功率从92%回升到99.7%
- P：用户投诉量当天降了80%
四句话。你老板看了立刻知道：这活有价值、解决了、效果好。
第一周你会觉得别扭，因为你的本能是先讲排查过程。第二周开始顺手。一个月后你会发现一个意外收获——不只是表达变好了，你开始能分辨”我做了什么”和”我做的事有什么价值”的区别了。
这两件事听起来像一回事，其实完全不同。很多人每天忙得要死，周五一回顾，发现自己说不出”做了什么有价值的事”。PREP不只是汇报工具，它是一面镜子——照出你的时间到底花在了哪里。
下次在电梯里遇到老板
不要讲B+树索引。
不要讲gRPC迁移。
不要讲Redis集群。
就说一句话：”我们把用户等待时间从3秒降到了不到1秒。”
然后看着他的眼睛亮起来。
技术人最大的误区，不是”说得不够多”。是说了太多对方不需要的东西。
好的沟通不是把你知道的都倒出来，是只把对方需要的递过去。
就像好的API——接口简洁，文档清晰，实现藏在后面。用的人觉得轻巧，写的人知道背后有多少个深夜。
毕竟，能把复杂的事说简单，才是最难的技术活。