这几天微信价值观、百度价值观满天飞。所以我也来说说研发文化这个虚东西怎么落地。否则，价值观只能被挂在领导嘴上。

我在前几家公司任职CTO时都推行过研发文化。主要推的三个文化就是：工具文化、代码文化、数据文化

一、文化提出

为什么推着三个文化？推这三个文化的初源是什么？

1、工具文化提出的初源：

1.1、很多人写代码，都是COPY、修改。但引发的问题就是：COPY源的一些代码没有删减干净，致使异常触发，致使代码难以被新来的人看懂为啥会写这些代码

1.2、有规范，但很难被大家记住，并统一按规格全息落地执行。所以需要把规范转换成可生产过程中使用的工具

2、代码文化提出的初源：

2.1、过去大家总是花很多时间空对空讨论、对着想象的设计写成的文档进行反复的层层道道评审，最后花了大量时间做出来的开发终于发版了，用户一试用发现和自己最初讨论的想象的东西根本不一样，于是又进入新一轮的空对空讨论、想象性设计文档、赶工的开发和漫长的严谨的测试。

为啥不去先做个原型大家先来给大家一个直观呢？有人又说了，原型代码在正式开发时扔掉按照商用代码重新架构设计重新开发呢，还是做商用产品时就在原型代码上继续修改呢？

2.2、大家过去做项目总结，都你好我好大家好。即使开bug分析会，也是一条条看，然后当事人回忆根源，然后安一个改进措施，就算把bug分析改进会这个事糊弄过去了。大家根本不打开代码来亲自看亲自找根源，都凭当事人主观自己判断，而当事人的记忆性、主观判断能力，都参差不齐。这不行

3、数据文化提出的初源：

3.1、过去销售、实施、客服、产品、开发、测试，各说各有理，讨论会上绘声绘色的讲某个具体客户有某个具体不爽的使用场景，企图来证明这个问题很重要很严重，需要立即处理。其实事实上是不是如此，根本没有多人佐证这是事实。那就看谁会说了、谁会现场灵机应变了。

所以我提了出来，到底需求是不是普遍的，到底问题是不是常犯的，拿数据来证明。

但是，三个文化是提出来了，也在各种场合各层次员工群体中反复的宣讲了，也事对事及时提醒了，也拍桌子了，但有个毛用。

看来需要实措施才能落地虚文化。

二、工具文化的关键落地措施：

1、明确定义Leader的工作职责就是：工具/模板/代码框架/规范/高效协同流程的制定和推广落地应用；实现方案总体设计与把控；团队实现分工分任务、整体推动与协调；团队项目复盘总结、经验知识分享传播、新人指导。

过去是缺乏高级程序员和Leader，Leader实际上是高级程序员，但因为一个团队总需要一个头，于是他也是Leader。Leader和高级程序员融为一身，平时主要做项目中最核心的模块，从设计到开发全部搞定，最难的异常分析、修改也是他一个人搞定，其他人都搞不来。这就出现了他是瓶颈，他是最忙的，中级程序员都是熟练手，新人没人指导成长缓慢。

这样职责明确定义后，Leader就干这些事，本来高级程序员要做的最核心最难的模块，分成两人配合：Leader设计和实现代码框架，中级程序员来填具体细节实现代码。

2、定义Leader的KPI：专门有一项是工具/模板/代码框架/规范/高效协同流程的制定和推广落地应用的情况怎么样，专设KPI

但这个KPI是个定性的分数区间，由他的上级来打分。但上级打分这样的方式不好。我本来是希望让他的下级来评，但被总监级、以及HR以评价太复杂、大家工作太忙为由而阻止了。

该不该设KPI，怎么评价，谁来评价，希望大家能给我一些好建议

3、榜样推广、奖金激励：KPI是一方面，我也设了软性的激励手段。如：公司内网博客邀请他写总结文章，在研发电子期刊上对他和他的工具模板成果进行介绍与推广，在公司大讲堂上分享他的成果使用方法。而且设了奖金奖项，每个季度都有奖金和奖品。

二、代码文化关键落地措施：

1、Code Review会：

过去做Code Review，是Leader偶尔做不固定做，不像国外软件公司，代码Check进主库前必须Leader或同级来交叉做Code Review，在中国这行不通。而且过去也是某些Leader靠自己对自己团队的自我期许要求做，有的Leader对自己团队的产出要求高，他就做，有的Leader是赶活交差他就不做。

我曾经也想把CodeReview的职责安给Leader，但是做不到啊。

于是我想了一个办法，让Leader带着大家做CodeReview。而且是从本月或上月自己团队犯的最严重的一个错误BUG入手，打开代码，大家一起，一起来过代码，大家一起来找问题根源，大家一起来讨论改进措施。

这样做CodeReview，目的就不是检查代码质量了，也不是找bug根源了，而是Leader和大家一起，拿着真实代码，拿着真实问题，来一起讨论代码质量的提高。这本质就成了团队学习提高会了。这个方法非常有效，对大家自我的警醒促进作用也非常的大。

我还制定了固定制度：每个月必须留出两个半天，来做团队学习会。而做团队学习会，可以是CodeReview、可以是项目知识提前学习、可以是团队经验总结分享。这样就避免了有的团队留住时间瞎做团队学习，因为曾经出现过有的团队一开始做团队学习会，上来就搞了一个读书心得分享会。这就有些脱离具体生产了。

三、数据文化关键落地措施：

1、研发开放需求系统、开放bug系统：

需求、bug，过去真是来自各个部门各个渠道。有销售、市场、咨询、实施、客服、运维、区域...，有当面说的、邮件说的、电话说的、微信QQ说的，有在各个场合下说的（开讨论会、在客户现场、日常使用的时候...）。

到底哪些需求被人们反复提，到底多少人提，是哪些客户提，到底问题有多严重，现在有了统计。

现在再制定研发计划、放入研发需求，就不会谁嗓门大、谁跟谁关系好、谁能说会辩，而是看库做统计。

2、开发底层埋点功能：

提需求这事吧，和人有关。有的人墨迹、有的人大方，有的人希望自己被关注，有的人希望设坎卡别人，都各有各的屁股各有各的利益想法，但他不会光明正大的说出真正他想要的目的，而是包装以光明正大的理由让你去修改，往往产品经理和程序员不省人事背后的复杂，按需求按事改，改来改去还不满意。很多时候我们急着赶着开发完，后来这个功能他们也没用多少次。

所以我就着手平台研发，开发底层埋点日志框架，自动记录我们想跟踪的数据，比如功能点使用量、业务处理平均时长、数据变更量、数据增长量等等。根据统计对比来看我们辛辛苦苦做出来功能是否被真的业务利用上了，是否加快了他的工作效率。