讲故事也要商务范儿：用业务术语传达工程工作

当我与工程师交流时，我最常听到的一种抱怨是，他们觉得自己必须不断开发各种特性，而他们所使用的软件和工具却变得更加脆弱、不一致、令人沮丧，让他们越来越难完成自己的工作。

作为工程师，我们会无奈地摇头，想知道为什么我们的业务伙伴（产品负责人、高级领导层、销售等等）没有看到那些对我们来说显而易见的问题，并且对他们不断将工程驱动的工作（例如技术债务、解决技术风险或增强系统以开辟新机遇）的优先级排在更多特性开发工作之后的做法感到沮丧。

同时，我们的业务伙伴（与你共事且专注于业务的人们，如产品负责人、高级经理，甚至是客户）可能会觉得工程师总是在抱怨他们的软件质量和工作环境，并且总是想努力让技术变得更好。就像其他行当的工匠一样，他们希望手头的工具趁手又闪亮。但从业务伙伴的角度来看，业务上的诸多限制不允许我们花几个小时来给汽车打蜡和抛光，只为了让车看起来闪闪发光；有时我们要的只是到达目的地而已。

我们可以尝试让业务伙伴像工程师一样思考，但重点在于要记得我们花了多少时间来学习自己的手艺——它是非常专业和复杂的。而且一般来说，在你真正构建了一段时间软件之前，你真的说不清楚什么才是可行的，什么又是不可行的。

因此，也许更好的方法是让我们的工程师努力“用商务范儿说话”——用业务术语传达工程工作的重要性。

在这篇文章中，我将为你提供如何做到这一点的一些想法。我将展示如何将工程工作构建为一个故事，包括清楚地提出一个问题、提供一个解决方案，并向他们展示一条成功之路，以解决他们的问题并避免失败。以这种方式介绍你的案例后，这些工程问题被解决的几率会大大增加，同时你也会成为业务方更好的合作伙伴。

让你的业务伙伴成为故事的主角

我们需要了解什么事情对我们的业务伙伴很重要。他们面临什么问题，成功对他们来说是什么样子？他们可能不太关心“这个 API 真的很复杂”或“这个系统是一个相互依赖的网络"这样的事情。

纵观人类历史，故事一直被用来吸引关注和教育受众。当你讲一个故事时，它会吸引受众的注意力，带他们进入一段旅程。一个故事的结构是一种强大而有效的方式，可以用来将你的信息传递给你的业务伙伴。具体来说，你可以考虑讲一个故事，让你的听众成为故事的主人公。一本帮助你从利益相关者（在这里是指你的业务伙伴）的角度构建故事的好书是 Donald Miller 写的《建立故事品牌》。在这本书中，Miller 提供了一个框架，帮助你思考谁是主角（你的业务伙伴）、他们的问题是什么，以及你作为一个向导将如何帮助他们解决这个问题以避免失败并带领他们走向成功，从而构建一个故事。

这个过程中的一个重要步骤是弄清楚问题应该是什么。你需要把你的业务伙伴作为主角放在故事的中心，而把你自己作为向导。如果你不清楚他们面临哪些问题，可以安排一次会议，问问他们。仅仅是迈出这一步也会改善你与他们的关系，让他们感到自己被倾听和理解。

最好从三个层面考虑问题：外部问题，内部（或个人）问题，以及道德问题。

他们试图解决的外部问题几乎总是与为组织提供价值有关：带来更多收入、降低成本、避免客户流失、增加机遇。

他们经常面临的内部问题往往是他们希望避免在同行和领导面前出丑；他们希望被看作是一位可靠地提供优秀结果并能成功驾驭挑战性场景的人才。

道德问题比较有意思。这个问题是指事情的发展方式是不对的。例如，“天啊，仅仅交付一个特性不应该这么难！”或者“建立一个新的客户应该是简单快捷；为什么会这么难？”这是一种对事情发展方向感到不对头的潜在挫折感。

这一切与技术工作有什么关系？好吧，一旦我们清楚了我们的业务伙伴在面对哪些困难，我们就可以超越工程师的角度，重新从你的产品负责人或业务领导的角度来表述我们的问题。这里有一些例子：

• 与其说“这个代码库让我很难完成各种任务”，不如说“只要一个特性需要对这个代码进行修改，它都需要两倍的时间来交付，而且往往会有更多质量问题。”

• 与其说“每次我想做一个变更，都要得到架构委员会和质量工程师的批准”，不如说“交付一个特性所需的总时间的四分之三是用来等待批准的。如果我们能精简这些流程，我们就能大大减少构建一个特性所需的总时间。”

沟通风险

有一件事可能特别具有挑战性，那就是工程驱动的工作所要解决的问题往往不是现存的，但在未来可能会成为问题。这时，作为一个工程师，你的一项独有义务就是尝试用业务术语来与业务伙伴沟通风险情况，从而让相关工作得到优先处理。

例如，也许你正在使用一个单体系统，所有工程师都在用同一个代码库，特别是他们可以直接访问所有的底层数据库表。到目前为止，这个系统一直运作良好，但你的组织刚刚获得了一笔资金，计划在六个月内将团队数量翻倍。你已经看到了团队试图协调变更时会遇到的挑战，以及当某人对数据库模式做出一项变更而意外地破坏了其他人的工作时会发生的失败。你如何帮助他们理解当前系统所带来的风险，以及现在就投资修复它的重要性？

回想一下哪些东西对你的业务伙伴来说是重要的。在这种情况下，你的业务伙伴可能是一位高级产品经理或高级经理。当他们的团队数量增加一倍时，高层也会期望生产力能提高一倍，但在目前的架构下这是不可能做到的。

因此，你可能会与他们开个会，在会上你将带领他们走过一个变更的流程，并向他们展示在团队数量增加一倍的情况下会变成什么样子。如果你在过去有这方面的经验，就讲讲你的经验故事。帮助他们理解如果现在不投资重构可能出现的结果。如果可以的话，你甚至可以参考一些关于这个问题的研究。

但要把重点放在对业务的影响上——我们将无法实现今年的目标，因为即使你的团队规模扩大了一倍，特性交付率也只会增长一点。

用数据说话

只要你能做到，就把数据带到讨论中。这些数据应该是与业务成果相关的指标。诸如错误率、交付一个特性所需的平均时间、员工满意度和客户满意度等指标都可以用上。

来自Accelerate的一组指标就很好用，可以拿出来。你可能需要展示诸如准备时间、部署频率、平均恢复时间和变更失败率等指标是如何直接预测改善的业务成果的。

但要尽可能多地使用与你的合作伙伴最关心的问题和疑虑有关的指标。例如，假设你看到工程师们正在努力理解一个特定的组件——它很复杂，测试结果很差，文档很糟糕。这对业务有什么影响？可能因为测试和调试的周期很长，所以需要更长的时间来交付一个特性，即使交付完成了也可能会有更多错误。所以，也许你可以看看构建一个用到这个组件的特性与不需要这个组件的特性所需的时间差异，看看你是否能体现出明显的差别。或者看看针对这个组件和其他组件的支持问题和错误报告的数量，看看你是否能看到明显区别。

顺便说一句，如果你看不出有什么不同，那么这可能实际上表明它并不像你认为的那样是一个大问题。对这种可能性持开放态度总是好事情。如果你不能说服你自己这个问题真的影响了业务，那么你就没什么可能说服你的业务伙伴。

你也可以用这些指标来衡量你将提出的项目的进展并预测其成功率。比如说：“我们目前平均每月交付两个特性，每个特性从开始到完成需要 4-6 周。其中大部分时间是在反复测试和调试。我们还看到针对这个组件的错误和支持案例的数量明显增多。一旦我们对这个组件进行重构，我们估计将能够把交付一个特性所需的时间减少一半，而且应该会看到错误和支持案例也至少减少一半。”

成为他们的向导并给他们一个方案

仅仅帮助你的业务伙伴理解问题是不够的。你需要扮演一个向导的角色，向他们展示你心中的计划，即如何解决这个问题、避免失败并取得巨大成功。

通常，这涉及到一套高层次的渐进式可交付成果的组合、对时间和人员的要求，以及衡量成功的方法（例如使用我上面提到的数据指标）。

比如说你可以用一种分阶段的方法。“让我们做一个试点，让几位工程师从这个旧代码库中重构出一个特定的工作流程。然后我们可以评估它对这些关键指标的影响，我们可以决定是否要投入更多时间。”

尽早和经常提供价值真的很重要。这可以让你的利益相关者获得信心，让他们感到这是正确的方向，并更愿意继续投资。不要让整个团队为你的方案忙活三个月才开始交付什么成果。

也许这实际上是不值得的

从你的业务伙伴的角度努力讲述故事可以带来的一个好处是，你可能会意识到修复某件事情所需的努力并不是真的那么物有所值——业务价值并不真正存在。我们不得不承认，有时候工程师确实喜欢给事情镀金；做这样的分析可以帮助我们获得信心，相信这项工作是必要的——或者让我们意识到自己也许应该接受轻微的不愉快状况，然后继续前进。

例如，也许有一个组件是很久以前写的，当时用的风格和方法让它难以阅读，也许难以修改。但它每年只被修改一到两次，而且依赖它的特性并不是业务的关键。在这种情况下，也许不值得投入大量的时间来升级和重构它。如果它真的困扰着你，你也许可以在周末花一点时间来清理它。但是，当有其他更优先的工作要做时，可能不值得花时间或精力去做它。

把它放在同一个积压中

我曾在一些组织中工作过，在这些组织中工程驱动的工作是用工程部门拥有的能力来处理的。这对于正在进行的簿记工作（如升级库）可能是有用的，但对于一次性项目，我发现如果你不努力把它的优先级放在与特性相同的积压中，就会发生一些事情：

• 工程师们没有遵循正确的纪律来确保他们所做的是为企业带来最大价值的工作；

• 我们的业务伙伴并不清楚我们正在做什么事情，如果迫不得已，这些资源会被拉到其他事情上；

• 因为这不是可见积压的一部分，所以当你的业务伙伴被问及这些工程师在做什么时，他们并不能真正回答问题。

因此我发现，确保每个人都只有一个积压的工作，并遵循同样的纪律来证明工程工作的合理性和优先级，就像证明特性工作的合理性和优先级一样是非常有用的。

实践出真知

最初几次尝试时可能会很艰难，你可能会觉得自己没有清楚地传达工程工作的重要性。但要坚持下去——倾听业务伙伴的反对意见和担忧，试着更好地理解他们的目标和需求，并深入思考工程工作如何影响这些目标。

我的经验是自己在这方面做得越来越好，并且当我这样做的时候有一些事情发生了：

• 我成为业务方利益相关者的一名更值得信赖的伙伴；

• 我实际上能够更好地将我们工程工作的价值传达给工程团队；

• 它提高了我作为一名员工的价值，因为我更有能力在工程和业务之间架起桥梁。

胜任工作

我总是喜欢做工程工作——提出设计，让它发挥作用，与团队合作将其投入生产，并看到客户使用它。

但我也发现，当我和利益相关者清楚地知道我所做的事情是有价值的时候，我就会更加满意——即使这些事情是修复我们的构建工具、把数据库迁移到一个新的模型，或者写一堆自动化测试。最让人激动的就是看到关键的业务指标得到改善，并从业务方那里得到郑重的感谢——这是因为你能够向他们展示一些重要的东西并说服他们投资，而如果没有你的话他们永远都意识不到。

作者介绍：

David Van Couvering 从 1988 年开始在 Sybase 工作，将测试从 C 语言转换到 COBOL；之后他一直在设计、构建和交付企业软件。他的经历包括：在 Sybase 设计了第一批 Java 应用服务器之一，在一系列遭遇重大失败的初创公司工作，在 Sun Microsystems 设计了一个集群的 Java EE 应用服务器，在一家医疗保健初创公司将一个 Ruby 单体迁移到 Java 微服务，并使用领域驱动设计来推动 WeWork 的核心空间管理系统的重构。他目前在 eBay 的首席架构师手下工作，负责一项全公司范围内的计划，以提高 eBay 的软件交付表现。David 还为那些需要帮助扩展和优化其软件架构和软件交付实践的组织提供顾问服务。

原文链接：

Talking Like a Suit - Communicating the Importance of Engineering Work in Business Terms