OKRs 与目标分解


近年来,OKRs (目标和关键事件)作为一种新型目标管理方法,受到了很多企业的关注。OKRs 所倡导的新型管理理念,正在取代 KPI 成为广受欢迎的目标制定工具。

关于 OKRs

OKRs 是 「Objectives and Key Results」 的缩写,即「目标和关键事件」。它是在德鲁克的目标管理 (MBO) 理论基础上发展出的一套方法。最初由 Intel 发起,在 Google 使用后被推广开来,近两年逐渐受到了各类公司的青睐。OKRs 的逻辑在于将公司目标层层分解到团队,部门再到个人,在各个层面贯穿和统一起来,每个目标的达成情况由几个关键事件来衡量。用 OKRs 做目标管理有以下优点:

  1. 目标的协调和统一。公司 -> 团队-> 个人目标层层分解,每个人不再只关注自己的工作,而是能够看到」the bigger picture」,了解自己在团队和公司整体目标中发挥的作用,让自己的工作更有意义,从而更有积极性。并且,所有团队的目标都能被统一地联系在一起,执行起来可以相互支持;

  2. 判断优先级。通过梳理 OKRs,能找出最重要的事情,让全公司专注在最有价值的事情上,便于做出取舍,最有效地利用资源;

  3. 双向沟通。OKRs 的制定由员工和自己的直线上级一起制定,需要双方同意,而不是简单粗暴的由上而下,员工只是被动接受

  4. 灵活调整。不像 KPI 是死的,只要目标不变,OKRs 中的关键事件(Key Results)在回顾的过程中可以根据情况随时灵活调整;

  5. 鼓励创新。员工有自主权去制定有挑战性的目标,而不是拘泥于公司设定的框架里。往往能激发和产生出一些意想不到的新想法和结果,鼓励公司内部创新的发生。

制定 OKRs

结合之前施行 OKRs 的经验,我们总结出了一套「目标制定 ->分解 -> 追踪」 的方法,即「平衡计分卡+OKRs「的方法,用平衡计分卡制定公司目标,再用 OKRs 分解到团队和个人,来进行全公司的目标管理。你可以创建一个 OKR 管理的项目,将每个部门的 OKR 通过任务分组区分,也可以和 Teambition 团队一样,为每个部门别建立 OKR 项目,统一管理。在 Teambition 里,每个部门的 Objectives 可以看成一个任务分组(看板), Key Results 可以具象化为任务,在这里进行团队 OKR 管理,能够将目标由大到小拆分,自上而下细化到每个员工身上。



OKRs 中的每一个目标都决定了大伙应该如何去做,以及能做到何种程度。首先定出公司的目标,其次再根据公司目标分配到每个部门每个团队,各自制定自己的 OKRs,接着每个成员根据部门目标拆分,制定自己的目标。对于一些可以量化的目标,此时 OKRs 也必须量化,比如销售团队设定销售目标时,需要添加对应的时间或数量(如:年的销量较去年增加50%)。在 Teambition 中,这一切都公开透明,任何员工都可以看到自己在这个团队中的工作价值,以及为推动团队目标的达成将要承担怎样的责任。



定期回顾

OKRs 不是永久的,它往往与企业某一段时间的战略目标挂钩。你可以在每个季度初需要确定部门和员工的季度的 OKRs,在季度结束时结合部门和员工的工作完成情况给每项 OKRs 打分。同时,也通过这样定期的季度会议检查 ,及时调整 OKRs 以适应变化。每季度的回顾任务及文件可以设为公开,给同事们提供更好的学习样本同时,也激励大家在工作中以更高的水准要求自己。



点击阅读 Teambition COO 王雅倩有关 OKRs 与目标分解的文章

跨部门协作

项目好复杂,部门太多,责任不明,出事没人管,怎么办?

为了实现高效的项目管理,需要使用科学的管理框架合理分解任务、分配具体行动、设定不同责任人、监控进程。在所有的项目管理方法论中,「责任分配矩阵」(Responsibility Assignment Matrix,RAM)独树一帜,尤其在跨部门协作方面有优势,无论任务大小和复杂度、或者中途内容有变动,都能真实地反映项目的具体情况,并且让每个人都明晰自己的职责,确保任务的最终成功执行。

「责任分配矩阵」主要针对解决了「谁来对项目的主要产出负责任」的问题,最显著的效果包括:

  1. 清楚界定每项成果
  2. 为项目的每项成果设定责任人
  3. 让跨职能沟通更为有效
  4. 加速项目决策流程,简化审批
关于 RACI 模型

「责任分配矩阵」把项目的主要成果的责任情况分为RACI (Responsible, Accountable, Consulted, Informed,即「负责」、「问责」、「咨询」、「通知」)。Teambition把这套先进的管理思想融入进产品设计逻辑,结合进简洁易上手的使用界面中。

RAM理论基础——工作分解架构(Work Breakdown Structure, WBS)

RAM是建立在WBS的理论基础上的,在对任务进行有效分解之后,利用R、A、C、I来分配具体执行任务。 使用WBS进行任务分解的基本原则是:

  1. 相互独立,完全穷尽(Mutually Exclusive Collectively Exhaustive, MECE):分解的任务各部分之间相互独立,所有部分完全覆盖任务的各个部分;
  2. 结果导向,而非行动:分解任务时关注结果,而不要陷入对细节行动的过分关注当中,导致分解过于繁琐复杂。 利用WBS分解任务的树状结构实例:

而Teambition的企业->项目->任务->子任务的层级结构就是融入了WBS思想分解任务,然后根据具体任务使用RACI制定具体责任人。

RAM使用过程


在具体工作过程中,会分解子项目和具体任务人,制作成RACI表格。编制RACI的具体步骤包括:

  1. 按照WBS把大任务分解为具体任务项,列在RACI表左侧;
  2. 与团队讨论并确定流程中的所有角色,记录在RACI表上方;
  3. 完成RACI表的方格单元:辨识每一个流程、活动的角色(R、A、C、I);
  4. 每一个流程只有一个「R」角色,这是RACI的一般原则。当一个流程找不到「R」角色时,则出现缺口。当一个流程有多个「R」角色时,则出现交叠;
  5. 解决交叠问题。每个流程只能有一个「R」角色,以便明确流程的具体拥有者和责任。如果不止一个「R」存在,那么就要对该工作包进行再分解,然而再对「R」进行分配;
  6. 解决缺口问题。如果某个任务找不到「R」角色,项目负责人则应该在现有角色中(或者发现新人选)挑选、任命一人担任「R」 。


以Teambtion内部使用情况为例:

  1. 根据公司内部的核心部门,分为市场、销售、专业服务、产品、支持、工程、用户支持部门,列在RACI表上方;
  2. 开发最好用的团队协作软件,让更多不同规模、不同行业的用户顺利使用, 并持续提供服务帮助客户成功一直是Teambition的宗旨,根据这个核心宗旨分解为7个任务,列在表格左侧;
  3. 和各个部门的负责人讨论他们如何具体负责或者辅助该任务,填入R、A、C、I;
  4. 提供一个RACI草稿表格,提供给各个责任人讨论、修改、最终通过RACI表格;
  5. 最终按照RACI进行日常任务协作,使每项核心的任务都有一个专职部门负责,没有遗漏也没有重叠,其他部门明确自己的辅助责任,实现跨部门的有效协作。

高效会议

每个公司、每个部门都有无数的会议要开。说的人滔滔不绝,听的人云里雾里,1小时的会3小时还没开完,坐久了浑身僵硬,恐怕是所有人避之唯恐不及的事情。在 Teambition ,同样有大大小小的会议,然而仅有两间会议室的我们是怎么实现高效的信息交换,将有限的时间和空间资源最大化利用的呢?今天,我们来说一说开会这件说小不小的小事。

一、从站会开始新的一天



每天早晨,研发团队的负责人会打开看板,在项目菜单中选择“查看更多-任务演示模式”,将任务板上的工作进程全屏展示,然后每个人依次简短地与团队成员交流三个问题:

1、昨天我完成了什么?

2、今天我要做什么?

3、在开发过程中遇到了什么阻力?

15分钟,就能有效的让每个人都跟进项目进展、认识潜在挑战。站立保证了会议的高效;团队成员也能因此养成每日回顾昨天工作并规划今天工作的习惯,确保自己在有限的发言时间内言之有物,实现有效沟通、推动信息交换。 站会体现了敏捷开发快速验证、快速修改的精神,充分呼应了敏捷原则的第6条:不论团队内外,传递信息效果最好效率也最高的方式是面对面的交谈。



在 Teambition 上,开发团队的负责人会为每日站会创建一个日程,设置“工作日重复”,添加团队成员为参与者。每天早晨,团队成员登陆 Teambition ,打开日历,站会的日程象征着新一天的开始;站会后,大家各自带着明确的目标和满满的干劲开始新一天的工作。

二、简短详实的部门周会



每周一早晨,销售部门会在周会上回顾上周业绩、调整本周销售方向。销售总监提前把每周的Agenda(议程)列在日程的备注中,相关议程的负责人就可以做好充足的会前准备,并将自己负责的内容归纳成要点,添加在议程中,和与会人员分享,开会时也能起提示作用,引导自己的思路。开会用的PPT可以直接上传在评论中,方便大家随时参阅。

对于开发团队来说,每个为期两周的Sprint(冲刺计划)需要召开启动、中期梳理和结束回顾三次会议。在中期会议上,开发团队会梳理目前遇到的瓶颈,反思在资源协调和进度把控上的不足,并做出相应的调整。

三、头脑风暴即时落地

跨部门会议有效的实现了企业内部的信息大循环,不同部门的声音彼此碰撞,最终汇聚成一股坚定的力量推动公司的前进。开会时热情澎湃,但怎样才能避免开完会千头万绪、无从下手呢?在 Teambition ,当会议上形成一个相对成熟、完善的计划时,相应的负责人会直接在自己部门的项目里建立任务,明确责任人和预计完成时间,会后的执行和追踪变得轻而易举。高效的会议如果受到执行力的限制,再多再好的点子也只是空谈, Teambition 行之有效地解决了将想法和计划落地的难题。

四、年度回顾有迹可循

年底将至,个人和部门都需要回顾今年的工作,通过反思总结经验、避免教训。但是对一整年的工作内容进行量化和回顾,谈何容易?



在 Teambition ,借助OKRs(目标和关键事件)的管理理念,我们总结出了一套「目标制定 ->分解 -> 追踪」的方法,即「平衡计分卡+OKRs」的方法,用平衡计分卡制定公司目标,再用 OKRs 分解到团队和个人,来进行全公司的目标管理。你可以创建一个 OKRs管理的项目,将每个部门的 OKRs 通过任务分组区分;也可以和 Teambition 团队一样,为每个部门分别建立 OKRs 项目,统一管理。



在 Teambition ,每一个 Objective 对应一个任务列表, Key Results 则具象化为任务,在这里进行团队 OKRs 管理,能够将目标由大到小拆分,自上而下细化到每个员工身上。 OKRs 也可以实现目标的量化,比如在销售团队设定目标时,需要添加具体时间和数量(如:年销量较去年增加50%)。在 Teambition ,这一切都公开透明,任何员工都可以看到自己在团队中的工作价值,以及为推动团队目标的达成将承担怎样的责任。

有了清晰的目标分解和责任分配,无论是员工汇报年度个人工作,还是管理层回顾各部门进展,都井井有条、有迹可循。 Teambition 让你的年度总结会议更轻松。

附:敏捷宣言12原则

1、我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。

2、欣然面对需求变化,即使在开发后期也一样。为了客户的竞争优势,敏捷过程掌控变化。

3、经常地交付可工作的软件,相隔几星期或一两个月,倾向于采取较短的周期。

4、业务人员和开发人员必须相互合作,项目中的每一天都不例外。

5、激发个体的斗志,以他们为核心搭建项目。提供所需的环境和支援,辅以信任,从而达成目标。

6、不论团队内外,传递信息效果最好效率也最高的方式是面对面的交谈。

7、可工作的软件是进度的首要度量标准。

8、敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。

9、坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。

10、以简洁为本,它是极力减少不必要工作量的艺术。

11、最好的架构、需求和设计出自自组织团队。

12、团队定期地反思如何能提高成效,并依此调整自身的举止表现。