技术领导力实战笔记
TGO鲲鹏会
100位CTO的真知灼见
立即订阅
14733 人已学习
课程目录
已完结 268 讲
0/6登录后,你可以任选6讲全文学习。
开篇词 | 卓越的团队,必然有一个卓越的领导者
免费
第1讲 | 你的能力模型决定你的职位
第2讲 | 七位CTO纵论技术领导者核心能力
第3讲 | CEO实话实说:我需要这样的CTO
第4讲 | 技术领导者不等于技术管理者
大咖对话 | 从几个工程师到2000+个工程师的技术团队成长秘诀
第5讲 | CTO的三重境界
第6讲 | 像CEO一样思考
第7讲 | 要制定技术战略,先看清局面
第8讲 | 技术领导力就是“成事”的能力
大咖对话 | 未来技术负责人与首席增长官将如何协作?
第9讲 | CTO是商业思维和技术思维交汇的那个点
第10讲 | 创业公司CTO的认知升级
第11讲 | 最合适的技术才是最有价值的技术
第12讲 | 谈谈CTO在商业战略中的定位
大咖问答 | 打造自己的个人品牌,你也可以
第13讲 | 把脉高效执行的关键要素
第14讲 | 从零开始搭建轻量级研发团队
第15讲 | 定制高效研发流程
第16讲 | 培养中层团队的管理认知
大咖问答 | 发现下一个小米,不是只能靠运气
第17讲 | 团队成长要靠技巧和体系
第18讲 | 做到这四点,团队必定飞速成长
第19讲 | 将企业打造成一所终身大学
第20讲 | 论团队管理与共同升级
大咖对话 | 技术人真正需要的是升维思考
第21讲 | 绩效管理的目标不仅仅是绩效考核
第22讲 | 验证研发团队价值的绩效考核机制
第23讲 | 产品技术团队OKR使用法则
第24讲 | 996、987,程序员加班文化你怎么看?
大咖对话 | 技术管理者应该向优秀的体育教练学习
第25讲 | 建立有效的员工淘汰机制
第26讲 | 让细节的“病毒”感染你的团队
第27讲 | 如何在不同组织文化下推行技术管理
第28讲 | 业务高速增长期的团队管理:“知轻重、重绸缪、调缓急”
大咖对话 | 让团队成员持续的enjoy
第29讲 | 被80%的人误解的工程师文化
第30讲 | 关于工程师文化的六个问题
第31讲 | 五位技术领导者的文化构建实战
第32讲 | 文化是管理的那只无形之手
大咖对话 | 创业就是把自己过去的经验快速的产品化
第33讲 | 选对的人,做正确的事情
第34讲 | 打好技术团队搭建的基础
第35讲 | 做个合格的技术岗位面试官
第36讲 | “高潜力人才”的内部培养
大咖对话 | 如何高效管理8000+规模的技术团队
第37讲 | 技术创业该如何选择赛道
第38讲 | CTO要掌握的产品哲学:理性与人性的权衡
第39讲 | 从客户价值谈技术创新
第40讲 | 技术人投身创业公司之前,应当考虑些什么?
大咖对话 | 技术人创业前衡量自我的3P3C模型
第41讲 | 技术人创业前要问自己的六个问题
第42讲 | 团队激励之分配好你的奖金
第43讲 | 通过积分考核提升技术团队的绩效
第44讲 | 空降技术高管的“择业七计”
大咖对话 | 如何打造自我驱动型的技术团队?
第45讲 | 选好人生下一站——CTO空降上篇
第46讲 | 走出“至暗时刻”——CTO空降下篇
第47讲 | 空降领导者平稳落地要做的四道题(上)
第48讲 | 空降领导者平稳落地要做的四道题(下)
大咖对话 | 管理者是首席铲屎官?
第49讲 | 打造高效的研发组织架构:高效研发流程那些事(一)
第50讲 | 你的研发流程符合你的组织架构吗?谈高效研发流程那些事(二)
第51讲 | 聊聊研发流程管理中的那些坑:高效研发流程那些事(三)
第52讲 | 数据如何驱动研发高效运转?谈高效研发流程那些事(四)
大咖对话 | 对人才的长期投资是人才体系打造的根本
第53讲 | 如何打造高效且敏捷的组织文化?谈高效研发流程那些亊(五)
第54讲 | 打造高速运转的迭代机器:现代研发流程体系打造(一)
第55讲 | 用机器打造迭代机器:现代研发流程体系打造(二)
第56讲 | 有了敏捷开发,那交付期限去哪儿了?
大咖对话 | 项目成功的秘诀——技术产品双头负责制
第57讲 | 敏捷中的期限之殇,软件业该怎么做?
第58讲 | 如何打造个人技术品牌?
第59讲 | 技术演讲,有章可循
第60讲 | 正确对待技术演讲中的失误
大咖对话 | 不可替代的Java:生态与程序员是两道护城河
第61讲 | 刘俊强:技术最高决策者应该关注技术细节吗?
第62讲 | 张溪梦:技术领袖需要具备的商业价值思维
第63讲 | 未来组织形态带来的领导力挑战
第64讲 | 如何判断业务价值的高低
大咖对话 | 池建强:做产品不要执着于打造爆款
第65讲 | 如何打造高效的分布式团队?
第66讲 | 如何打造有活力、持续创新的研发团队?
第67讲 | 如何打造独属自己的工程师文化?
第68讲 | 如何打造一个自组织团队?
大咖对话 | 童剑:用合伙人管理结构打造完美团队
第69讲 | 茹炳晟:QE团队向工程效能团队转型的实践之路
第70讲 | 王昊:技术、产品、管理的不同视角
第71讲 | 王昊:什么样的人适合考虑管理角色
第72讲 | 创业公司如何招到合适的人才
大咖对话 | 以产生价值判断工程师贡献——读者留言精选
第73讲 | 用数据来分析管理员工
第74讲 | 为什么给了高工资,依然留不住核心员工?
第75讲 | 刘俊强:一本正经教你如何毁掉一场技术演讲
第76讲 | 内部技术会议的价值
大咖对话 | 韩军:CTO转型CEO如何转变思路
第77讲 | 陈晨:谈谈Instagram文化和文化背后的故事
第78讲 | 陈晨:团队重组过程中踩过的坑
第79讲 | 程军:从0到1打造高效技术团队的方法论
第80讲 | 马晋:技术Leader的持续成长
技术领导力实战笔记
登录|注册

第23讲 | 产品技术团队OKR使用法则

明道创始人&CEO 任向晖 2018-05-23
经常有团队问我,团队或者部门是否可以应用 OKR 工作法。我的回答一般是否定的。像销售、市场、人事、行政这样的职能部门,如果彼此独立设定 OKR,几乎必然是无法和公司的聚焦目标对齐的。而且这些孤立的部门无法形成完整的业务链条,如果不能从公司或者事业单元的角度出发,就无法识别出影响成长的瓶颈问题和可能存在的增长动因,也就无法做有意义的聚焦。
但是,这个问题在产品技术部门可能是个例外。尤其是产品型公司的产品技术团队。一方面是因为产品型公司的聚焦重点经常会放在产品本身;另一方面是因为很多互联网公司在产品技术方面遇到的问题和机会都非常接近,以至于我看到不少科技公司在企业层面的 OKR 设定都非常近似。

先决条件

即便如此,也并非所有的产品技术团队都适合独立引入 OKR 方法。如果要让这个方法在企业中发挥出成效,不产生部门本位主义,那么这个团队要符合以下这些特征:
1)产品技术团队能够对产品的设计、开发和交付整体负责;团队具备主控性,而不是受制于多个部门的配合;
2)非项目服务业务模式,产品技术团队服务的是本企业的产品,而不是客户的产品,否则这个团队的核心管理体制很难超越项目管理本身。而且外包项目的生命周期也不足以来激励 OKR 的实施。
3)公司的业务成效很大程度上取决于产品本身的定位、特性与市场需求的适配度和产品质量;销售和营销职能起的是放大器作用。消费者应用领域的公司大多符合这个条件。如果是 2B 的产品则要视情形来看。
如果以上先决条件不存在,那么这样的团队独立实施 OKR 的成效是不乐观的。实际上,缺乏自治度和管理关注度的产品技术团队,本身也很难有动力来自行发起目标管理。即使做,一般也只是为了响应公司从上至下的管理要求而已。

常见的产品技术部门 OKR 类型

当我辅导了十家科技企业的 OKR 制定沟通会议以后,我发现这类企业的 OKR 选择有非常明显的规律。团队相对容易达成一致的目标意图(Objective)大体会分成这么几类:
1、产品特性交付里程碑
这可能是最常见的目标之一。产品技术团队因为担负交付产品和特性的责任,所以容易有这样习惯性的思维——本季度发布 xxx 特性,交付 2.0 版本产品等。
在这个动因下,产品技术部门设定目标要有更清醒的头脑和更整体的认知。为什么要交付 2.0 版本?2.0 版本主要解决的问题是什么?除了形式上的交付,用什么 KR 能够更好地定义交付成功?一个好的产品交付目标应该揭示背后的商业意图。比如:“通过 2.0 解决客户自助部署问题”就是更加完整的目标描述。
正是因为如此,这类目标所配套的关键结果(Key Results)也要能够反映出意图达成的 KPI(请中性理解这里的 KPI 含义)。发布时间本身不应该成为 KR,发布后能够形成的一个关键数据指标才是。比如上面“通过 2.0 解决客户自助部署问题”的 Objective 可能需要配套一个 KR:自助部署页面的 UV 数量,它反映了这个特性交付带来的客户价值,每有 1000 个 UV,说明可能有 1000 个用户得到了自助部署系统的帮助。
在产品特性交付目标方面,我还经常发现一个常见困难,就是每个季度的 OKR 周期很难保证一个大宗的产品特性交付彻底完成,更加不要说获得使用相关的数据。这时候,我们就需要定义更加细分的里程碑,而不是一个版本的交付,比如“完成单元测试”、“完成数据架构设计”等。
2、提升开发和运维质量
在产品型公司的早期,因为经验和能力的原因,在产品开发和运维过程(devops)中存在大量缺陷。有一些质量问题也可能是因为“MVP”理念导致的。这些可能都是创业公司不可避免的阶段。
但当公司开启了商业化进程,建立了专门的销售团队,低质量的产品会消耗巨大的营销投入,不仅无法转化满意的客户,而且会让整个团队士气低落。
但站在公司的角度看,刚刚建立了销售团队,管理层的注意力通常被牵制在销售团队的形成和管理上,有时候是无暇顾及,有时候是没有意识到产品质量对于提高销售效率的重要性。与其等到部门之间相互指责和推诿,有全局观的 CTO 应该尽快聚焦在提升质量的目标上。在达成这类目标时,产品技术团队的自治能力至关重要。
技术产品的质量提升目标不难设定用于衡量的关键结果(KR),但指标选择的过程最好依然是从下至上的,因为非专业人员很难有相关的知识背景。如果是和软件缺陷有关的质量改进,这个关键结果最好能够落在测试流程内部(用例的数量和覆盖度,测试的自动化程度等),而不是去衡量客户投诉率这样的滞后性 KR;如果是和运维质量相关的目标,KR 则更容易选择一些,因为有足够多的监控工具来直接提供有意义的指标。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《技术领导力实战笔记》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(1)

  • 爱笑笑
    产品研发团队的KR设定问题深有体会,大家习惯于定义版本的发布与否,因为那是显而易见的事实,而忽略了发布的真正意义是给用户带来真正的价值
    2018-11-07
    2
收起评论
1
返回
顶部