乐趣区

关于研发管理:从-Netflix-传奇看结果导向的产品路线图如何制定下篇

写在后面 :本文译自 Jason Doherty、Kelsey Stevenson 和 Thomas Vela 于「2019 年丹佛守业周」发表的「Outcome Based Roadmaps」主题演讲实录;原作者为 Jason Doherty。

👉如何制订产品路线图(上篇)👈 中提到,明天优良的产研团队不只关注性能的上线交付,还更加在意性能交付后是否达成了预期的后果,而后果(Outcome)是性能所产生的、可测量的、与企业指标统一的用户行为的变动。

追随路线图制订的前四部曲,咱们设立了一个产品愿景,多个指标、后果和机会。 在敲下第一行代码或键入第一个词语之前,咱们先明确了「什么是产品胜利」,并分明地指出实现目标所需关注的一系列事件。

你可能不信,大多数团队并不这么工作。他们施行的性能通常来自 CEO 或 SVP 在晨间沐浴时蹦出的想法——典型的 HiPPOs(Highest Paid Person’s Opinion,最高薪人士意见)景象。Jez Humble 在 2012 年的一项钻研中指出,超过 60% 的产品团队会通过 HiPPOs 决定待构建的事项。

产品胜利被定义为「性能上线」,而只有七分之一的性能实现了「发明可量化的影响」的指标。

失去一个想法,非常容易。解决用户问题并实现目标,却很艰难。

一个能够掂量胜利与否的策略框架,可能让领有受权的跨职能组织一直迭代性能并解决问题,直到预期指标达成。

01 后果导向的路线图

路线图是一个与领导层和产研团队沟通的策略工具。它说明了

  • 愿景和指标是什么?
  • 想要达成什么后果?
  • 如何掂量「胜利」?
  • 以后的重点是什么?
  • 有哪些重要的工夫节点?

路线图侧重于产品愿景、指标、成绩和机会,而发版打算则形容了故事、性能、解决方案和想法。

02 最容易实现目标的是跨职能团队

就像后面说的那样,过来大多数性能都是由居高临下的企业领导者所指定,与产品策略毫无关联。产研团队像外包供应商一样,一直实现性能;无论性能是否达到预期,咱们只掂量工程师团队的开发速度和已交付的性能,接着便能发表胜利。

更快地交付谬误的性能,仍然没有交付价值。

当初,高效能的产研团队应用数据和用户反馈,掂量性能是否达成预期指标。每个性能在公布时都是可量化的,并且都有一个预期的后果。团队会一直迭代性能(应用精益守业技巧,如「构建 - 评估 - 学习」循环)直到胜利为止——大家都晓得什么是胜利,也分明指标应该长什么样子。

企业中最有能力达成后果和指标的人,是那些实现性能和离用户最近的人;他们通常是产品团队、产品经理、工程师和运维团队。 现实状况下,他们应该处在一个跨职能团队中,而不是孤立地散布在各个部门里——如果这正是你所在团队的组织模式,那么后果导向型治理恐怕不太实用。

03 机会 > 想法 > 解决方案 > 性能

跨职能的研发团队如何以后果为导向,确保发版打算与路线图的指标统一,并将价值交付落实到研发全流程中?

制订产品策略图的第 5 步:将「后果」同步给跨职能团队,让他们:

🔸 联合独特切磋出的机会,提出想法(Idea);

🔸 应用数据和用户反馈,验证哪些想法真正解决了用户问题;

🔸 依据已实现验证的用户问题的解决方案(Solution),创立性能(Feature);

🔸 迭代性能,直到真正获得成功。*

强烈推荐应用 Theresa Torres 的「机会解决方案树」工具,它能够分明地展示后果和解决方案之间的分割。

机会解决方案树要弄清楚三个问题:

1️⃣ 有哪些想法能够解决这个机会?

2️⃣ 已经尝试过哪些试验、假如或可能的解决方案?

3️⃣ 试验的后果如何?是否要推动该性能 / 放弃这个想法,或者开展新的试验以改良该想法?

实际中,应该明确地向管理者表白本人认识,承当起本人的责任;在大公司里,随着时间推移,也能够在团队间交换彼此的学习教训。

通过试验验证想法后,再推动下一步工作,创立性能和用户故事,并构建生产就绪的代码。优良的产研团队总是防止构建没有价值的性能。

机会解决方案树有助于让高层领导们更具体地了解试验和学习成绩。Dave Chalmers 在《一个前「性能工厂」的 PM 自白》中,也提供了一些能让机会解决方案树在组织内具象化的实用倡议。

04 Current, Next and Future 模型

只管我很恶感在路线图上设置工夫点,但现实情况是咱们须要为企业高管们提供一些时序打算的领导;能够应用「Current, Next and Future」模型,列出工夫线。

别忘了要在路线图上列出产品愿景和指标,以确保后果与指标严密相干。如果须要,也能够将后果按主题(Theme)分组,这有助于策略的具象化。

将所有内容放在一起,就会失去一张后果导向的产品路线图:

一个十分有用的小技巧: 只列举出「Current」列中正在开发的性能,让企业高层们理解「目前正在进行的工作」和「下一季度或当前的策略」。

由 Todd Lombardo、Bruce McCarthy、Evan Ryan 和 Michael Conners 合著的 Product Roadmaps Relaunched 一书中也有许多很棒的案例,举荐大家浏览。

总结一下

以后果为导向,治理产品是一个难题。咱们必须建设一个清晰的产品愿景和策略;必须拥抱变动,承受不确定性;必须放弃传统的我的项目制治理,转向后果导向的怀抱。

咱们要组建和造就一支可能掌控后果的团队,受权他们解决问题,并一直迭代直到产品胜利;还要构建 DevOps 文化,以便在生产中平安地与实在用户一起测试想法,取得反馈和数据。

别放心组织规模太大或限度太多而无奈发展以后果为导向的管理工作,因为亚马逊、谷歌、Netflix 和 Facebook,甚至英国政府,都是这么工作的。

在工作实际中逐步向后果导向转变,尤其是销售主导或工程主导的团队。能够缓缓地从小规模扭转开始,关键在于要联合产品路线图,围绕产品的独特愿景,建设起一致性。


理解更多研发治理、效力晋升、麻利开发、行业动态等音讯,请关注 LigaAI@SegmentFault 账号。

或者点击 LigaAI- 新一代智能研发合作平台,在线申请体验咱们的产品。

退出移动版