宝软数字 · 产品设计哲学 · 2026-01-21
在科技行业有一种根深蒂固的分工观念：产品经理负责"理解业务和定义需求"，工程师负责"把需求翻译成代码"。这个分工听起来高效而专业——每个人做自己擅长的事情。但在实践中，这种分工制造了一个巨大的信息断层：真正写代码的人，对代码要服务的业务场景知之甚少。工程师拿到一份PRD（产品需求文档），按照文档里的功能描述和交互定义写代码，写完了交给测试，测试通过就上线。至于这个功能在客户的实际工作场景中怎么用、客户为什么需要这个功能、这个功能为客户创造什么商业价值——这些问题可能从未进入过工程师的视野。
在EIOS的团队文化中，我们刻意打破了这个分工壁垒。我们的工程师不仅要写代码，还要理解他们所构建的功能所服务的业务场景。这篇文章将阐述为什么工程师的业务理解力对一个B2B产品的成败如此关键，以及我们如何通过组织和流程设计来培养这种文化。
有一种普遍的刻板印象：工程师的工作是"纯技术性的"——选什么架构、怎么写算法、怎么优化性能。这些确实是技术决策。但在企业级软件的开发中，大量的判断实际上具有深刻的业务含义，只是常常被包装成了技术语言。
举一个具体的例子。EIOS的客户流失预警Agent需要设置一个"高风险客户"的阈值——当某个客户的流失概率高于X%时，系统自动标记并推送预警。这个阈值设多少？从技术角度看，这是一个模型参数的调优问题——可以通过历史数据回测来寻找精确率和召回率的最佳平衡点。但从业务角度看，这是一个完全不同的决策：一个被错误标记为"高风险"的客户，可能会导致销售团队投入不必要的挽回资源；一个被漏掉的真正高风险客户，可能导致数十万的收入损失。前者容忍度更高还是后者？这完全取决于企业的客户价值结构和销售资源情况，而不是一个纯技术问题。
如果工程师只是按照PRD里写的"设置流失预警阈值，默认75%"来实现这个功能，他可能会把阈值做成一个简单的配置参数，用户自己填数字。但如果他理解了背后的业务逻辑，他会意识到：不同类型的企业对"误报"和"漏报"的容忍度完全不同。高客单价、低客户数的B2B企业极度厌恶漏报（丢一个客户损失巨大），低客单价、高客户数的B2C企业对误报的容忍度更低（被误报的客户太多，销售资源无法覆盖）。基于这个理解，工程师会主动设计一个"根据企业的客户价值结构自动推荐阈值"的智能配置——这不仅是一个更好的技术实现，更是一个更贴近业务需求的解决方案。
这就是为什么工程师需要理解业务：代码中充斥着需要业务判断才能做出的技术决策。如果工程师不理解业务，这些决策就会被随意地、默认地、未加思考地做出——而产品经理甚至不会意识到这些决策在代码层面发生了。
在大多数B2B软件公司中，工程师与客户之间的信息传递路径是这样的：客户告诉销售或客户成功他们的需求，销售/客户成功转述给产品经理，产品经理理解消化后写进PRD，工程师读PRD来理解需求。这条链路中经历了至少三次信息转述和解读，每一次转述都伴随着信息的衰减和变形。
我们不认为产品经理是多余的角色——好的产品经理在需求提炼和优先级判断上的价值无可替代。但我们认为，工程师对业务场景的理解不应该完全依赖产品经理的转述。就像你不能通过读影评来完全理解一部电影一样，你不能通过读PRD来完全理解一个客户的真实业务场景。
在EIOS，我们有一个硬性的安排：每个工程师每个季度至少参加两次客户交流——可以是产品评审会（参见第九篇），可以是客户回访，可以是新客户的试用引导。在这些交流中，工程师不是去"展示技术"的，而是去观察和倾听的——看客户怎么使用他们写的代码，听客户表达什么样的困惑和期待，感受客户在真实工作场景中面临的限制和挑战。
这种直接接触的效果是惊人的。一位负责数据接入模块的后端工程师在参加了一次客户回访后，发现客户在对接ERP数据时反复遇到的一个问题——字段映射错误——的根源，不是文档写得不够清楚，而是客户的技术人员对"会计科目"和"财务维度"之间的区别不清楚，而这在他的认知中是一个不需要解释的常识。他回来后不仅优化了数据映射的错误提示信息（从"字段映射错误"变成了"您的XX字段对应的是会计科目，但系统需要的是财务维度数据，两者的区别是……"），还主动写了一份"ERP数据对接常见概念澄清"的文档。这份文档后来成为了我们帮助文档中阅读量最高的内容之一——因为在所有对接类客户的问题中，概念混淆占了一大半。
在中国古代的朝廷里，最怕的是宦官隔绝内外——大臣见不到皇帝，皇帝听不到真实的声音。在现代的软件公司里，最怕的是产品经理隔绝工程师和客户——工程师不知道自己做的东西在真实世界里是怎么被使用的，客户不知道那些"不合理"的限制背后有什么技术上的考量。
工程师理解业务不是锦上添花的文化标签，它会实实在在地提升代码质量。这种提升体现在三个具体的维度上。
第一：架构决策的合理性。当工程师理解了不同业务场景的重要性和优先级后，他在做技术架构决策时就有了清晰的价值判断依据。是优先保证客户分析结果的毫秒级响应，还是优先支持更复杂的多维交叉分析？如果他不了解客户的实际使用场景，他可能会按照自己的技术偏好做出选择。但如果他知道客户的高频使用场景是"早上打开手机看日报，需要在三秒内看到核心数据"，他会毫不犹豫地选择优化响应速度，而对于深度分析的延迟适当放宽。这种取舍不是在技术上能做出的——它需要业务理解。
第二：异常处理的业务语义。代码中的异常处理通常是技术导向的——"数据库连接超时""内存不足""API返回非200"——这些错误信息对用户来说毫无意义。当工程师理解了业务场景后，他能在技术异常和业务含义之间建立映射。如果在一个销售月报生成的关键时刻数据库连接超时，用户看到的不应该是一条"Error 500: Database connection timeout"，而应该是"月度销售报告生成暂时中断，数据已安全保存，系统将在恢复后自动继续。如果需要紧急查看，可以切换到离线缓存模式查看截至XX时间的部分数据。"这种业务化的异常处理，不是在PRD里会写的——它依赖于工程师对"这个功能在客户的什么场景下被使用、中断后的影响是什么"的理解。
第三：功能边界的前瞻性设计。PRD描述的是当前版本需要实现的功能范围。但如果工程师只按照PRD的边界来实现，他可能会做出一个无法平滑扩展的设计。一个简单的例子：如果工程师知道客户分析功能在第一版只需要支持"按客户维度查询"，但未来的版本一定会扩展到"按产品维度""按区域维度""按时间维度"的交叉分析，他在第一版的数据模型设计时就会为这种扩展预留空间。但如果他只读PRD，他可能会做一个刚好满足当前需求的紧耦合设计——六个月后再做扩展时，需要大规模重构。
知道"工程师需要理解业务"是一回事，建立有效的机制来培养这种理解是另一回事。我们在EIOS中使用了以下几种经过验证的实践方法。
客户场景沉浸：前面提到的每季度两次客户交流是底线。对于新加入的工程师，第一个月内必须完成一次实地客户访问——不是远程视频，而是去到客户的实际工作场所，坐在他们旁边，看他们真实的工作流程。为什么要实地？因为很多业务细节只有亲临其境才能感知。一个仓库管理员每天要扫描多少次条码、一个销售经理桌面上同时开着多少个系统——这些细节只有在现场才能看到，而这些细节恰恰是产品设计最宝贵的输入。
逆向演示：在功能开发完成后，不由产品经理来验收，而是由工程师向产品经理和客户代表演示功能的实际操作。工程师需要解释"这个功能如何解决业务问题"，而不是"这个功能在技术上是如何实现的"。这个强制性的换位迫使工程师在开发过程中就已经深度理解了功能的业务意图，否则他根本无法完成演示。我们的一位前端工程师在第一次做逆向演示时，准备了两天——不是因为技术不熟，而是因为他要学习客户的业务术语和决策逻辑，才能用客户听得懂的方式解释功能。这个过程本身就是最好的业务学习。
业务数据接触权：在传统软件公司中，工程师通常没有权限接触生产环境的客户数据——这是出于安全和隐私的考虑。但这种过度保护也隔绝了工程师了解真实业务数据特征的机会。我们在经过严格的匿名化和权限审批后，允许工程师查看脱敏后的客户使用数据——不是去查看某个客户的隐私信息，而是理解真实数据的分布、质量、特征和异常模式。一个工程师如果从来没有见过真实的客户数据是什么样子的，他会假设数据都是干净、完整、格式规范的——而现实是，真实的企业数据充满了缺失、重复、格式不一致和各种边缘情况。
工程师的业务理解力不是在培训课上教出来的，而是在与真实客户、真实数据和真实业务问题的持续接触中逐渐积累的。组织需要做的不是开一门"企业业务速成课"，而是拆除那些阻碍工程师接触业务信息的制度性壁垒。
在一个工程师深度理解业务的组织中，产品经理和工程师之间的关系会发生根本性的变化。不再是"你提需求我实现"的上下级关系，而是围绕同一个业务问题展开的联合思考。
当产品经理提出一个需求方向时，懂业务的工程师不是回答"能做到"或"做不到"——他会说："我理解你提出的这个方向。从技术角度看，还有一个你可能没考虑到的更高效的方式来实现这个目标。我们上个月在和客户的交流中发现，他们其实不需要那么复杂的筛选逻辑，他们最核心的诉求是快速对比。我们可不可以先做最简单的对比视图，把复杂筛选留到下一个版本？"
这种对话和传统模式有质的不同。传统模式中，工程师是被动的执行者——他的价值在于技术实现的质量和速度。在工程师文化模式中，工程师是主动的思考者——他的价值还包括从技术可行性和业务理解度的交叉点上提出更优的解决方案。
这对产品经理的要求也提高了。产品经理不能只是"传达客户需求"，他必须能够与工程师进行深度的业务对话，能够解释一个需求背后的商业逻辑，能够接受工程师基于对业务的理解提出的替代方案。这种对等的关系在很多传统组织中是不存在的，但它一旦建立起来，带来的产品创新力是传统模式无法比拟的。
工程师文化最终指向的是T型人才的培养——在某一技术领域有深度专长（T的竖线），同时具备跨领域的理解能力（T的横线）。这两种能力不是非此即彼的取舍，而是相互增强的协同。
技术深度的重要性不言而喻——如果一个工程师在数据库性能优化上不够深入，他写的分析查询可能会让客户的日报加载十秒以上。但技术深度解决的是"怎么做"的问题，业务理解解决的是"做什么"和"为什么做"的问题。当你同时具备这两种能力时，你不再是按照指令做高效执行的工匠，而是能够自主判断技术资源应该投向哪里才能创造最大业务价值的决策者。
我们对团队中的每一位工程师都有明确的成长期望：在入职后的前六个月，建立对至少一个EIOS核心行业（我们聚焦的十个行业之一）的业务基本理解；在一年内，能够独立完成该行业相关功能的需求解读、方案设计和技术实现；在两年内，能够代表团队与该行业的客户进行深度技术交流，提出超出PRD范围内但契合业务需求的技术方案。
这条路不容易。它要求工程师走出舒适区，去理解那些他们不熟悉的领域——库存管理、财务分析、销售漏斗、供应链优化。但一旦走上这条路，他们的职业发展视野就完全不同了——他们不再是"会写某种语言的程序员"，而是"能用技术解决企业实际问题的工程师"。两者的市场价值不在同一个量级。