@lucaswargha 更多关于工程师为成果负责的例子：https://t.co/kdfDAfDrjh

比了解代码更懂你的客户——与 Lucas Wargha 谈产品工程

来源：https://www.epicproduct.engineer/know-your-customer-better-than-your-code-product-engineering-with-lucas-wargha~1xegq 我和 Lucas Wargha 聊了聊，如何在全球范围内将软件工程师转变为产品工程师——以及为什么这始于关心成果而非任务工单。

Lucas 是 FamilySearch 的工程经理，负责 Memories 产品：一个存储照片、音频和故事的平台，帮助人们将家族成员视为鲜活的个体，而非家谱上的名字。他的团队服务于一个说起来容易、落地极难的非营利使命：帮助人们发现并与家族建立联系。这个使命体现在他们为重大遗留系统重写做论证时、体现在他们刻意决定哪些部分可以低配开发时、也体现在他们推动工程师质疑那些不能推动产品前进的工作时。

Lucas 有一句话让我印象深刻：比了解你的代码更了解你的客户。这不是说代码不再重要，而是因为实现成本越来越低，而产品判断能力却无法轻易获得。他描述了自己与巴西用户交流的经历：某个翻译后的词语与英文 UX 设计中的含义完全不同——这种事情盯着数据 reducer 是永远发现不了的。

我们还聊到了 Gmail 密码加载的故事：工程师注意到大多数人会在 1-2 分钟内完成密码输入，于是他们开始在用户输入邮箱后就在后台加载收件箱。这就是产品工程思维——用技术洞察服务用户成果，而不是等着产品经理递给你答案。

Lucas 正在积极终结这种模式：工程师消费 JIRA 故事，在一个平台上完成一个片段，然后交接给下一个孤岛。他会分配史诗和里程碑，让同一个人跨 Web 和 Mobile 拥有整个成果，这迫使工程师进行客户沟通、利益相关方协调和文档支持——而这些是孤立任务永远无法暴露的。

“创造者 vs 消费者”这个框架也很有启发性。Lucas 希望工程师成为创造者，理解自己软件为特定用户创造的价值——而不是那些将需求转化为代码就结束的“高级承包商”。

Lucas 的作业非常具体：选一个你手头的故事，与三个不同用户画像的潜在用户交谈，让学到的东西改变你的工作，而不是急着完成任务。

最后，他对身处这个令人担忧市场的工程师表达了希望——我们或许正生活在历史性时刻，而早点意识到这一点可能会改变我们构建的方式。在一场关于组织架构、用户画像和全球软件的务实对话之后，这种基调让我倍感欣慰。

嘉宾

• https://www.familysearch.org/
• https://github.com/lucaswargha
• https://x.com/lucaswargha

作业

• 比了解你的代码更了解你的客户——留意自己是否像热衷架构讨论一样，对产品成果充满热情。
• 拿起你看板上的第一个故事，在实现之前，与三个不同用户画像的潜在用户交谈。
• 让这些对话中学到的东西改变你构建的内容，而不是孤立地完成故事。

资源