为什么IT技术人员往往不站在业务角度思考问题？

chouheiwa

发布于 2026-05-06 21:21:07

780

作为一个写了近10年代码的程序员，我太熟悉这句话了——"不要太技术，一切要从业务价值出发！"

说实话，每次听到这句话，我内心都会翻个白眼。不是因为这句话不对，而是因为说这话的人，往往根本不知道技术人员每天在干什么。

今天我想站在技术人员的角度，好好聊聊这个问题。不是为了甩锅，而是希望双方都能理解对方的处境。毕竟，技术和业务从来都不是对立的，只是我们说着不同的"语言"。

先说结论：这是一个结构性问题，不是技术人员的"原罪"

我见过太多技术人员被贴上"不懂业务"的标签，但真正深入了解后你会发现，大约60%-70%的问题根本不在技术人员身上，而在于组织架构、沟通机制和考核制度。

这就好比你让一个只能看到局部代码的开发者去优化整体架构——他不是不想优化，而是压根看不到全貌。

技术人员真的不考虑业务吗？

这是我最想澄清的一个误解。

每一个有经验的技术人员，其实每天都在做"业务决策"，只是这些决策的表达方式和业务方完全不同。你以为我们只是在写代码？不，我们是在用代码表达对业务的理解。

举个例子。当我选择用什么技术栈、怎么设计数据库结构、API接口怎么定义的时候，我必须考虑：这个业务未来会不会扩展？用户量增长后能不能扛住？如果业务逻辑变了，这套架构改起来成本高不高？

这些全是业务问题，只是我们用技术语言在回答。

问题出在哪？出在我们不会"翻译"。当业务方问我们"这个功能什么时候能上线"的时候，我们的第一反应往往是"技术上怎么实现"，而不是"这个功能能给业务带来什么价值"。我们太习惯用技术语言思考了，以至于忘了对方听不懂。

那些被忽视的"隐形业务价值"

我想替所有技术人员说一句：我们创造的很多价值，是"隐形"的。

什么叫隐形？就是系统正常运行的时候，没人觉得这是技术的功劳；但一旦出了问题，第一个被骂的就是技术。这就是技术人员的宿命——做得越好，越不被看见。

让我给你算几笔账：

技术债务的代价远超想象。 哈佛商学院有个研究，说每1单位的技术债务，在3年内可能产生7到12倍的连带成本。什么概念？就是今天你为了赶进度写的那些"临时方案"，三年后可能要花十倍的代价去还。我亲眼见过一个电商系统，当年为了应对大促临时硬编码了很多逻辑，两年后系统扩容时，不得不重构38个耦合模块，额外开发成本是当初的5倍。

系统稳定性直接等于钱。 亚马逊Prime Day的一次故障，损失了9900万美元。这不是夸张，这是真实的数字。技术人员7×24小时保障系统稳定，这份工作的价值怎么算？没法算，因为"系统正常"不是一个可以量化的KPI。

所以当业务方抱怨"技术人员不考虑业务价值"的时候，我真的很想问一句：系统稳定、数据安全、架构可扩展，这些算不算业务价值？

为什么会形成这种误解？深层原因分析

说完了辩护，我们来客观分析一下，为什么会形成这种认知差距。

第一，教育背景塑造的思维模式不同。

计算机教育强调的是逻辑、确定性、结构化。程序世界里，1就是1，0就是0，没有"差不多"这回事。但业务世界充满了模糊性和变化——用户需求会变，市场环境会变，老板的想法也会变。

我之前是学化学工程的，后来转行做程序员。我发现化学实验讲究"控制变量"，编程调试也是一样的道理——你得一个个排除可能性，才能找到问题根源。这种思维方式在技术领域非常有效，但放到业务沟通中，可能就显得"太较真"了。

业务方说"这个功能体验不太好"，技术人员的第一反应是"哪里不好？能具体描述一下吗？有复现步骤吗？"——这不是抬杠，这是我们的本能反应。但在业务方看来，你这就是在"踢皮球"。

第二，组织架构的"部门墙"问题。

很多公司的组织架构是这样的：业务方提需求给产品经理，产品经理写PRD给技术，技术照着PRD开发。这个流程看起来很清晰，但问题是——技术人员只接收到了"解决方案"，而不是"原始问题"。

产品经理说"做一个梯子"，技术就去做梯子。但没人问过"为什么要梯子"？也许真正的问题是房间太暗，需要的是一盏灯，而不是爬上去换灯泡的梯子。

技术人员被动成了"执行者"，而不是"问题解决者"。你让一个只看得到需求文档的人去理解业务全貌，这本身就是个不可能完成的任务。

第三，KPI导向的错位。

说句扎心的话：技术人员的晋升和考核，跟业务理解能力关系不大。

我们被考核的是什么？项目交付时间、代码质量、Bug率、系统性能。这些指标很重要，但它们跟用户增长、转化率、营收没有直接挂钩。你说技术人员不关心业务？那是因为公司的考核体系根本没有激励他们去关心。

更扎心的是，技术能力是可移植的——你在A公司写的代码，换到B公司还是那套技术。但业务理解呢？你在A公司积累的业务知识，换个行业可能就没用了。从个人职业发展的角度，优先提升技术能力是理性的选择。

说个我自己的例子。

我在公司上班的时候，确实更专注在技术上。为什么？因为公司付我工资，本质上买的就是我的技术能力。我的职责是把需求高质量地实现出来，而不是去质疑需求本身是否合理。业务分析有产品经理做，市场调研有运营做，我只需要把我这一环做好就行。这是分工，不是我"不懂业务"。

但我也接私活。接私活的时候，情况就完全不同了。

客户找到我，跟我说"我想做一个XXX"，我不可能直接开干。我得先问清楚：你为什么要做这个？你的用户是谁？他们的核心需求是什么？你期望达到什么效果？你的预算和时间限制是什么？——这些全是业务问题。如果我不搞清楚这些，做出来的东西大概率不是客户想要的，最后返工的是我自己。

所以你看，同一个人，在公司里"只专注技术"，接私活时却能把业务分析、需求梳理、技术实现一肩挑。这说明什么？说明技术人员不是不会考虑业务，而是在公司的分工体系下，没有被要求、也没有被激励去考虑。

环境决定行为。你给技术人员一个需要他全盘负责的场景，他自然就会去考虑业务；你把他放在一个只需要执行的位置上，他自然就只关注执行。这不是能力问题，是机制问题。

那业务方就没有问题吗？

当然有。

我见过太多需求文档，写的是"用户希望有更好的体验"。什么叫更好的体验？具体哪里不好？期望达到什么效果？一概没有。然后开发完了，业务方说"不是我想要的"。请问，你想要什么你自己说清楚了吗？

还有一种情况更常见：业务方只关心"快速上线"，完全不理解技术债务的概念。今天为了赶进度欠下的技术债，明天是要还的，而且是加倍还。但很多业务方不在乎，他们只看眼前的KPI。

说句可能得罪人的话：产品经理真正的问题往往不是不懂技术，而是搞不清楚需求。比起不懂技术，不懂需求才是更致命的问题。

解决方案：技术人员可以怎么做

说了这么多，不能光吐槽不给解法。作为技术人员，我们确实可以主动做一些改变。

学会用"业务语言"翻译技术成果。

不要说"模型AUC值从0.75提升到0.82"，这话业务方听不懂。要说"优化后，100个用户里有85个能看到他们感兴趣的内容，之前只有70个。预计人均浏览时长增加2分钟，转化率提升5%到8%"。

同样的成果，换一种表达方式，效果完全不同。技术指标要翻译成用户价值或者商业价值，这是一项需要刻意练习的技能。

接到需求时，多问三个问题。

第一，这个需求要解决什么业务问题？第二，现状是什么，期望达到什么效果？第三，有没有更好的技术方案可以达到同样的目标？

很多时候，当你问清楚这三个问题，你会发现原始需求可能不是最优解。这时候你提出的替代方案，就是在展示你的业务思维。

按职业阶段调整技术与业务的投入比例。

刚入行的前两年，专注编码能力没问题，技术投入可以占90%。但工作三到五年后，你应该开始理解业务上下游，技术和业务的投入比例可以调整到50%对50%。五年以上，如果你想往更高的方向发展，业务思考的比重应该超过技术。

这不是说技术不重要了，而是说你的竞争力要从"会写代码"变成"能用技术解决业务问题"。

解决方案：业务方和管理者可以怎么做

技术人员要改变，但这不是单方面的事情。业务方和管理者也需要做出调整。

需求沟通要包含完整的上下文。

一个合格的需求应该包含这些信息：业务背景是什么，要解决什么问题，期望达到什么可衡量的效果，优先级如何，必须做的和可选的边界在哪里，时间和资源有什么约束。

让技术人员理解"为什么要做这件事"，比单纯下达任务有效得多。当技术人员从心理上认同一件事的价值，他们的投入程度是完全不同的。

尊重技术工作的特殊性。

程序员有个"心流"状态，下午3点到晚上是效率最高的时段。如果不是特别紧急的事情，尽量不要在这个时间段打断他们。把沟通和会议集中安排，让技术人员有完整的时间块去写代码。

还有一点很多人不理解：研发时间不等于完成时间。估算的开发时间是纯编码时间，但实际还需要联调、测试、改Bug。如果你按照研发估算的时间去倒排上线日期，大概率是要延期的。

理解技术债务的存在。

技术债务就像信用卡透支——今天花得爽，明天要还本金加利息。业务方在催进度的时候，要理解技术人员为什么会"抵抗"一些临时方案。不是他们不愿意配合，是他们知道这笔债迟早要还。

组织层面的系统性改进

最后说说组织层面可以做的事情。

建立跨职能团队。

把产品、研发、运营放在一个团队里，针对特定的业务目标协作。让技术人员参加业务方的周会，了解业务的全貌。定期组织轮岗或联合培训，打破部门之间的信息壁垒。

调整考核体系。

技术人员的考核里增加业务贡献维度——不只是看你写了多少代码，还要看你对业务指标产生了什么影响。同时，业务人员的考核也可以增加技术协作维度——需求文档的完整性、对技术约束的理解程度。

当考核体系把技术和业务绑在一起，自然就会倒逼双方互相理解。

我有一个更进一步的构想。

既然前面说了，我接私活的时候会主动分析业务，那能不能把这种模式引入公司内部？

具体来说，就是让技术人员直接参与需求的源头分析。不是等产品经理写好PRD再交给开发，而是在业务方提出原始诉求的时候，就让技术人员参与进来。技术人员不只是"接需求"，而是和产品、业务一起"挖需求"。

其实这件事，很多公司已经在做了，只不过参与的是架构师，而不是普通开发。我们公司也是这样，架构师会参与前期的需求分析和方案评审，从技术可行性的角度给出建议。这确实能在早期发现一些坑——比如某个需求实现成本极高，或者和现有系统架构冲突，架构师在这个阶段提出来，整个方案可能就会调整。

但问题是，这种参与只停留在架构师层面。到了具体开发的时候，普通程序员拿到的还是一份"已经定好的"需求文档，他们依然是执行者的角色。架构师理解了业务全貌，但一线开发并没有。

我的构想是，能不能把这种参与再往下延伸一层？让核心开发也能在需求分析阶段就介入，哪怕只是旁听，也能让他们理解"为什么要做这个"。这样在实现的时候，他们就不只是机械地照着PRD写代码，而是真正理解自己在解决什么问题。

当然，这个构想在现实中会遇到阻力。公司愿意让架构师花时间参与需求分析，是因为架构师人少、决策权重大；但如果让所有开发都参与，老板可能觉得这是在浪费人力成本。所以目前来看，这只是一个理想化的方向。但我始终认为，如果能让更多技术人员从"执行者"变成"参与者"，很多所谓的"技术不懂业务"的问题，根本就不会出现。