工程师持续招募中，一起来滚个大雪球

从事互联网行业的技术工作者最近十几年来可以说是时代的宠儿，走在时代的浪尖，各类媒体也是大肆宣传国内外的明星互联网公司是如何溺爱工程师的，什么一万块的座椅，取之不尽的零食，各种活动，飙升到天的薪资，甚至是一夜暴富的神话。似乎有了这些元素一家公司就可以摇身一变，成为一家马上走向巅峰的企业了，身在其中的工程师也会有着无与伦比的优越感和自豪感，但是，等等，这些和工程师文化到底是个什么关系？

我虽然并不认为一家科技公司必须是工程师文化主导的，但是一家科技公司的工程师团队必须有自己的文化，对于一家科技公司的工程师团队来说如果没有对卓越的追求无论如何也不能称之为科技公司。

我认为，一个工程师团队的文化应该体现在这几个方面：

• 正确的价值观

• 完善的基础设施

• 惩罚和激励

价值观 

为什么要有价值观

价值观这个词可能有点容易被误读，从我的理解来说所谓价值观就是对待一个特定事情的观点，所谓价值观一致那就是我们对待某一个特定事情的观点是统一的理解是一致，进而不同的人在这个基础上所做出的行为也是一致的，不同的人之间可以非常容易的相互理解和沟通，即便有一定的不一致的想法也能很快达成一致。

如果不能在价值观上形成一致，很可能在行为上有非常的分歧，甚至南辕北辙的情况，如果一个团队都不能形成一个统一的价值观那么大家采取的行动可能很难被其他人理解甚至相互拖后腿，这对任何一个追求效率的团队都是无法接受的。

我们认为好的价值观

那么对于一个工程师团队什么样的价值观是好的呢？在雪球我们虽然没有把价值观贴在墙上，但是我们一直在践行着几个重要的价值观：主动、专业、效率、同理心。 

主动：我们希望每一个工程师都能主动思考自己的代码是不是还可以改进、监控报警是不是完备，线上会不会出现什么问题，产品设计是不是合理等等，只有一个人能主动思考这些问题那么他的工作才可能更完备不需要其他人帮他擦屁股，业务才可能有更好的发展，个人能力提升的也会更快。在雪球职位变化最快、负责的事情增加的最多、工资涨幅最高的就是那些主动跳出来承担各种事情并且能搞定的人，这样的人有很多。

专业：作为一个开发工程师，无疑必须具备相当的专业性，如果我们说主动性是态度的体现，那么专业性就是能力的体现，如果总是写出有 BUG 的代码，对使用的技术没有比较好的了解，那么态度就算再好也依旧是不合格的。

效率：作为一个技术工作者应该有强烈的意识去不断提高自己和团队的效率，比如使用更好的工具/编程语言/框架更快更好的完成任务；使用更好的工具进行生产环境的部署；使用更好的工具来协助我们进行项目管理等等，如果碰到一个问题首先想到要增加流程来解决问题那肯定不是一个最佳方式，应该用工具去完成这个流程的实现，因为工具更可靠更不易犯错误。雪球在特别早期就使用了 Node.JS / Docker / Scala / Go 这样的技术应用在生产环境，无一不是为了尽可能的提高我们开发、部署、运维的效率，我们希望尽可能的用有限的资源完成更多的事情，这就要求我们持续的提高效率。

同理心：作为一个产品/服务/API的生产者，生产出来的作品是要给其他人使用的，那么有没有站在使用者的角度去思考自己的产出是不是合理？有没有站在上下游合作伙伴的角度去评估他们为什么要会提出某一个要求？后端工程师有没有考虑过自己的 API 提供给前端同学是不是清晰、易用？在大规模团队协作中如果你能以这样的同理心去思考，无疑会让你的伙伴倍感舒心、可依赖。

完善的基础设施

为什么要做基础设施

这个世界上没有多少人真的愿意做重复性的工作，工程师这个群体更是这样的一群人，每天和机器打交道自然希望更多的工作由机器代为执行，这样可以大幅减少重复性工作的时间，也可以把人为导致的低级失误降低到最少。我觉得一个团队基础设施做的好不好的唯一标准就是工程师离开去了另外一家公司是不是会怀念前团队的工具：“现在公司的工具没有以前公司好用啊 ……”

要做什么样的基础设施

从互联网产品开发生命周期来看每个环节都很重要，文档管理、问题追踪、代码管理、持续集成、代码质量检查、移动APP打包、测试开发环境、部署上线、监控报警，这些环节中在市场上都有对应的工具，商业化的、免费的、开源的都有，其实重要的并不是哪一种工具比另外一种功能更多，而是要选择最适合自己团队的。如果现有的产品都无法满足需求那么我们就自研造轮子好了，其实工程师最喜欢干的事情之一就是造轮子了。

怎么做好基础设施

商业化产品：比如雪球团队内部文档管理用 Confluence，事件/BUG管理用 Jira，最早使用过很长一段时间开源软件 Redmine 但是功能上差强人意非常影响效率所以才决定彻底的切换。成熟的商业化产品无论功能还是体验都是很好的（当然请一定要购买商业软件的授权，作为软件开发者如果不尊重别人的劳动成果那么自己的成果别人也不会尊重的）。这个切换带来的效果可以说非常明显，使用 Redmine 后期大家都不愿意往里写文档了，现在看看 Confluence 上积累的文档可能是以前的十倍，每年新增文档 6千+，各种修改 5万+，因为实在是太方便了，早已经没有人抱怨文档不好编辑不好查看了。

开源产品：对于持续集成最常用也能完全满足我们需要的就是 Jenkins 了，我们根据可以根据需要增加插件或者自己开发一些特定的插件来实现某个功能，配合代码静态检查工具、单元测试覆盖率检测工具、自动打包脚本和自定义的流程可以保证我们的代码一提交很快就能找到打包好的程序来进行测试部署。

自研产品：早期我们也用一套统一的脚本命令行的方式进行发布，速度很慢偶尔还会出现各种误操作导致的错误，当时我们已经开始在线上使用 Docker 了（但是还没有任何自动化的编排系统），我们决定把手工的命令行转化成一个独立的产品，把脚本的功能和人工步骤固化在这个产品中，整合过以后的工具对于工程师来说非常简单使用，后端的代码一上传系统就会自动编译打包成一个 Docker 镜像，然后用户可以用一个 WEB 界面选择把这个镜像部署到哪个环境去。每天我们的部署任务都超过 100 个，完全由开发的同学自己执行。有不止一个离职的同学会来跟我说：“我们以前那个部署系统太强大了，好怀念。”

还有一个自研的例子，我们的监控系统实际上使用好几个开源组件加上自己的一些代码粘合，我们统一了日志格式、自动化了日志收集、自动化创建监控模板，相当于任何一个新的（微）服务上线，就已经有了基本的监控图表，想定制就直接创建图拖监控项上去，一个完整的 Dashboard 就有了！

惩罚和奖励 

每家公司应该都有常规的目标管理制度，比如 KPI，OKR 等等（雪球正在实施 OKR，以后机会我们还会分享雪球在 OKR 实施过程中的一些实践和体会），这一节介绍一下雪球如何专门针对工程师这个群体的一些惩罚和奖励措施。

除了绩效、薪资之外，大部分工程师其实对荣誉都是非常看中的，哪怕只是口头说一下可能也很满足，如果犯了错误自己都觉得抬不起头必须尽快去弥补并且以后坚决不在犯同样的错误。这都是特别可贵的追求上进的特质。

惩罚

雪球措施倒是很简单，每次出现生产环境的故障，我们会要求当事人解决问题以后，撰写一个详细的故障报告，分析清楚当时的现象，产生的原因，处理的措施，可以系统性进行改进的地方。我们希望每一次的错误都不重复的出现，故障报告发给全体团队成员希望其他同学也能吸取教训，并且一定要系统性的解决同一类问题，而不是头疼医头脚疼医脚。

当然这里还有一个特殊的规定，如果是一个低级错误，那么我们还要对责任人进行一定额度的罚款，罚款会做为某种奖励发放给工程师（下一节介绍）。怎么定义低级错误呢？有一下几种：

• 人为疏忽导致的错误（比如没有代码Review / 想当然没有问题也没有找其他人确认 / 有明确合理的文档标注而没有按照文档步骤操作 / 执行命令之前没有确认）

• 重复出现相同的错误（比如同样的或者同一个类型的错误出现2次以上）

• 未经过充分测试出现的错误（比如没有去想办法测试或者没有和团队充分讨论如何测试）

这种惩罚的目的当然不是为了罚款，还是希望把这些堪比剁手的错误牢牢记住不再重复犯错。

奖励

奖励的措施肯定要比惩罚多，比如我们鼓励大家在内部分享工作的心得体会、在技术社区/大会展示自己的工作成果，对于出来分享的同学我们会用低级失误的罚款来进行奖励。还有公司每年年终总结会上也会颁发当年的技术进步大奖，奖励通过技术创新来提高产品系统效率、稳定性的团队。我们还会不定期的组织 Hackathon 的活动，调动大家积极参与产品、技术创新，每次活动还会评出各种奖项，颁发奖品，其中有一些活动的成果已经成功应用到了生产环境当中。

其实这些奖励从纯粹的金钱价值来说并不是很多，但是给了我们的工程师一个展示自己，建立自己影响力，获取荣誉的方式，大家都乐此不疲。

写在最后

所谓的工程师文化并不是高喊着口号，走走形式就可以让所有人可以感受到的，是需要通过我们日常工作中持续地一点一滴来渗透，怎么让工程师干活干的爽不想离开那么我们就这么做。

还有一件事

雪球的工程师团队在招聘，期待你的加入！

招聘信息如下：

高级Java开发工程师：项目经验广 热衷技术栈 Java老司机 

推荐算法工程师：玩转数据建模 执迷个性推荐

产品经理：调研需求 设计产品 让创造发挥价值

测试工程师：挖掘缺陷 懂得“防守”的攻城狮

用户运营经理：潜伏金融行业 了解用户需求 拉新留存小能手

品牌视觉/用户体验设计师：细节控 灵魂画手 审美达人 

客户关怀专员：集互联网 金融 客户服务为一身的贴身助手

广告销售经理：颜值担当 移动的直客资源库 

更多职位、更详细的招聘信息请点击“阅读原文”查看。