什么是产品负责人？在成为产品负责人之前不久，我并不知道这个术语。然而，我经常听说产品经理为公司开发和维护产品。我目前在 Red Hat 工作，我们有几个很棒的产品，还有更棒的产品经理在产品整个生命周期中引导产品。产品经理与客户密切合作。不断与他们会面，评估他们的产品表现如何，同样重要的是，确定客户需要添加的新功能。

但产品负责人？直到有一天，我的经理让我成为 RHEL 容器运行时套件产品（如 Podman、Buildah 和 Skopeo）的产品负责人，我才意识到这个词。她解释说这个职位刚刚空缺，鉴于我的业务和软件工程背景，她认为我是一个合适的人选。不完全清楚我要面对什么，我说：“当然！听起来很有趣。”

我做的第一件事是在 Google 上查找“产品负责人”这个词。我找到的一个比较好的定义是在 TechTarget 上。简而言之，文章解释说“产品负责人是 Scrum 团队中的一个角色，负责项目的成果”。他们是 Scrum 团队和产品管理团队之间的桥梁。产品负责人这个角色非常需要平衡，权衡产品经理提出的客户对功能的需求与 Scrum 团队的产出能力。

除了需要平衡之外，我作为容器运行时团队产品负责人的角色也证明了它是一个需要协调多项任务的角色，其中还混杂着相当多的分类工作。我的主要职责之一是监控问题报告，特别是任何新报告的问题。我会在一天早些时候审查所有新报告，然后决定它们的重要性以及团队中哪位工程师最能处理该问题，并将其分配给他们。然后，随着问题的进展，我负责确保它们按时解决，对于关键问题则有更短的时间框架。鉴于此，我需要利用一天中的时间来监控新问题和当前问题。

尽管问题至关重要，但作为产品负责人，您不能过分专注于处理问题。它们对工作来说非常重要，但您还必须确保不断推出新功能，以保持产品的新鲜感和持续发展。我与我们的产品经理的关系发挥作用，以确保我不会忽视新功能。在 Red Hat，我们每六个月发布至少两个 Red Hat Enterprise Linux (RHEL) 版本。对于每个为期六个月的发布周期，我与产品经理和我组织中的其他几个人密切合作，以确定将添加到我们产品中并随即将推出的 RHEL 版本一起发布的功能。

许多这些讨论还涉及我们的工程、质量保证、打包和文档团队，以验证为拟议交付物计划的工作对于每个团队来说都是可行的，而不会在此过程中使任何团队超负荷。如果其中一个团队无法交付特定功能的要求，将进行进一步的讨论以优先考虑所有计划内容。有时，我们可能需要将一些计划内容推迟到下一个六个月周期，或者在极少数情况下，完全放弃考虑。

功能和问题是这个职位的主要职责，但日常工作中还会出现许多其他事情。它们多种多样，必须添加到我的日常“待办事项”列表中。例如，我做了很多社区工作。我负责维护 Twitter/X、Bluesky、YouTube 和 Mastodon 账户。我管理我们项目的大量电子邮件列表，并关注和维护 Podman.io 和 Buildah.io 网站。我还计划和运行 Podman 社区和 Cabal 会议，并撰写会议记录。我一直在为两者寻找话题，并为我们的 YouTube 频道寻找内容。

当我有一些空闲时间时，我会写一篇像这样或技术性更强的博客。我的职业生涯始于工程师，并且我仍然正式持有该头衔，所以我确实喜欢实际解决问题，通过编写一些代码来“弄脏我的手”。更常见的是，团队中的一名工程师会发现并修复一个错误，我将协助将修复程序移植到需要更新的各种版本中。

除了所有这些之外，计划外的问题也会时不时地冒出来。这些问题可能包括新的 CVE、来自主要客户的高度关键问题、团队状态的变化、CNCF 提交或需要考虑的 RHEL 交付物的变化。最后但同样重要的是会议。由于我们项目中有许多人在工作，还有 Red Hat 内外依赖这些项目的人，我每天花几个小时开会，与每个人进行协调和沟通。

我想我在这里想说的就是，作为产品负责人，从来没有“典型”的一天。我总是计划在某一天做“X、Y 和 Z”，然后可能会做“X”，接着处理“A、B 和 C”。事情不断出现，需要考虑、分类，然后酌情纳入团队的工作计划。

我的日子总是不同的，很少像预期的那样。这是一份快节奏的工作，而且非常被动。这是一个我热爱并每天都觉得充满挑战的职位。我需要运用多年来积累的所有组织和工程技能，它与我职业生涯中担任过的任何其他工作都不同。我不确定这是否是典型产品负责人的生活，但这是我现在非常享受和引领的生活。