Key Takeaways
Product engineering in software engineering blends technical excellence with customer-centricity, moving beyond code delivery to solving real user problems.
Teams shift from linear handoffs to continuous learning loops, involving engineers in discovery, design, and validation.
This approach increases feature adoption, team engagement, and alignment with customer needs.
Foster a culture where engineers own outcomes and collaborate closely with customers for greater product impact.
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 确定功能的优先级时，他可以轻松地将客户影响与技术复杂性联系起来，从而做出更明智的决策。最重要的是，我们的工程师终于可以了解整体情况—不仅仅是我们正在构建的东西，还有为什么它对我们的客户很重要，以及它将如何影响他们的工作。
对于正在考虑类似转型的团队，请记住这不是在卓越技术和客户至上之间做出选择，而是要将两者结合起来，创造出客户真正喜爱的产品。当工程师深入了解客户需求时，他们就能做出更好的技术决策，设计出更优雅的解决方案，并在工作中找到更大的意义，因为他们能看到工作的直接影响。
想进一步了解我们是如何实现这一转变的吗？请查阅我们的在线研讨会：产品工程背后的魔力：将客户问题转化为他们喜爱的功能，我将深入探讨我们的历程，并与您分享可以在自己的团队中实施的实用策略和例行程序。
