技术团队与OKR

2018-09-20 14:45:00
麦田兔子
转贴:
51cto
542
摘要:本文从周期,内容,奖罚及关键因素四个方面,来论述OKR的落实。

在思考如何激励时,自然想到了CTO讲师于斌平《技术团队如何做绩效管理》中的论述,于斌平老师有着10年以上500人以上的团队管理经验的,观点也是经过了实践的淘洗,有几点很适合我们当前的团队。此处并非拿来主义,更不敢谈英雄所见略同,但是作为基层管理人员,有些point还是可以get到的~

1.考核预设
统一的价值观,引导,“方向比努力更重要”——CTO讲师于斌平
预设是为了将企业对技术团队,乃至具体到员工的价值期望传达到位,而不是在最后评分的阶段流于形式,对员工评价高,打分低或者打分评价都高,却没有实质的奖励,再次验证了方向比努力更重要的正确性。

2.用OKR而非API
KPI有毒,此言不假,如果设置不当,对团队和个人不能指导就会变成误导了。OKR全称是Objectives and Key Results即目标与关键结果,何为关键结果?
做了几个项目,搭建了几个系统,测试除了多少bug这个是关键结果吗?是,但是核心还不够清晰,有产出是必要的,但是我们忽视了其背后的两个重要的目的,一,对业务带来的收益(此处综合考量成本),二,对技术人员带来的成长 。细化一下:是否纯粹为了bug数量这一指标,在IE6兼容问题上技术争得火热?是不是用合适的技术,高效优美的完成的项目?搭建的系统有没有后续推广指导投入到作业中?等等。

3.激励策略
那,重点来了,作为技术管理层,这种格局下怎么才能通过管理手段,来打造一支有活力,有战斗力,热血又不轻浮的技术团队呢?以下我从周期,内容,奖罚及关键因素四个方面,来论述OKR的落实:

wKioL1eoRJbifUbBAACHFr8B3b4651.png

wKiom1eoROuCFH9RAACHoX57gj0131.png

wKiom1eoROygfAneAADF-Zdm-KQ835.png

具体的目标及奖惩机制根据具体人员及项目来设置调整,原则是要能充分调动起技术人员的积极主动性,成果明显,气氛欢快轻松,员工幸福指数高。

另外, 既然是团队激励,那团队的组织结构将密切影响激励方案及方案效果。以下是某司的技术部组织结构草图:

                     wKiom1eoQJXxMeweAABoI-14qXY877.png-wh_50

这种小组划分,优势明显:分工明确,责任到位,各司其职,术业专攻;劣势也很明显:工作形式长期单一,组间各自为站,不利于技术交流及发挥整体团队协作的power。


公司作为较早崛起的互联网公司,积累了丰富的互联网经验,资源及用户;传统业务项目历久弥长,业务形态成熟稳定,技术方面以支持为主;随着互联网的迅速发展,网络的普及,智能手机的大众化,办公移动化等时代的进步,如何突破创新,走出安逸,跟随甚至引领互联网大潮,对企业及技术团队提出了较高的要求;业务先行,技术需提供强有力后盾。

这种业务形态下的这种组织,貌似是很合理的,但是,员工职责单一,在团队规模不大的情况下,组员成员少,人才梯度小,不能帮扶,不利于员工成长; 时间久了,呈现出两类员工,一类是对业务轻车熟路,对技术熟视无睹(或者感觉当前的工作都在把控之内,无意识也无能力超于自己);另一类是有追求,也是不能自己完成突破,通常寄希望于环境来改变自己,比如离职跳槽;

第一类的员工貌似会给公司带来稳定,实则是不求上进的态度(企业和员工都是),试想技术迅猛发展,用户需求复杂多变,这种保守会让企业慢慢的掉队;第二类的员工通常都是有想法,和对自己的投资负责的员工(员工选择企业并为其工作也是一种投资”),能留住此类能自驱的员工,并为其提供成长的环境,形成互利关系,才是健康茁壮的团队面貌。

组织结构是稳定的产物,这里并不是要打乱当前结构,把团队揉成一团,而是可以结合OKR的形势,在关键事件中,引入“技术指导”之类的概念,担当技术指导角色的通常是来自其他组,有能力的人贡献想法,能力稍差的人在指导下落实实践方案。实践结果都纳入二者的考核范围。(貌似和大公司的师傅带徒弟制度类似,不过导向更明确)。

至此,好像说了很多,又好像什么都没说清楚,理论是美好的,现实是多变的,但是相信努力不会白费,经过摸索和实践一定能找到适合自己团队的风格。

本文旨在抛砖引玉,技术成就梦想,让团队更美好!