Tag: 功能请求

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

今年早些时候，《华尔街日报收入》团队的一些同事发现了一个完美的工具来帮助他们加大广告工作，但是他们需要WSJ iOS团队（我的团队）来实现该工具的软件开发套件（SDK）。 尽管这似乎是一个简单的请求，但我们很快发现了多个危险信号，其中包括由于SDK庞大而可能对WSJ应用造成巨大性能影响。 在我们的团队之间经过三个多月的反复交流之后，我们得出结论认为SDK不必全部实现。 我们仅需要SDK中包含的一项非常基本的功能。 两个团队都对结果感到满意，但是花了不必要的时间才能达到这个简单的解决方案。 当我们享受合作的广泛时，我们的团队想知道这个古老的问题： “我们如何更快地获得相同的结果？” 为了改善跨团队的协作，《华尔街日报》的产品，设计和工程（PDE）小组一直在实施“ 目标和关键结果 （OKR）”，这是一种流行的方法，鼓励个人设定可衡量的，面向团队的目标设定目标，支持团队目标，最终帮助推动公司目标。 为了给这些PDE OKR的规模提供一些背景信息，以下是《华尔街日报》上整个​​PDE组的示意图。 尽管事实证明OKR在整体PDE方面非常成功，但仍缺乏对功能级别的转换。 我和我的团队认识到了收入团队的要求的意图，但并没有完全理解其价值或重要性。 意识到缺乏对功能级别细节的关注，我的团队开始尝试在产品级别上使用OKR进行功能请求。 从那时起，我们已经看到了一些奇妙的好处，包括更好的团队之间的协作，更轻松地确定功能请求的优先级以及经过更好的功能审查。 现在，当另一个团队希望就某个功能进行协作时，我们要求该团队的产品负责人将请求与PDE级别的OKR以及具体请求的客观和预期关键结果以及如何进行度量保持一致。 通过解决以下问题： 团队确保他们正在考虑部门级别的目标 涉及功能请求的每个人（从工程，设计到产品）都了解为什么要通过已定义的预期结果来实现该功能 所有PDE都可以更好地集思广益，以达到相同的结果 还不清楚吗？ 让我们看一个假设的场景：产品负责人要求WSJ iOS团队提供一项特定功能，即“添加一个新的介绍性视频，以显示通知在应用程序中的位置。”我们的模板如下所示： 功能要求：添加新的介绍性视频，以显示通知在应用程序中的位置。 PDE目标：使读者体验引人入胜。 PDE关键结果：到第三季度末，将至少具有一个针对iOS或Android应用程序的通知警报的读者数量从10,000个增加到12,000个。 功能目标：鼓励读者注册他们关心的通知。 功能关键结果： 在第三季度末，将至少已为WSJ iOS应用程序打开一个通知的读者数量从5,000个增加到6,000个 将第三季度访问通知设置的读者数量从10,000个增加到12,000个 将第三季度请求通知的客户服务票证数量从200减少到100。 当我们将这些由OKR驱动的功能请求带给更广泛的团队时，就会展开美好的协作。 设计师可能会说：“如果我们想让更多的读者进入通知部分，这将有助于将图标更新为更加醒目和直观的方式。”然后工程师可能会大声说：“因为我们要针对特定​​读者，我们可以使该应用再次向那些没有通知的读者显示入职通知屏幕。” 通过促进OKR驱动的功能请求，我们开始鼓励采用不同的观点，以便团队协作地考虑请求的基础价值，而不只是请求本身。 功能请求的讨论变得简洁明了，指向“把功能请求扔在篱笆上等待其完成”的心态已过时。 我们计划继续迭代此方法，以便将来使跨团队协作更好。