管理者，别总以为自己比员工聪明

创业公司，老板对技术团队不满意，故空降来了一个职业经理人CTO来带队，并提了明确的要求，“必须要让不懂技术的人，看懂管理结果”，更具体的：要量化，要体系化，要有重点。

CTO针对老板提的三点具体要求，新官上任便烧了三把火：

（1）量化：设定北极星指标；

画外音：源自《增长黑客》。

（2）体系化：RFM模型；

画外音：常见的客户管理模型。

（3）有重点：分层管理；

一、北极星指标

空降CTO认为：技术团队为系统交付负责，产出的是代码，因此，可以以“代码行数”甚至“代码字节数”作为北极星指标，量化衡量技术团队，研发工程师的产出。

二、RFM模型

通过三个核心指标，建立模型，对技术团队进行管理：

（1）最近一次提交代码的时间 (Recency);

（2）最近一周提交代码的频率 (Frequency);

（3）最近一周提交代码的总量 (Monetary);

Recency

空降CTO指出：最近一次提交代码的时间更近的工程师，大概率是较好的工程师；连续几天没有提交代码的工程师，大概率在摸鱼。

Frequency

空降CTO指出：最近一周提交代码频率高的工程师，大概率是积极的工程师，满意度高的工程师，忠诚度高的工程师；反之，大概率在摸鱼。

Monetary

空降CTO指出：最近一周提交代码的总量大的工程师，根据北极星指标，是产出最高的工程师；反之，大概率在摸鱼。

三、分层管理

空降CTO指出，将上述三个指标，分别细化出01两类，又可以将工程师划分为2*2*2=8组，进行分层管理。

画外音：

R：近1远0

F：高频1低频0

M：量大1量小0

空降CTO指出：对于北极星指标M=1，即最近一周代码提交总量大的工程，应该重点关注：

（1）RFM=111的，是公司的重要价值员工，最近一次提交代码的时间近，代码提交频率高，代码提交总量大！

（2）RFM=011的，是公司的重要保持员工，其之前代码提交频率高，代码提交总量大，但最近几天没有提交代码，管理者应该重点与其保持联系；

（3）RFM=101的，是公司的重要发展员工，最近提交了大量代码，但提交频率不够，管理者应该重点培养这些潜力员工；

（4）RFM=001的，是公司的重要挽留员工，之前提交过大量代码，但最近提交频率和提交时间都不让人满意，管理者应该重点挽留这些员工；

“三把火”付诸实践半年之后，北极星指标急速提升，工程师们交付代码数量几何倍数增加；RFM模型，以及分层管理也卓有成效，员工们纷纷往RFM=111的优秀员工移动了。

公司老板对空降CTO非常满意。

只是… 仔细研究了一下工程师的行为：

（1）变量名，平均20个字符（字节多）；

（2）研发插件，每输入一个字符，ci一次代码（频度高）；

（3）研发脚本，每秒ci一次代码（时间近）；

（4）绝不封装函数，能copy的就copy（行数多）；

（5）…

管理者，是规则的制定者，别总以为自己比员工聪明，你考核的数据，会引导员工的行为，他会给你你想要的结果。

纯属戏谑，如有雷同，欢迎对号入座。

调研：

贵司如何？总不会是看工作时长吧？