Compass 的工程团队遇到了一个问题。我们的功能在技术上是完善的，但缺少一些东西—真正的客户之爱。我们编写代码的效率很高，但我们解决了正确的问题了吗？
作为 Atlassian 负责 Compass 的高级工程经理，我多年来一直在努力应对这一挑战。我和我的团队负责构建工具，以帮助开发团队大规模管理软件组件和资源。刚加入公司时，我注意到许多工程组织都会面临的一种模式：我们擅长交付功能，但有时会在交付价值方面没能成功。
我亲眼目睹了工程文化如何决定产品的成败。在 Atlassian，我们不仅为软件团队打造工具，还花大把的时间来解决客户每天面临的挑战。这使我们在转变工程文化方面拥有独特的视角，这也是我特别热衷于分享我们所学知识的原因。
传统的工程脱节
让我们来谈谈一个假设的产品团队，它的故事可能听起来很熟悉。
Tina 是一名高级开发人员，以卓越的技术而闻名。虽然她的代码无可挑剔，但她发现自己陷入了一个熟悉的循环：接收需求、编写代码、部署功能。Tina 承认：“我在孤立地编写代码。我不知道我所构建的东西是否真正解决了客户的实际问题。”她希望获得更多的客户背景，但又觉得自己只专注于实施而受到了限制。
Rita 是团队的产品设计师，她也面临着自己的困难。她花费数周时间精心设计出像素般完美的设计，但在开发过程中却收到了重要的反馈，迫使她不得不进行重大修改。她解释说：“当开发人员指出技术限制时，往往已经来不及保持最初的设计构想了。”Rita 需要与开发流程更好地集成，并需要一种能更早验证设计的方法。
然后是产品经理 Paul，他试图将所有事情整合在一起。他花了无数个小时撰写详细的需求文档，但总有一些东西在翻译过程中丢失。Paul 说：“感觉就像在玩电话游戏。当功能到达客户手中时，它们已经变成了与我们最初设想不同的东西。”他急切地寻求工程团队和设计团队之间更好的协作，但传统的交接流程不断制造障碍。
项目群经理 Rick 可能担任着最具挑战性的角色。协调多个团队之间的依赖关系，同时兼顾交付速度和质量，这让他彻夜难眠。Rick 说：“当团队各自为政时，简单的变更就可能导致数周的延误。”他需要一种方法来促进更好的跨团队协作和可见性。
负责监督这一切的是工程领导 Anna，她正在努力改变团队的运作方式。虽然她非常重视卓越的技术，但她知道自己还缺少一些东西。她指出：“我们拥有才华横溢的工程师，但我们并没有持续提供客户所需的价值。”Anna 希望改变团队文化，但传统的开发模式很难在卓越技术和客户价值之间取得平衡。
这个团队的经历反映了软件开发中更广泛的模式。传统的按部就班的方法虽然有条不紊且可预测，但却在产品的开发者和使用者之间造成了自然的脱节。
文化：转型的关键
“文化把战略当早餐吃”。尽管这句话通常被认为出自管理大师 Peter Drucker 之口，但在 2006 年 Mark Fields 将其永久性地陈列在福特公司的作战室后，这句话的地位就更加突出。这句话不仅仅是一个朗朗上口的短语，它还抓住了我们在科技行业反复看到的一个基本事实：如果与组织文化相冲突，即使是最杰出的战略也会失败。
当我们决定转变 Compass 的工程文化时，我们发现了一个深刻的道理：仅有卓越的技术是不够的。我们需要在工程师和客户之间架起一座桥梁。事实证明了这一点：与竞争对手相比，拥有强大文化的公司收入增长 4 倍。
我们在 Compass 的转型历程完美地诠释了这一点。我们从通常需要 6 到 8 周才能完成的传统功能生命周期流程转变为迭代发现流程，这让我们更贴近客户的问题。这不仅仅是流程的改变，而是从“无所不知”到“无所不学”思维模式的根本转变，在这种转变中，每个功能都成为向客户学习的机会。
产品工程的演变
传统上，软件工程是通过系统化的设计、开发和测试，将需求转化为工作代码。工程师主要关注技术执行：编写高效代码、维护系统和确保质量。
然而，产品工程代表着我们在构建软件方面的思维方式发生了根本性转变。产品工程在保持软件工程技术严谨性的同时，还增加了一个关键要素：深入了解客户和持续学习。产品工程师不仅仅是编写代码，他们还参与发现和解决客户问题，为产品决策带来技术洞察信息，并对自己的工作成果负责。
传统的软件工程模式
在传统模式中，开发遵循线性路径。需求从产品管理转向设计，再到实施需求的工程团队。把它想象成一场接力赛，每个团队将接力棒传递给下一个团队。
我们团队以前的工作流反映了这种线性方法：
- 创建和批准需求文档需要几个月的时间
- 架构师和设计师孤立工作
- 工程师按照精确的规范编码
- 最后才进行测试和部署
- 客户反馈经过多层筛选
在需求稳定、变更成本高昂的情况下，这种方法非常奏效。但在当今快速发展的市场中，我们需要一种适应性更强、更以客户为中心的方法。
产品工程持续循环
我们的转型重点是用持续学习循环取代这种线性流程。现在，我们不再将开发视为接力赛，而是更像一支足球队来运营—每个人都齐心协力，适应不断变化的条件，并紧盯为客户创造价值这一目标。
在这种新模式中：
- 工程师参与客户访谈和发现会议
- 通过快速原型设计和测试，合作进行开发和设计
- 根据客户需求验证技术决策
- 部署成为学习的机会，而不仅仅是交付的里程碑
- 团队通过客户影响而不仅仅是技术指标来衡量成功与否
从实施到自主权
对于像 Tina 这样的工程师来说，这种转变意味着从单纯的实施发展到真正的自主权。现在的工程师：
- 参与问题定义和解决方案探索
- 将技术视角引入早期讨论
- 直接与客户验证假设
- 对功能成果负责，而不仅仅是对代码质量负责
- 跟踪业务指标和市场影响
结果不言自明：与采用传统工程方法的组织相比，采用这种模式的组织上市速度更快，功能采用率更高。也许更重要的是，我们看到了更高的团队参与度、更好的技术决策，以及技术解决方案与客户需求之间更强的一致性。
我们如何实现转型
转变工程师的工作方式需要的不仅仅是思维方式的转变，还需要正确的基础。对于我们的团队来说，Jira Product Discovery 是这一基础的关键部分，该工具自然而然地将客户背景信息带入了我们的日常工作流。
我们需要解决的第一个难题是让每个人都能获得客户洞察信息。以前，客户反馈和产品需求都存在于 Confluence 文档、Slack 话题和 Jira 请求单中。Jira Product Discovery 将所有这些背景信息直接引入了我们的开发工作流。工程师现在可以在进行开发工作的同时查看客户访谈、反馈会议和使用模式，从而使客户需求变得切实而直接，而不是抽象而遥远。
这种可访问性从根本上改变了我们团队的协作方式。当像 Rita 这样的设计师创造新设计时，她可以直接将其与工程师可以看到和理解的客户痛点联系起来。当 Paul 确定功能的优先级时，他可以轻松地将客户影响与技术复杂性联系起来，从而做出更明智的决策。最重要的是，我们的工程师终于可以了解整体情况—不仅仅是我们正在构建的东西，还有为什么它对我们的客户很重要，以及它将如何影响他们的工作。
对于正在考虑类似转型的团队，请记住这不是在卓越技术和客户至上之间做出选择，而是要将两者结合起来，创造出客户真正喜爱的产品。当工程师深入了解客户需求时，他们就能做出更好的技术决策，设计出更优雅的解决方案，并在工作中找到更大的意义，因为他们能看到工作的直接影响。
想进一步了解我们是如何实现这一转变的吗？请查阅我们的在线研讨会：产品工程背后的魔力：将客户问题转化为他们喜爱的功能，我将深入探讨我们的历程，并与您分享可以在自己的团队中实施的实用策略和例行程序。