在本文中,我们将介绍OKRs(OKR与Scrum)如何为产品开发团队提供强有力的支持,帮助他们摆脱“功能工厂”的反模式,并使每位成员能够对公司战略目标的实现贡献自己的价值。
目录
传统组织通常以有限的方式采纳敏捷,她们将敏捷视为一种方法,用来更快更好地交付由业务部门确定的战略项目。
敏捷通常是在IT服务部门内实施的。但这并不能引发组织结构的重新设计,也没有让团队得到管理层的充分授权去执行业务战略。
产品负责人(PO),本应是被充分授权的产品经理,作为连接业务机会和技术团队的桥梁,实际上大多仍然只是“代理人”或敏捷项目经理。
然而,OKRs提供了一个改变这一现状的机会。让我们来看一个例子:
公司OKR
以下团队OKR则没有意义:
相反,在定义和对齐团队OKRs时,运营和技术团队应该就共同的OKRs达成一致,以服务于公司的OKRs。
或者,他们也可以共同定义与公司OKRs一致的举措或任务。
这种定义技术团队工作的方式使他们摆脱了根据”业务需求“来交付技术的IT服务模式。
当产品负责人收到一个功能或项目的请求时,他们通常得不到创建这个请求的完整战略背景。
例如,请求是“我们需要一个用于网站的AI聊天机器人。”大家都知道它应该可以减少对支持部门的呼叫,但没人知道它如何与公司战略或其他部门对齐。
如果公司今年的目标是:
那么产品负责人就会得到非常有价值的信息来了解这个聊天机器人应该解决的业务问题。
这将使他们能够与支持和工程部门互动,找到使支持更高效的最佳方式,而不会失去这些部门之间的协调。
换句话说,OKRs可以帮产品负责人更清晰地了解需要解决的问题以及提供解决方案可能的最佳方向。
组织中透明度的定义可以是“共享理解”。
OKRs促进所有团队理解大家对他们有何期望,以及他们应如何与其他团队合作,以服务于公司期望的结果。
没有OKRs,沟通可能会变得支离破碎,每个团队应该做什么以及他们应该如何合作的共享愿景也会变得割裂。
有了OKRs,规划共享工作和每个人的职责将变得简单。在前面的工作中:
支持部门、工程和开发团队理解共同目标,并确定每个部门可以采取的行动,以及他们之间的依赖关系。
OKRs有频繁的检查会议,例如每周或每两周一次。这使得部门很难采取不一致的行动或延迟。优先级和联合协调得到改善。
产品团队可能对划分Sprint工作的优先级有不同的标准。
最简单的Scrum认为,所有优先级划分都由产品负责人完成。但这:
OKRs鼓励整个团队参与定义目标和关键结果,以及共同规划Sprint工作并执行它们。
尽管保留了OKR斗士(类似于Scrum Master)和OKR负责人(类似于产品负责人)等角色,但使用OKRs有利于促进团队自我管理和以结果为导向的工作方法。
要让敏捷团队在对业务战略产生真正影响,面临的挑战之一就是不断收到来自业务部门的各种请求。
虽然这些请求对于提出它们的人来说可能很重要,但它们也可能与组织的战略不一致。这是一个问题,因为团队的时间是一种稀缺资源。
而OKRs使产品负责人更容易专注于战略目标。继续使用前面的OKRs示例:
如果我们收到一个业务请求“为其他国家的客户服务添加多语言选项”,产品负责人可以评估这个请求与战略OKRs不一致。
这并不意味着它必须被自动拒绝。在时间允许的情况下,仍然可以在交付OKRs的同时满足这个请求。但这提供了一个明确的标准来区分战略性和非战略性请求。
最后,使用OKRs为敏捷或Scrum团队带来的另一个优势是,它们加强了学习和实证主义,以定义:
OKR方法,像Scrum一样,需要通过回顾和总结来提高团队的内部效率和与改善外部利益相关者的关系。
Scrum回顾会议更频繁,例如,如果我们有2周的Sprint工作,同时OKR实行季度考核,我们可以为每个OKR周期回顾会议设定6个Sprint回顾会议。
这有助于提升团队在OKR周期中的效率,让我们有更多机会纠正团队的操作。
另一方面,虽然Scrum回顾会议可以专注于技术或流程改进,但OKR回顾会议专门关注改进团队的工作成果。
这些OKR改进可以带来想法,例如:
在本文中,您已经看到了OKRs如何提高敏捷和Scrum团队工作的有效性,以及一起使用这两个模型的优势,例如: