新晋总监生存指南二——建立指标

Posted 叶小钗

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了新晋总监生存指南二——建立指标相关的知识,希望对你有一定的参考价值。

一、膨胀的团队、膨胀的复杂度

书接上文:新晋总监生存指南开篇之总监二三事

按照之前的逻辑:如果你想创造一个能够维持一定秩序、不会分解的系统,那么这个系统必然是一个开放系统,就需要为他注入能力,并让其在系统中流动以维持这种秩序。管理的动作就是为团队注入能量,能量停止系统就会开始退化,这种持续为组织注入能量的行为,正是领导力的核心。

以上的话比较晦涩,他要表达的意思是:团队一定会出问题。规模越大问题越多,并且问题会越来越愚蠢、越来越不可思议!

如果没有管理动作的介入,团队会变得十分混乱,效率接近为0,根据熵增定律,封闭的系统,最终会由有序变成无序。

这里举个简单的小例子,大家去食堂打饭,没人维护秩序会怎么样;增加规模,变成市民去火车站买票没人维护秩序会怎么样;持续增加规模,变成国庆期间外滩游客如果没人维护秩序会怎么样。

所以管理的核心其实是有效的解决团队的问题,保证他有效的运转,而团队不同的阶段(不同的规模)下他所产生的问题以及对leader的依赖是有所不同的,如图所示:

每个团队在形成初期,沟通往往是单向的,需要一个强有力的leader,成员之间了解度低,对环境乃至公司团队战略不清晰,很容易产生焦虑困惑和不安全感。

比如新同学是非常容易无所适从而导致离职的,这个时期主要需要解决的是两个点:信任与目标,即员工之间的信任问题,和明确团队的目标问题,这个可以由五维能力模型的战略入手。

这个时期的团队一般50人以下(更常见于20人以下),由leader凝聚起来,如果leader足够优秀,团队会非常有凝聚力,适合局部作战,打一些小战役,而随着团队发展,接下来就会进入风暴期。

由于团队规模变大,不可避免的团队和团队之间会产生合作,但是因为各个团队风格各异,冲突会因为文化、理念、利益、工种等问题不断爆发,这个时候我们主要解决团队之间的问题,这里除了机制解决以外,更好的办法是划分赛道,并且确定更大的战略目标。

风暴期的团队已经有一定体量,人数因公司团队情况而有所不同,这个时候的团队冲突往往很难自己解决,因为一旦涉及到所谓团队利益,很多人就会很容易失去冷静,所以这个时候更需要一个好的leader解决一些冲突,把各个团队串联起来,避免团队各自为战,各自埋怨产生内耗,形成效率竖井,事实上风暴期是很多创业公司的送葬场。

团队经历痛苦的磨合,开始进入规范期,这个时候团队之间已经找准自己的定位以及对方的价值,彼此间开启高效的合作模式,之前良好的机制迭代,也形成了统一的文化,所以团队问题变得更可控了(未必变少了),合作共赢、配合执行成为团队主旋律,leader的更多是参与决策,而不是主导决策,只有在一些比较胶着的情况才会推动问题解决。

团队最终阶段,我这边缺少经历无法建立认知,便不多说了。

分而治之是解决规模过大的良药(正如上图中的team小圆圈),多数公司都会分为事业部,继续将关注点聚焦,技术团队一般是按业务线或者按技术职能线划分(前后终端...)分为几个组。

于是管理整个技术团队变成了管理各个小组,这样虽然会导致“屁股问题”,但管理难度会小很多。这里最核心的问题依然绕不开:CEO不可能承担所有角色(技术、财务),技术负责人也很难精通各个技术栈,那么各个陌生的部门、陌生的领域如何管理?

二、为什么要建立数据指标

实际推进数据指标落地可能非常费力,需要不停的建立共识,了解全貌可以更好实施,所以我们首先介绍团队膨胀到复杂度增加,并最终选择分而治之的方案,至于数据指标是什么,我们以一个案例开始:

因为产研是公共资源,所以会存在业务方抢占产研资源的现象,而限制创造力的内部竞争会导致制度性的内卷,于是某一天老板提出谁使用谁埋单的规则,产研刚以为可以少做一些低价值需求后,来了一句神来之笔:

产研团队对于公司的意义是什么,如何评价产出。

角色定位决定关注点,我们直接聚焦到研发团队,研发团队对于公司的意义是什么,如何评价产出;这里再进一步,各个技术栈团队的产出如何评价?

虽然当时的真实反应是:艹!又要做一堆无效的作业去应付这莫名其妙的疑问。但如果细细思考,这里却触发了本质问题:

我们的团队与外包团队有何不同,我们与其他研发团队的差异是什么,如何评价优劣

技术负责人应该如何评价各个单元组的产出,可以主观的定性,却需要客观科学的定量,于是便需要建立数据指标。

然后在具体实施落地的时候,很多同学不容易理解数据指标是什么,认为“数据指标”在瞎折腾,不能理解这块的用意,内心抵制是不容易做好的,就算做好了也可能只是运气好(蒙对了,反而会埋下更大的坑),这里跟大家强调下,数据指标至少有两个作用:

1 想不出来数据指标,说明是对这块事(团队要做的事)没有一个清晰的认知

2 想得清楚数据指标,却做不出来,说明对整个团队缺少掌控,不能推动落地

不能建立数据指标,根本没法做数据驱动,看似简单的数据指标把团队是否在裸奔指了出来,是因为惯性还是被动向前跑,一目了然。

综上,数据指标其实是想真实反应我们的团队是什么状态,我们做的事是什么状态的一个指向标。究其原因,组织执行力、产品健康度需要某种程度的量化,数据指标的作用从更宏观的角度看是这样的:

 

 

数据指标提供了航行方向,北极星的作用,这里再来一张图,看看数据指标在全局中的角色:

 

 

其中牵引指标就对应我们的业务数据指标,牵引指标不健康的时候可以预警是不是团队方向跟目标走偏了,leader要考虑调整目标还是修正团队方向。

三、研发数据指标

3.1 比价模型

先回答上面的灵魂一击:你的研发与外包团队有什么区别?

一般来说研发团队的工作是“做项目”,其工作产出物是“代码”,作为偏执行团队的评价指标一般是三个:

1 成本指标

2 过程指标,执行效率

3 结果指标,交付质量

粗粒度的表格可以是这样的:

  你的团队

竞品团队

成本

人均成本

   

人力成本

   

维护成本

   

交付质量

过程BUG数

100(个)

冒烟通过率:90+%

 

上线一月BUG数

3(个)

 

安全性

 

事故处理能力

 

交付效率

人日(单位)

   

在数据准确的情况下,上述评价模型基本是可用的(只不过大概率拿不到,所以老板的问题大概率还是瞎扯淡......)

3.2 质效指标

事实上比价模型被作为一个作业交差了,但其中的质效相关指标作为了衡量整个研发团队的指标被保留下来,持续迭代后变成了这个样子:

 

 

实际执行效果如图:

 

 

 

 

上述是周常规指标,每周周会我们会过这个数据,除此之外我们还有一个项目维度的指标,大概是这样的:

 

这个表格用于每个项目结束后复盘的重要参考材料。

3.3 其他指标

上述是比较通用的质效指标,各个业务团队皆需要遵守,是兜底的存在。

具体到前端团队的数据指标、后端团队的数据指标、NA团队的数据指标,又会有很大的差异,端更倾向于体验指标、后端更倾向于稳定性指标。

而业务团队的数据指标提取就“奇妙”了,除了通用的质效指标需要遵守,还需要侵入业务,而这个数据指标又不能是诸如订单量之类的业务指标,所以纯业务团队的研发数据指标,很长一段时间我也没想明白,后来回归本质,我认为依旧需要在效率和质量上做文章。

其中效率可以具体细化为很多组件化工具的建设,技术升级,这里最终会反馈到整体的效率指标提升,但如果单项的工具建设,由于耗费人力,可能还会在某个时间段降低效率,这里取舍需要leader自己判断,比如测试环境治理要不要做,需要付出什么成本,能达到什么效果,这些都需要决策。

业务质量部分可以更多的考虑业务埋点,比如P0页面乃至接口的监控,这里要达到的效果是,大流量场景下,一旦某个用户触发了边界场景,这个是有预警的。

关于业务侧的技术类指标问题,我认知有限,如果大家有什么建议,请不吝赐教

最后,数据团队、工程团队、产品团队的指标各有不同,大家可以自由补充。

四、数据的使用

建立数据指标,才能存储正确的数据,随后数据便可以产生价值了,我们这里的数据使用依旧是聚焦到研发领域:

1)周常规数据,比如我们每次周会都会过上一周质效周报,里面数据一旦有波动,就一定是某个团队出了问题,这里首先暴露了该团队这个周期内可能的问题,我们可以继续深入这个团队,看他这个周期是什么因素导致了指标不达标,再协助做整改即可。

某些程度来说,数据指标有“紧箍咒”的作用,没有团队想在会议上被人“复盘”,于是平时就会刻意的做建设,那么团队整体的产出就有基础的保障。

这里要注意的是,大家都可能出问题,万不可以某个团队指标不合理大做文章,成为喷子。

2)项目维度指标,我们记录了项目维度的执行指标(如上图),在对“问题”项目、“典型”项目复盘的时候,我们发现这次项目过程中,产品与研发的合作十分糟糕,battle不断,对比数据一看,发现需求更改10次,于是便更需要产品同学做复盘;我们发现技术侧耗时远远超出平均项目时间,跟进去一看发现原来测试环境泳道出了问题,项目的执行测试环境,不断的被其他团队修改,那么就该在测试环境治理一块做工作......

诸如此类

3)周期内某业务线整体质量复盘,大概是这样的:

 

 

四、结语

无论个体、单元组、团队都需要切实了解自身状态如何,为了更具象的描述这种“状态”,我们要求每个单位需要提出自己的衡量指标,这个就是我们所谓的数据指标。这里要注意一个点:

数据指标绝对不是leader独立提出来的,财务的数据指标需要财务提出、产品的数据指标需要产品提出、研发的数据指标需要研发提出,谁了解谁提出,leader更多的是考察其科学性(leader缺少认知、信息很难提出系统的指标,但总会有几个行业好友吧)

建立数据指标——>数据开始有指导作用——>数据可说话——>数据驱动,这是每个团队都想要达到的状态,他需要每个“山头”的leader都对自己的领域有足够的认知,提得出相关指标,还需要切实的落地指标记录,到最后的应用指标,这个要求其实比较高,那么有没有相对简单的办法可以更好的建立指标呢,事实上可能还真有:

在某种意义上说好的OKR实践,会经历完整的指标建立过程

所以下次,我们一起学习下OKR工具的使用,关于数据指标一块的浅薄的认识就到此,希望大家多多讨论。

以上是关于新晋总监生存指南二——建立指标的主要内容,如果未能解决你的问题,请参考以下文章

随手记录生活和工作

随手记录生活和工作

数据团队总监生存指南

技术管理进阶——技术总监的第一要务

新晋总监生存指南四——项目执行指南,如何挽救混乱的项目

新晋总监生存指南五——人才运营机制,技术团队如何解决造血能力