那些年，程序员背过的“不懂业务”的黑锅
深夜十一点，办公室还亮着几盏灯。开发小李正在紧急修复线上bug，产品经理发来消息：“这个功能能不能加个快捷入口？很简单的，就几行代码吧？”
小李盯着屏幕上复杂的调用链路，深吸一口气，默默关掉了聊天窗口。
第二天晨会，领导语重心长：“技术人员要多从业务角度思考啊。”小李想说些什么，最终还是把话咽了回去。
这样的场景，是不是很熟悉？
为什么技术人员总被说“不懂业务”？
“你们技术太技术了！” “能不能不要老想着技术实现，多想想业务价值？”这些话如同紧箍咒，常常萦绕在IT人的耳边。
但事实真的是技术人员不愿意思考业务吗？
我曾经问过一个十年开发经验的老程序员，他苦笑：“我们想的业务，和他们说的业务，好像不是一回事。”
技术人员眼中的业务可能是：这个功能能承载多少并发？数据一致性如何保证？系统扩展性怎样？
而业务人员眼中的业务却是：这个按钮放哪里用户更爱点？这个流程能不能再少两步？这个功能下周能上线吗？
看，大家明明都在说“业务”，却在两个平行宇宙里对话。
被误解的“技术思维”：不是不懂，是维度不同
我的朋友张工是个架构师，他有个经典比喻：
“业务人员看到的是冰山上面的部分——功能好不好用、界面美不美观、流程顺不顺畅。而我们技术人员，必须看到冰山下的九成——数据结构怎么设计、接口怎么划分、缓存怎么设置、异常怎么处理。”
当产品经理兴奋地说“我们要做个社交功能”时，产品想的是用户互动、增长指标；而程序员脑子里已经蹦出了：时间线如何实现？好友关系怎么存？消息推送怎么保证不丢？并发高了怎么办？
这不是不关心业务，而是关心得太深、太底层，以至于水面上的部分，反而被忽略了。
那些无法跨越的“沟通鸿沟”
曾经参加过一个需求评审会，让我印象深刻。
业务方：“这个需求很简单，就是用户点一下按钮，然后出现个动画，然后跳转到新页面。”
技术负责人：“这个‘点一下’是在什么场景下？用户网络不好怎么办？动画要兼容哪些机型？跳转前需不需要预加载？数据异常怎么处理？......”
业务方（逐渐失去耐心）：“不用想这么复杂，其他APP都有这个功能，照做就行。”
技术方：“那如果......”
会议陷入僵局。
这种对话每天都在无数公司上演。不是谁对谁错，而是思维方式天然存在差异。业务追求的是快速验证、快速试错；技术追求的是稳定可靠、可维护可扩展。
就像两个人一起旅行，一个说“咱们去玩得开心点”，另一个却开始查天气、规划路线、准备药箱、买保险。你能说第二个人不想玩得开心吗？他只是用另一种方式确保“开心”能够实现。
被忽视的“技术债”：今天少想一步，明天加班到吐
小王曾经在一家创业公司，早期为了快速上线，很多功能都是“先跑起来再说”。一年后，系统已经成了一团乱麻，改一处崩三处。新来的产品经理提出一个“简单优化”，技术评估需要两周。
“这么简单的功能要两周？你们技术是不是在偷懒？”
小王想解释这是历史遗留问题，但看着产品经理怀疑的眼神，最终只说了一句：“我们会尽快。”
技术人员不是不愿意快速响应业务需求，而是见过太多“今天图快，明天重写”的血泪史。那些被业务方视为“技术细节”的东西，往往是系统能否健康存活的关键。
绩效考核的“隐形导向”
在大多数公司，技术人员的KPI是什么？系统稳定性、bug数、项目按时交付率...... 很少有公司把“业务增长贡献”直接写入技术人员的考核指标。
不是技术人员不想关心业务，而是在现有考核体系下，保证系统稳定运行已经是巨大的挑战。一个因为追求业务创新而导致的线上事故，远比一个保守但稳定的技术决策后果更严重。
这就像要求消防员在救火的同时，还要考虑如何美化火灾现场——不是不能，而是首要任务不同。
打破壁垒：其实我们可以做得更好
那么，技术人员真的无法改变这种局面吗？当然不是。多年的观察让我发现，那些既能深入技术又能理解业务的技术人，往往成长最快。
第一，学会“翻译”：把技术语言转化为业务价值
不要说“我们用了Redis缓存，QPS提升到5000”，而要说“这个优化可以让同时在线用户增加三倍，页面加载时间减少70%”。
第二，多问“为什么”：深入理解需求背后的真实意图
当接到一个需求时，不要只问“要做什么”，多问“为什么要做”、“希望达到什么效果”、“用户会怎么使用”。这不仅能帮你做出更合适的实现方案，还能发现潜在问题。
第三，偶尔“走出机房”：体验真实的业务场景
如果你做电商系统，试着去客服部门听听电话；如果你做OA系统，去观察员工实际办公流程。真实场景带来的冲击，比一百份需求文档都强烈。
第四，建立“技术同理心”：主动沟通技术决策的业务影响
当因为技术原因需要调整需求时，不要只说“做不了”，而是解释“如果这样做，会导致什么后果；如果换种方式，能达到类似效果，且更稳定/更快/更省钱”。
业务方，也请听听技术的声音
写到这里，我也想对业务侧的同事说几句心里话。
当技术人员说“这个需求有风险”时，他们不是推卸责任，而是真的看到了你看不到的风险。
当技术人员要求更多时间时，他们不是效率低下，而是在为系统的长期健康争取空间。
最好的产品，永远是业务愿景与技术现实的美妙平衡。
写在最后：我们都是一条船上的人
说到底，技术和业务从来不是对立关系。技术是引擎，业务是方向盘，少了哪个，车都开不动。
那些最成功的互联网产品背后，无一不是技术与业务深度融合的结果。技术人员懂业务，能做出更接地气的方案；业务人员懂技术，能提出更可行的需求。
下次当你又想说出“你们技术太技术了”时，不妨换个说法：
“这个需求，从业务角度我希望达到……，从技术角度你看怎么实现更合理？”
相信我，你会收到意想不到的积极回应。
因为最终，我们都在为同一件事情努力——做出牛逼的产品。
技术人员不是不关心业务，而是用技术人的方式关心着业务。只是这种方式，需要一点翻译，需要一点理解，也需要一点耐心。
毕竟，代码最终要为业务服务，而业务，也需要代码的坚实支撑。
这世界从来不是非此即彼，而是在差异中寻找最优解的艺术。
