WSJ iOS团队如何通过OKR驱动的功能请求促进跨团队协作

今年早些时候，《华尔街日报收入》团队的一些同事发现了一个完美的工具来帮助他们加大广告工作，但是他们需要WSJ iOS团队（我的团队）来实现该工具的软件开发套件（SDK）。

尽管这似乎是一个简单的请求，但我们很快发现了多个危险信号，其中包括由于SDK庞大而可能对WSJ应用造成巨大性能影响。

在我们的团队之间经过三个多月的反复交流之后，我们得出结论认为SDK不必全部实现。我们仅需要SDK中包含的一项非常基本的功能。

两个团队都对结果感到满意，但是花了不必要的时间才能达到这个简单的解决方案。当我们享受合作的广泛时，我们的团队想知道这个古老的问题： “我们如何更快地获得相同的结果？”

为了改善跨团队的协作，《华尔街日报》的产品，设计和工程（PDE）小组一直在实施“ 目标和关键结果 （OKR）”，这是一种流行的方法，鼓励个人设定可衡量的，面向团队的目标设定目标，支持团队目标，最终帮助推动公司目标。

为了给这些PDE OKR的规模提供一些背景信息，以下是《华尔街日报》上整个PDE组的示意图。

尽管事实证明OKR在整体PDE方面非常成功，但仍缺乏对功能级别的转换。我和我的团队认识到了收入团队的要求的意图，但并没有完全理解其价值或重要性。

意识到缺乏对功能级别细节的关注，我的团队开始尝试在产品级别上使用OKR进行功能请求。从那时起，我们已经看到了一些奇妙的好处，包括更好的团队之间的协作，更轻松地确定功能请求的优先级以及经过更好的功能审查。

现在，当另一个团队希望就某个功能进行协作时，我们要求该团队的产品负责人将请求与PDE级别的OKR以及具体请求的客观和预期关键结果以及如何进行度量保持一致。

通过解决以下问题：

还不清楚吗？让我们看一个假设的场景：产品负责人要求WSJ iOS团队提供一项特定功能，即“添加一个新的介绍性视频，以显示通知在应用程序中的位置。”我们的模板如下所示：

功能要求：添加新的介绍性视频，以显示通知在应用程序中的位置。

PDE目标：使读者体验引人入胜。

PDE关键结果：到第三季度末，将至少具有一个针对iOS或Android应用程序的通知警报的读者数量从10,000个增加到12,000个。

功能目标：鼓励读者注册他们关心的通知。

功能关键结果：

当我们将这些由OKR驱动的功能请求带给更广泛的团队时，就会展开美好的协作。设计师可能会说：“如果我们想让更多的读者进入通知部分，这将有助于将图标更新为更加醒目和直观的方式。”然后工程师可能会大声说：“因为我们要针对特定读者，我们可以使该应用再次向那些没有通知的读者显示入职通知屏幕。”

通过促进OKR驱动的功能请求，我们开始鼓励采用不同的观点，以便团队协作地考虑请求的基础价值，而不只是请求本身。功能请求的讨论变得简洁明了，指向“把功能请求扔在篱笆上等待其完成”的心态已过时。

我们计划继续迭代此方法，以便将来使跨团队协作更好。