技术领导力实战笔记
TGO鲲鹏会
100位CTO的真知灼见
立即订阅
14777 人已学习
课程目录
已完结 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的持续成长
技术领导力实战笔记
登录|注册

第21讲 | 绩效管理的目标不仅仅是绩效考核

蚂蚁金服资金运营技术部负责人、TGO会员于君泽 2018-05-21
我们经常讨论绩效考核这个话题,有不少人为如何考核程序员产出这件事烦恼。我旗帜鲜明的提出观点,绩效考核只是绩效管理的一环,如果抛弃绩效管理谈绩效考核,无异于舍本逐末。本文尝试聊几个大家关心的话题:绩效考核有哪些痛与伤、绩效管理与绩效考核的关系、目标与 KPI、OKR 的关系等。

绩效考核有哪些痛与伤

我们先回顾一下绩效考核都有哪些常见问题。
第一类问题,我们姑且称为”工作量考核”。顾名思义,工作量考核的关键点在于工作量评估。工作量评估,又会绕到一些常见的问题:
Java 开发工程师的工作产出如何衡量?
前端工程师的工作产出如何衡量?
产品经理的产出如何衡量?
DBA 的工作产出如何衡量?
有人提到过代码行评估,但代码行评估其实在业界的争议非常大。代码行多是绝对代表产出更好吗?不同语言之间对比代码行也是一个有点滑稽的事情。
第二类是绩效考核,可以称之为”全面指标考核”。全面指标考核可以说在”考核”本身这件事上已经做得足够了,一般会关注多个维度的评估以保障全面性。我曾在一家电信业务的 IT 公司做部门经理,当时公司是采用平衡计分卡来做绩效考核。
平衡计分卡是从财务、客户、内部运营、学习与成长四个角度,将组织的战略落实为可操作的衡量指标和目标值的一种新型绩效管理体系。我后来反思,绩效目标要突出拉动力,而不是面面俱到。否则很容易导致全面指标考核在实操过程中走向失败,绩效考核的维度和实际运营维度不 match。
我们再看一个例子。在项目研发中往往以研发过程数据、业务结果、公司制度(比如考勤)、主管主观评价等构成程序员的绩效考核体系。如下图所示,示例了一个绩效考核的指标体系。
业务结果、研发过程、制度考勤、主观评价 4 个维度有对应的权重,来体现不同的岗位角色和各项指标的关联紧密程度。比如,活跃用户数超出预期,研发人员自然是有贡献,但产品和运营所起到的作用更是重要。我认为,研发过程的指标应该作为观测指标,真正的考核指标是业务在线上运营的故障和缺陷,以及研发人员对于需求响应、客户服务方面的满意度。由外而内,避免自嗨。
绩效考核还有一类问题,出在绩效指标设定上。绩效指标要和组织目标对齐,不要为了设置而设置。我们来看一个例子。某测试同学的绩效指标设定:1:所负责的模块无线上缺陷;2:辅导应届生进行功能测试;3:完成一次性能测试。
到考核季的前一个月,这位同学发现我的第三个指标 (完成一次性能测试) 还没做呢?于是急急忙忙去做了。当主管评估该同学绩效指标的时候,发现所有指标都完成了,包括性能测试的指标。但这个指标是不是当下最重要紧急的,甚至这个个人绩效指标跟项目目标、团队目标没有强关联。目标没有对齐的危害,可能是树木和森林没有很好的对应,甚至可能南辕北辙。
通过这个 case 可以思考一个问题,绩效目标设定和所属团队目标的关系,以及和上级组织目标的关系。
我们跳过绩效考核应该如何做,先回头来看看绩效管理是怎么回事。

绩效管理闭环

有个专家叫戴明,他发明了一个快速反馈的工具叫戴明环,又称为 PDCA 环。PDCA 环实际是美国质量管理专家休哈特博士首先提出的,由戴明采纳、宣传,获得普及。PDCA 循环的含义是将质量管理分为四个阶段,即计划(plan)、执行(do)、检查(check)、行动(Action)。
绩效管理其实质也是一个 PDCA 循环。
第一步是目标设定。目标来自于哪里?技术团队的目标一定是来自于业务。我经常讲不服务业务的技术都是耍流氓。阿里巴巴 CTO 行癫也有句话,所谓的工程师文化就是”让好技术驱动业务腾飞”。比如一个业务负责人把一款 app(如极客时间) 的目标设定为:
活跃用户数达到 10 万
单品专栏成交量超过 20000
按照增长黑客的思路,引新、留存、促活、转化这些套路都会用起来,那么对于技术平台就可能有一些对应的技术指标。比如:
App7*24 小时可用(实际上可以放宽一点,深夜 4 点还在学习的用户极少)
App 稳定性 (安装包大小、启动时间、崩溃率、App 耗电等)
易于分享和传播(比如分享步骤不超过 3 步,过于复杂会让用户失去兴趣,当然还可以通过返利一定程度上平衡)
第二步是设置计划,亦即是 PDCA 环中的 P(Plan)。设置计划来自于目标的分解。比如:
8.31 完成 A 业务线的全部业务接入
9.30 完成 B 业务线的全部业务接入
10.31 完成 C 业务线的全部业务接入
第三步是执行 (Do),执行过程中进度风险、人员流失、技能不够、需求变更频繁等风险都有可能存在,甚至是不止一个因素同时发生。那么我们要做好的就是缩短反馈环,解决问题。每日立会、缩短迭代发布频度等有助于掌握项目实际的风险和完成状况。参与项目的同学,项目整体目标与个人目标息息相关,可以通过主动反馈主管来做阶段性检查 (check) 对齐。
第四步是检查(Check)。对于个人而言,日常过程中的绩效管理尤其重要,及时发现偏差,及时清晰的沟通,落地有效的改进计划或方式。同时如果涉及绩效目标的变更,也要及时沟通调整。
第五步是给出 Action。根据 check 结果给出 Action 帮助目标进行改进。同时进入到新的 PDCA 循环。
由此可见,绩效管理是一个闭环过程,而绩效考核是其中一个阶段。如果等到考核期才发现问题就晚了,应该保持按周、月、季做 check 有利于早发现、早纠正。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《技术领导力实战笔记》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(2)

  • 少帅
    KPI是手段,没有问题,变质在于人心,偏离了初衷
    2018-05-21
    4
  • 谢军
    在管理工作中,我特别希望下面的员工能够拥有子驱力,并且能够从产品公司的角度去解决思考问题,但一直没有什么好的方案,后面了解到了okr,事实上就是我们把公司阶段目标和方向和部门中的人都做了传达,大家知道公司现在要做些什么,然后才知道自己做的事哪些是最重要的,优先级最高的,这时候他就拥有了独立思考自己驱动自己完成工作的能力了
    2018-06-14
    1
收起评论
2
返回
顶部