美团与字节的管理15：字节怎么让中后台研发接地气？

在我经历过的公司，常见的中后台技术人员，总是更追求技术，做出来的功能们，总是不好用……
你要是提个bug，反而会被说“我的功能没问题！是你不会用！”

字节的同学，却说他们的中后台研发“特别接地气”，内部产品（比如飞书）也“特别好用”。

字节是怎么做到的呢？

1、
其实，本质上是考核评价方式的问题。
这个考核方式，决定了业务部门普遍接地气、而中后台研发常常不接地气。

因为，业务部门考核的是业绩。
数据不会说谎，不接地气、不了解用户，不可能做出好的业绩。

而到了中后台，你的工作到底有没有价值？有多少价值？
远不像运营、销售那么容易度量，就只能卷汇报、卷ppt ——反正老板也不会用系统！也没有考核数据！汇报过关，就万事大吉。
在加上，很多技术同学的技术追求远大于业务追求。
有时间，宁可研究技术，也不乐意了解需求和用户。
自然不接地气。

2、
字节解决这个问题的方法，也简单。
谁说中后台同学，就不能用数据指标来考核呢？

比如，
你要是做后台系统，做得好，内部用户就会多。
那就可以考核内部用户的使用量。

你要是开发一个公共服务，你得有接口、得被调用吧？
那就可以算调用量。
调用量到顶了，还可以计算调用的稳定性、响应速度等等。

有些内部产出，实在找不到被使用的数据，也有办法！
比如，有人搞了个代码模块。
所有人遇到同样的需求，都能复制他的代码。
没有用户、没有接口，也有办法！
别人拿到这段代码，总得看文档吧？遇到了问题、总得和设计者飞书请教一下吧？
那就可以度量了。
你的文档，看的人多不多？
大家看完，赞不赞？
遇到问题找你，飞书聊天最后是“感谢大神”还是骂娘？
这些，都可以是评价工作的指标。

于是，
在这个指标激励下，甭管你在前台还是后台，在哪个岗位，都得接地气！
你技术再牛逼，做的事儿不符合同事们的需求、没人用也白搭。
原先是同事，有了考核数据，就正式变成了“用户”。

就必须找用户了解需求。
不只了解需求，功能做出来了，还得自己推广。
求着运营、客服、其他的技术团队们用起来。
有用户提bug，也不敢不改，不改会失去用户。
于是，
中后台研发们，也像业务团队一样，被市场需求驱动了起来。
开始像业务部门一样接地气。

3、
其实，大多数的工作都是一个道理。
找到某种客观度量标准，让客观标准压倒一切，团队就会好好干。
当没有客观标准时，
全看管理者主观印象，员工们就只能拼汇报、拼讲故事。

而常常没有标准的原因——不是这个标准找不到，而是“没去找”！
只想着干活儿，忽视了标准。

而要想让公司里所有人都接地气？
只需要管理者在评审每个方案时，不断重复问两个问题：
第一，你做的事儿，会有什么价值？
第二，这个价值，如果实现了，可以怎么被看见？怎样被度量？（在数据驱动的字节，就是会影响什么数据？）

大多数的工作，
只要你问这两个问题，总能找到客观的评价方法——
产品是通过实现用户价值实现利益的。
于是，产品价值要么体现在用户规模里、要么体现在收入利润里。

技术要么是直接服务用户、要么是服务那些为用户服务的人。
所有技术的价值一定是用户价值的向后传递。
于是，价值要么体现在用户里，要么体现在内部离用户更近的人的使用和反馈里。

只要找到了客观评价的办法，自然就会驱动每个人关注用户、关注需求。

只不过，大多数管理者都只布置工作。
从不问这两个问题。
于是，中后台总是不接地气、向上管理也总是比做好业务划算。

4、
但是，字节让中后台也被数据考核之后，也会遇到问题——
很多基础的技术建设，要想见效，需要的时间太久了。
甭说一两次OKR周期看不到影响，可能两三年都看不到影响。
这样的项目，就很难做起来。

怎么办呢？
在字节要想做这些事儿，起吗要先保自己OKR 过关。
对于有些有追求的技术团队——
会先规划好“靠哪几件事儿交数据”。
这些为了OKR做的事儿，会占掉70%的精力。
剩下的时间，再去做那些自己觉得该做、而实在长期的事儿。

不过，这不是“建立客观标准”的锅。
是OKR的周期太短、考核的压力实在太大的问题。
所以，字节在这几天，将过去2个月的OKR周期延长到了3个月，希望能缓解这样的问题。

这是系列连载“美团与字节的管理”的第15篇，下一篇我们聊聊：那么抠门的美团，为什么在某些部门，要开出市场上最高的工资？