五位技术领导者的文化构建实战
作为技术领导者，构建良好的工程师团队文化可能是你绕不过去的一个课题。今天我们就请 5 位过来人，讲述他们的文化构建实战经验。当然，由于每个公司对工程师文化的理解不同，这些经验不一定能拿来就用，但至少可以提供一种思路。
我 35 岁前主要钻研技术，近几年逐步转向管理，带过几十人至一两百人的研发队伍。在最近的管理工作中，总结并归纳了几个可以贴到墙上的大字，即 “共治分享自视一起拼，简单有效快”。
共治：共治就是部门要共同治理，自我管理和部门管理一起进行，每个人要管好自己，部门的共治我们希望能转化为个人的自治。具体形式有部门共治文件夹、轮值会议等；
分享：因为专业所以自信，因为自信所以开放，因为开放所以分享。具体形式有周五分享日、书斋建设；
自视：自视就是自我察觉，双眼反向注视着自己。对公司和他人的要求转化为对自己的要求，少一些抱怨，多找一些方法，如乐捐；
一起拼：一起拼就是团队要一起拼搏，一起奋斗，一起喝酒、一起爬山，如户外、项目管理；
简单有效快：把复杂的事情变简单，追求事物的本质，这就是简单有效。“快”是指快速地交付，快速响应业务的需求，如站立式会议等。
当我们确定了这个阶段的部门文化后，团队氛围有了较大的改善，从死气沉沉到激情活力，从固步自封到好学分享，从互相推诿到勇于担当。在后期的几个大项目中，项目的成功显得自然得多，特别在新员工的融合上，成本也低得多。
文化的构建并没有想象的那么难，也没有多少高大上。它也需要脚踏实地、土了吧唧，一步一步埋头干。先有管理工具、制度和行为措施，然后予以贯彻，形成一种习惯，最后才是总结提升。
我们不能简单的参考大公司的做法，或者管理书籍上挑选几个词语，然后领导喊两声或挂在墙上。构建团队文化的过程就如同花朵或生物一般，需要播种、栽培，然后才能收获。这样「长」出来的文化，才能管人做事，深入骨髓、改变思想，才能成为公司或团队的核心竞争力。
关于如何建立工程师文化，我们付钱拉团队的经验是，最好的方式就是把业务和技术结合起来，通过技术降低业务的难度，从而提高学习的时间。分享技术，让代码和思想都能得到升华。
我们在团队内部通过工具化，框架化和实时重构，本质上简化了我们的运维成本，同时也提高了大家对技术的钻研兴趣，用学习的技术解决实际的生产问题。另外还有挺重要一点就是平时工作中多鼓励大家钻研技术，鼓励刨根问题，鼓励知识共享。鼓励思维创新，鼓励组建技术小组，攻克技术难点。开展黑客马拉松，强调竞争，合理奖赏。另外在工作之外，会组织一些游戏竞赛，一来放松心情缓解疲劳，二来团队合作增加彼此了解。
其实工程师文化就是一种放松的，自我驱动的技术文化，在这种文化下，通过成员的自我创新，通过技术手段，降低工作强度，优化业务数据，将技术与生产的需要相结合，并做到极致，从而使人在这个环境中得到飞速成长，团队也飞速进步。工具化，框架化强调 DRY 原则，避免重复，提高工作效率。实时重构避免代码质量恶化，重新设计提升代码品质。技术氛围创造来良好的环境，促进工程师文化持久留存，人人受益，团队才会受益。
作为一个核心团队来自于谷歌的初创公司，出门问问的公司文化很大程度上受到了谷歌工程师文化的影响。其中我印象最深的是，谷歌对代码质量的要求和追求到了一种近乎狂热的程度。
那我们怎么在一个小的 Start Up 中间达到谷歌的代码质量呢？我有一些建议：
一定要坚持原则，坚持 Unit Test 和 Code Review 。
Start Up 的步伐、步调是非常快的，各方面的竞争也很激烈，你不快的话就会落后。在这种情况下的话，很多产品经理面对各方面的压力，可能会说“我只需要这个产品快速出来，我根本不 Care 你是怎么做的，你的代码质量、代码风格，Whatever，我不 Care 。” 但实际上，，从公司的长远角度来讲，你把基础框架搭好之后，对以后的发展、稳定都会有很大的帮助。因此，在很大程度上，要坚持 Unit Test、建立 Code Review 的机制，一定要保证你的代码是有一定质量的。
第二点是要拥抱开源。实际上，谷歌是一个非常大气的公司，它已经把很多很好、很酷的内部的东西都开源出来了，我们要做的话，就只需要把这些东西积攒在一起，然后搭建一套更适合于创业公司的开发环境。
很多时候，我们会面临一个问题，代码的第一个版本出来之后，我以后是在这个基础上修改呢，还是在一定阶段把它推翻了重来呢？
谷歌内部基本上都认为，没有什么代码是能活过超过 2 、3 年的，所以，会对代码进行推陈出新。实际上，在代码的推陈出新之间，会把以前没有考虑到的东西会做得更好，也会锻炼新人，然后学到更多东西。
拥有良好工程师基因团队的三点要素：
如何从一线的工程师转成技术管理者，对个人和工程师团队文化来说都是非常重要的一环。我非常看重的的一点是，技术公司的管理人员一定需要从技术第一线提拔而来，这样才能让公司保持工程师团队文化，而且这种文化才具有与生俱来的某种技术特性。
在我的定义和 FreeWheel 的文化中，转变为团队领导的人必须要在他的团队里具有最顶尖的技术水平，要能够服众。
我们的开放主要体现为在信息维度的充分共享和在思维维度的创造激发。整个公司发展中，技术层面和商业模式层面的信息，可以在领导层和员工之间做到充分的沟通和共享，使得全员在任务处理上能更好地把握整体方向、理清事情的优先级，做对公司最重要的事情。另外，大家做事情都是本着平等开放的原则，不会因为说话的人不同，就对他提出的问题或者方案有不同的态度。这样做的目的就是要激发大家的积极性，充分发挥每一位员工的创造力。
追求 Engineering Excellence，是近期 FreeWheel 整个工程师团队的最大变化。在公司整体度过了生存期的挑战并进入到加速生长期时，我们要关注的事情，不再是到处救火，而是要追求卓越， 要打造一个可以在未来几年里，支撑业务发展的优秀技术平台。 在这个新的目标下，FreeWheel 工程师团队也发生了不少变化，包括对 Full Life Cycle Engineer 理念的倡导，对 CI / CD（持续集成 / 持续交付）等高效开发流程的探索和精进等。
作为管理者，我们会忍不住像游戏一样去设计规则，但这是不可能的，我们也不应该这样做。我们应该去强调约束，定义规则的边界，确保规则跟约束没有冲突。
我们倾向于让团队成员自己以民主的方式形成自己团队的规则，我尽量不插手。当然，在团队发展早期，你也可以尝试为它设置一些规则，但你会发现这些规则很快就会被团队内部产生的新规则所替代。
有些公司比较看重员工的一致性，尤其是思想上的一致性，统一的价值观，这点我是不认可的，我觉得统一思想这件事毫无意义。所谓共识，大致有三个层次：
愿景。就是“什么该做什么不该做”。比如往页面上放广告，这事儿该不该做，大家会有自己的看法；
价值观。就是“应该怎样做事”，在愿景之下，通过规则和约束体现出来。我觉得价值观不是贴在墙上的东西——越是贴在墙上反复念叨的，一般都是越没有的东西；
规则与约束。这是在行为层面。规则是一个很容易被复制的东西，比如开发流程，你看到大家都用 pull request 提交，你也很容易跟着这样做。在这个过程中，价值观得到了强化。
对于我来说，我更愿意大家在行为上一致，而不去追求思想上的一致。规则创建的过程应该是民主的，这个过程需要有冲突，有碰撞，有妥协——因为大家的思想并不一致；而规则一旦建立，则人人遵守规则。
以上就是五位技术领导者在实践中总结的“工程师文化”的内涵及实施经验，可以看出来，不同公司的工程师文化确实存在比较明显的差异，相信也是在实践中慢慢演化而来。希望你也可以通过思考与实践，在你的团队中构建起最适合的文化。