https://www.cnblogs.com/freephp/p/19687302
很多技术人其实都有一种隐隐的焦虑。
每天都很忙。
代码写得不少。
新技术也在狂学。
但过了一段时间回头看，却发现一件奇怪的事情：
自己的价值似乎没有明显提升。
甚至有时候还会出现一种更挫败的感觉：
明明已经很努力了，但好像越来越不重要。
这并不是个例。
在很多团队里，都会出现类似的情况：
- 有些人写了很多代码，却很少被业务部门发现。
- 有些人技术很强，但在项目中始终边缘化。
久而久之，很多技术人会产生一个误解：
是不是技术越做越不值钱了？
其实不是。
很多时候，问题出在另外两个地方：
方向和沟通。
技术人最容易掉进的坑：把技术当目标
很多研发同学都有一个很自然的习惯：
把技术本身当成目标。
比如：
- 今天研究了一个新架构
- 给系统加了一层缓存
- 优化了一个复杂的技术方案
- 引入了一个很酷的工具
从技术视角看，这些事情都很有价值。
但问题是：
业务未必需要这些。
于是就出现了一种很常见的情况：
技术做了很多优化，
系统也变得更复杂了，
但业务结果几乎没有变化。
时间花了。
精力投入了。
但价值并没有明显提升。
于是慢慢就会形成一种错觉：
越努力做技术，越没有价值。
其实问题不在努力。
而在 努力的方向。
技术人还有一个致命问题：不会跨角色沟通
很多技术人其实不太擅长一件事：
和非技术的人沟通。
当我们介绍一个方案时，很容易这样开头：
- 我们这里调整了一下架构
- 引入了一个异步队列
- 做了一些服务解耦
- 优化了一下缓存策略
讲了五分钟，可怕而漫长的五分钟。
对方脑子里只剩下一个问题：
所以最后会发生什么？和我们有什么关系？
技术人习惯讲 How。
但大多数人只关心 What。
于是就出现一种经典场景：
研发讲得很认真。
对方听得很努力。
大家最后点点头。
几天之后才发现：
双方理解的根本不是一回事儿。
很多项目的问题，其实从这里就已经开始了。命运的齿轮开始转动，只是技术人没有发现端倪。
不同的人，需要不同的语言
后来我慢慢意识到一个非常重要的原则：
沟通的目标，不是把话说清楚，而是让对方听明白。
而想做到这一点，必须学会一件事：
面对不同的人，说不同的话。
和 Leader 沟通：讲可行性
Leader 关心的是：
- 这件事能不能做
- 风险大不大
- 需要多久
他们并不需要知道：
- 代码怎么写
- 架构怎么设计
- 用了什么技术方案
技术细节越多，反而越容易模糊重点。
技术解释越多，沟通效率越低。
和老板沟通：讲 ROI
老板关心的世界其实很简单：
ROI、优先级、目标。
他们真正关心的是：
- 这件事值不值得做
- 是不是当前最重要的事情
- 是否推动了业务目标
在 AI 时代，这一点变得更加明显。
以前开发一个系统，可能需要几个月。
现在很多东西（我说的是PoC）几天就能做出来。
于是出现了一个新的问题：
实现成本变小了，但决策成本变大了。
因为人可以更快地做事情，
也可以 更快地走弯路。
所以很多时候，老板更关心的是：
方向对不对。
和产品沟通：讲结果
产品同学关心的其实只有一件事：
最终效果是什么。
他们不关心：
- 技术栈
- 架构设计
- 系统复杂度
他们关心的是：
- 用户看到什么
- 功能体验如何
- 是否符合需求
有时候研发很容易陷入一种情况：
产品想要 B。
研发做出了 C。
C 可能更先进。
C 可能更优雅。
但问题是：
用户并不需要 C。
技术上的正确，不一定是产品上的正确。
技术圈还有一个奇怪现象：黑话越来越多
技术圈还有一个很有意思的趋势：
大家越来越喜欢说黑话。
比如：
- 闭环
- 颗粒度
- 组合拳
- 打通链路
- 赋能业务
听起来很高级。
但很多时候，这些词其实没有提供任何信息。
更有意思的是：
我们在网上经常吐槽这些“大厂黑话”。
但一旦自己进入那个环境，也很容易不知不觉开始这样说话。
所以有时候需要提醒自己一句话：
专业表达，不等于复杂表达。
真正厉害的人，往往能把复杂问题讲得很简单。
一个简单但极其有效的沟通技巧
后来我慢慢养成了一个习惯：
先说结论。
表达顺序变成：
结论 → 方案 → 细节
而不是：
背景 → 技术 → 分析 → 结论
这个小改变，其实非常重要。
因为大多数人最关心的是：
结果是什么。
只要先说结论，对方理解成本会瞬间下降。
最后一个感悟
做技术时间久了会发现一件事：
很多项目失败，并不是因为技术不行。
而是因为：
- 目标理解错了
- 沟通没有对齐
- 方向一开始就偏了
技术能力决定你能走多快。
但沟通能力决定你：
是不是走在正确的方向上。
所以现在我越来越认同一句话：
技术决定下限，沟通决定上限。
最后只记住一句话
大家的时间都很贵。
长话短说。
先说结论。