拿了个C,艹NM一年TM白干了!
原创不易,求分享、求一键三连
最近老板的行为很迷,今年绩效他居然只给我打了个C!
我TM这么多年还没受过这种「奇耻大辱」,于是跑去质问老板,准备跟他干一架:
小钗:爸爸,这次我绩效是C呢,这也太惨了吧?
老板:核心原因是「绩效不清楚」,不清楚的统一C,你们的绩效我当时没签字,还有很多疑问没有被解除。
小钗内心嘀咕:技术这块给你说了你也不懂啊,你要清楚个撒?
小钗:是我们考核没有依据吗?
老板:是的,没有办法判断。
第一没有提前「约定好的考核指标」,第二没有「被提供的材料说服」。这种情况都是C。
小钗心理:你这台无情的机器,忘了我陪你一起打了羽毛球吗?
显然老板装逼感觉上来了,于是又在部门负责人群开始发散:
大家应该都拿到部门绩效考核结果了,几点算法模型说明(你又不会写代码,说什么算法模型,我呸!):
1 这次考核分为两类,有提前约定好绩效考核方案的部门和没有约定好方案的部门(以CEO及分管领导签字为准);
2 有方案的,又分为两类,「客观可量化指标」和「主观不可量化指标」;
3 对于客观可量化指标,又分为采信数据「信用度高和低」;
4 这次得A的部门是有提前约定绩效方案+方案主要为客观可量化指标+指标采信数据信用度高+完成率达标;
5 没有提前约定绩效方案的部门,最高为C;
6 主观不可量化指标过40%的部门,最高为B;
7 采信数据信用度低的部门,最高为B;
8 请所有部门认真对待绩效方案的设计,在来年确定有签字、「可量化」、采信高的好方案,「此谓科学」。
虽然对老板给我打C的行为极度不满,但有两个问题却萦绕不去:
1)老板疯了,今年怎么开始看数据指标了?
2)老板傻了,这么多「专业部门」数据指标他能懂?
带着以上问题,进入今天的学习,首先是为什么老板「突然关注数据指标」了。
膨胀的复杂度
规模大了会怎样
按照系统性思考的逻辑:
如果你想创造一个能够维持一定秩序、不会分解的系统,那么这个系统必然是一个开放系统,就需要为他注入能力,并让其在系统中流动以维持这种秩序。
管理的动作就是为团队注入能量,能量停止系统就会开始退化,这种持续为组织注入能量的行为,正是领导力的核心。
以上的话比较晦涩,他要表达的意思是:
团队一定会出问题。规模越大问题越多,并且问题会越来越愚蠢、越来越不可思议!
如果没有管理动作的介入,团队会变得十分混乱,「效率接近为0」,根据熵增定律,「封闭的系统,最终会由有序变成无序」。
这里举个简单的小例子:
大家去食堂打饭,没人维护秩序会怎么样; 规模增加,变成市民去火车站买票没人维护秩序会怎么样; 持续规模增加,变成国庆期间外滩游客如果没人维护秩序会怎么样;
每个阶段的问题
所以管理的核心其实是「有效的解决团队的问题」,保证他有效的运转,而团队不同的阶段,不同的规模下产生的问题以及对leader的依赖是有所不同的,如图所示:
形成期需要向心力
每个团队在形成初期,沟通往往是单向的,需要一个「强有力的leader」,成员之间了解度低,对环境乃至公司团队「战略不清晰」,很容易产生「焦虑困惑」和不安全感。
比如新同学是非常容易「无所适从」而导致离职的,这个时期主要需要解决的是两个点:「信任与目标」。
即员工之间的信任问题,和明确团队的目标问题,这个可以由五维能力模型的战略入手。
这个时期的团队一般50人以下(更常见于20人以下),由leader凝聚起来,如果leader足够优秀,团队会非常有凝聚力,适合「局部作战」,打一些「小战役」,而随着团队发展,接下来就会进入风暴期。
这个规模完全「不需要数据指标」,什么事吼一声了事,设置指标反而是一种阻碍。
风暴期建机制、分赛道
由于团队规模变大,不可避免的团队和团队之间会产生合作,但是因为各个团队风格各异,冲突会因为「文化」、「理念」、「利益」、「工种」等问题不断爆发。
这个时候Leader主要解决团队之间的问题,除了机制解决以外,更好的办法是「划分赛道」,并且确定「更大的战略目标」。
风暴期的团队已经有一定体量,人数因公司团队情况而有所不同,这个时候的团队「冲突往往很难自己解」,因为一旦涉及到所谓「团队利益」,很多人就会很容易失去冷静。
所以这个时候更需要一个好的leader「解决一些冲突」,把各个团队串联起来,避免团队各自为战,形成效率竖井,事实上风暴期是「很多创业公司的送葬场」。
在这个周期需要逐步考虑「数据指标建设」了,如果连数据采集都没做,下个阶段会出一些麻烦。
规范期造血能力
团队经历痛苦的磨合,开始进入规范期,这个时候团队之间已经找准自己的定位以及对方的价值,彼此间开启高效的合作模式。
之前良好的机制迭代,也形成了统一的文化,所以团队问题变得更可控了(未必变少了)。
合作共赢、配合执行成为团队主旋律,leader更多是参与决策,而不是主导决策,只有在一些比较胶着的情况才会推动问题解决。
这个时候,公司最大的任务是「增加造血能力」、和建立「跨部门协作的机制」。
这个周期是必须「建立数据指标的」,不然管理层容易抓瞎。
绩效期
团队最终阶段,我这边缺少经历无法建立认知,便不多说了。
分而治之的问题
「分而治之」是解决规模过大的良药,正如上图中的team小圆圈,多数公司都会分为事业部,聚焦到技术团队,他一般是按业务线或者按技术职能线划分(前后终端...)分为几个组。
于是管理整个团队变成了管理各个事业部;管理整个技术部变成管理各个小组,虽然会导致「屁股问题」,但管理难度会小很多。
这里最核心的问题依然绕不开:「CEO不可能承担所有角色(技术、财务)」,技术负责人也很难精通各个技术栈,那么各个陌生的部门、「陌生的领域如何管理」?
这个才是老板为什么今年开始关注数据指标了,因为公司已经大到他「看不清了」!
建立数据指标
数据指标是什么
实际推进数据指标落地可能非常费力,需要不停的「建立共识」,了解全貌可以更好实施:
团队膨胀到最终选择分而治之,「如何评价分而治之的效果」,这是产生指标的核心原因。
至于「数据指标」是什么,以一个案例开始:
因为产研是公共资源,所以会存在「业务方抢占产研资源」的现象,而「限制创造力的内部竞争会导致制度性的内卷」,于是我们提出谁使用、谁买单的规则,这里对产研也需要回答一个问题:
产研团队对于公司的意义是什么,如何评价产出。
角色定位决定关注点,我们直接聚焦到研发团队,研发团队对于公司的意义是什么,如何「评价产出」;这里再进一步,各个技术栈团队的「产出如何评价」?
这里还可以换个问法:
我们的团队与外包团队有何不同,我们与其他研发团队的差异是什么,如何评价优劣
技术负责人应该如何评价各个单元组的产出,可以主观的定性,却需要「客观科学的定量」,于是便「需要建立数据指标」。
在具体实施落地的时候,很多同学不容易理解数据指标是什么,认为「数据指标在瞎折腾」。
不能理解这块的用意,内心抵制是不容易做好的,就算做好了也可能只是运气好(蒙对了,反而会埋下更大的坑),这里跟大家强调下,数据指标至少有两个作用:
1 想不出来数据指标,说明是对这块事(团队要做的事)没有一个清晰的认知
2 想得清楚数据指标,却做不出来,说明对整个团队缺少掌控,不能推动落地
不能建立数据指标,根本没法做「数据驱动」,看似简单的数据指标把团队是否在「裸奔」指了出来,是因为「惯性」还是向前跑,一目了然。
综上,数据指标其实是想真实反应我们的团队是什么状态,我们做的事是什么状态的一个「指向标」。
究其原因,组织执行力、产品健康度需要某种程度的量化,数据指标的作用从更宏观的角度看是这样的:
数据指标提供了「航行方向」,「北极星」的作用,这里再来一张图,看看数据指标在全局中的角色:
其中牵引指标就对应我们的业务数据指标,牵引指标不健康的时候可以预警是不是团队方向跟目标走偏了,leader要考虑调整目标还是修正团队方向。
案例·比价模型
先回答上面的灵魂一击:你的研发与外包团队有什么区别?一般来说研发团队的工作是“做项目”,其工作产出物是“代码”,作为偏执行团队的评价指标一般是三个:
1 成本指标
2 过程指标,执行效率
3 结果指标,交付质量
粗粒度的表格可以是这样的:
在数据准确的情况下,上述评价模型基本是可用的,只不过大概率拿不到真实数据,所以建立指标的「最难部分一直是数据获取」。
案例·质效指标
质效相关指标作为了衡量整个研发团队的指标被保留下来,持续迭代后变成了这个样子:
实际执行效果如图:
上述是周常规指标,每周周会我们会过这个数据,除此之外我们还有一个项目维度的指标,大概是这样的:
这个表格用于每个项目结束后复盘的重要参考材料。
上述是比较通用的质效指标,各个业务团队皆需要遵守,是兜底的存在。
具体到前端团队的数据指标、后端团队的数据指标、NA团队的数据指标,又会有很大的差异,端更倾向于体验指标、后端更倾向于稳定性指标。
案例·数据使用
建立数据指标,才能存储正确的数据,随后数据便可以产生价值了,这里的数据使用依旧是聚焦到研发领域:
1)「周常规数据」
比如我们周会都会过上一周质效周报,里面数据一旦有波动,就一定是某个团队出了问题,这里首先暴露了该团队这个周期内可能的问题,我们可以继续深入这个团队,看他这个周期是什么因素导致了指标不达标,再协助做整改即可。
某些程度来说,数据指标有「紧箍咒」的作用,没有团队想在「会议上」被人「复盘」,于是平时就会刻意的做建设,那么团队整体的产出就有「基础的保障」。
这里要注意的是,大家都可能出问题,万不可以某个团队指标不合理大做文章,成为喷子
2)「项目维度指标」
我们记录了项目维度的执行指标(如上图),在对「问题」项目,「典型」项目复盘的时候,我们发现这次项目过程中,产品与研发的合作十分糟糕,battle不断,对比数据一看,发现需求更改10次,于是便更需要产品同学做复盘;
我们发现技术侧耗时远远超出平均项目时间,跟进去一看发现原来测试环境泳道出了问题,项目的执行测试环境,不断的被其他团队修改,那么就该在测试环境治理一块做工作......
业务指标
可以看到,上述全部是通用的技术指标,事实上公司关心的是业务指标,每个公司会有一套「公司级数据指标系统」,我思考很久,还是决定放出一个大概草图:
结语
无论个体、单元组、团队都需要切实了解「自身状态」如何,为了更具象的描述这种“状态”,我们要求每个单位需要提出「自己的衡量指标」,这个就是我们所谓的「数据指标」。这里要注意一个点:
数据指标绝对不是leader独立提出来的,财务的数据指标需要财务提出、产品的数据指标需要产品提出、研发的数据指标需要研发提出,谁了解谁提出。
leader更多的是考察其科学性,leader缺少认知、信息很难提出系统的指标,但总会有几个行业好友,所以各位不要忽悠他
「建立数据指标——>数据开始有指导作用——>数据可说话——>数据驱动」
这是每个团队都想要达到的状态,他需要每个“山头”的leader都对自己的领域有足够的认知,提得出相关指标;
还需要切实的落地指标记录,到最后的应用指标,这个要求其实比较高,那么有没有相对简单的办法可以更好的建立指标呢,事实上可能还真有:
在某种意义上说好的OKR实践,会经历完整的指标建立过程,但今天不展开了。
至此,我们回答了上述问题:
因为团队分而治之导致的部门黑盒验证,老板需要能理解的数据指标,判断他们的工作情况;
各领域负责人需要提出合适的指标,并且不要去忽悠老板,他会问题他牛逼的顾问的......
好了,今天的分享就到这,希望对各位有用。「原创不易,多多分享」
想要更多交流可以加群: