有技术导向的价值观,是保持好的技术氛围的最关键的事情。一个公司要想有较好的技术氛围,首先从最高层开始就需要重视技术,尊重工程师。如果连CEO都认为工程师只不过是用来实现产品需求的资源,那么技术团队的负责人不管怎么做,也不可能保持住技术氛围的。

这里说的尊重工程师,不是说给高薪之类的,而是说理解工程师的思维方式和做事方法,用客观的、有逻辑性的方式来带领团队。比如重视数据、使用 A/B test 等方式来辅助决策、信息公开透明、不随意更改需求、开发周期主导权由工程师把握等。鼓励工程师对产品发表意见甚至介入决策过程也是很好的实践。

自上而下的推行技术平台化建设、推行DevOps、推行自动化构建、测试和部署流程。这几样事情虽然不直接产出产品,但可以显著提高团队的开发效率和技术水平,以及能够提升开发者为自己的产出物质量负责的意识,这也是一个好的技术团队必要的素质。但是如果没有管理者的大力支持,靠平级推广,难度就要大很多。

在豆瓣的一个很好的实践就是很早就建立了技术平台团队,这个团队从被产品推着跑的重压下解脱出来,专注于技术能力的升级和基础组件的维护。因为有这个团队的存在,各个产品线可以保持相似的技术栈和开发方式,在基础组件升级换代的过程中也可以避免出现新旧版本混乱的情况。同时,由于脱离了产品压力,这个团队可以有更多的时间来考虑精益求精的技术问题,可以持续不断的推动整个公司的技术氛围。

管理者不断向团队提出更高的技术要求,提高技术挑战度,可以促进技术氛围。对于性能提升、对于成本控制、对于效率优化、对于运维友好度,这些技术要求会持续不断的激励团队向更高的地方走,从而带动整个团队技术水平的不断提升。

分享是快速交流思想的一种手段。鼓励分享可以使得技术讨论的气氛活跃起来,碰撞出新的想法,也能更容易让优秀的人脱颖而出,成为团队中的hero。

无论在豆瓣还是在宜信,我都会要求团队成员每周轮流做一次技术分享,话题不限,但必须是技术相关。这是强制的,会迫使每个成员都意识到不能只满足于完成工作内容,学习也是非常重要的。这可以使得团队主动的去跟随技术趋势,同时一个人的研究方向可以在分享时传达到团队成员,形成讨论,甚至直接可以应用到工作中。

除了这种比较重的强制分享机制,还需要为团队成员提供轻量通畅的分享交流渠道,当任何人发现一个有点意思的信息时,都可以没有心理包袱的分享出来。在豆瓣我们用的是自建IRC,在宜信使用Slack和Bearychat。这种基于主题聚合的聊天频道的设计,可以鼓励交流,同时不会对正在专心工作的人产生干扰。

代码也需要分享,分享的手段就是 code review。早期豆瓣采用的是投影代码到墙上讲解这种比较重的手段做 code review ,虽然由于效率问题只能 review 部分代码,但是所幸的是我们一直坚持了下来,并且不断设法提高效率,尝试了各种工具。在把代码仓库从 svn 切换到 git 之后,几乎所有团队都立刻接受了 github flow 的工作方式,采用 pull request 作为 code review 的手段,迅速提高了 code review 的效率和流程通畅,基本可以做到覆盖所有代码变更了。

code review 的好处非常多,对技术氛围而言,最大的作用就是培养每个工程师对代码质量的追求。写得很丑的代码在 review 时是会被无情抨击的,在来来回回的 comment 的过程中,整个团队对于什么是好的代码会慢慢达成一致,大家也会以写出好代码为荣。

多说一句,pull request 这种方式还有一个好处,就是打破团队间的壁垒。每个团队的代码都是公开的,如果你的工作需要别的团队修改代码,你可以直接 fork 一份改完发 pull request 过去要求 review 。这对促进团队间交流,提高跨团队工作效率,避免大公司病是很有益处的。

上面说的都是内部分享,对外的分享包括公司间交流、技术大会分享、代码开源等等。这些相信大家都已经深刻理解了可以带来的益处,就不多说了。

在一个工程师团队内,荣誉激励要比经济激励要有效的多,工程师最大的成就感就来自与自己的水平被同行认可。分享正是提供了荣誉感的来源。

对于架构师,在技术选型上有两种倾向:偏保守或者偏激进。偏保守的,会多选择已经经过多年使用,成熟稳定的技术,这样不确定性因素少,掉坑机率小。偏激进的,会多选择新出现的技术,因为新技术往往功能和性能上都更佳,可以更好更快的满足需求。

两种倾向各有优劣,我无意从技术层面上讨论哪种更好。但如果要打造一个有浓厚技术氛围的团队,那么最好是能将天平向激进一端倾斜一些。过于保守追求稳妥的技术团队是很难形成学习型氛围的。

在豆瓣,我们的倾向是非常偏向激进一边的,几乎对于新技术的引入是无保留的鼓励。任何工程师希望引入一个新技术,除非看到明显的问题(比如从现有技术无法平滑的切换过去),都会鼓励工程师进行尝试,用数据和效果来证明新技术的价值。一旦证明新技术可用且有效,就会进行全面的技术升级。尝试失败了,对工程师也不会有任何惩罚。

管理者对于创新需要有一个统一的认识:即创新都是有风险的。在豆瓣我们经常会说,多做才多错,不错是因为没做。要避免的是没有在错误中成长,而不是犯错本身。

当然,对新技术的选择会有一个硬限制,即团队拥有彻底掌握它的能力,出现问题时可以深入到底层进行修复。这会导致语言倾向,即优先选择使用本团队熟悉的语言(在豆瓣是 Python )编写的组件。当然,如果一个其他语言编写的组件非常有效,那么在团队内建设相应的语言能力,然后采纳之,也是可行的。比如 Docker 技术的兴起,我的建议是使用 Docker 的公司都应该拥有 Go 开发能力。

在招聘时,我们特别喜欢招聘喜欢“折腾”的人,即喜欢关注新技术,勇于尝试,不畏惧失败的人。这些人是真心喜欢技术的,团队里这样的人一多,管理者再给予鼓励,自下而上的创新就会自然而然多起来。

另外,举办或者参加 Hackathon 也是工程师释放创新动力的一个途径,Hackathon 往往更偏重产品层面的创新,这里就不多说了。

好的工程师是无法容忍低效的,能用技术解决的问题就坚决不要用人解决。所以要营造和保持一个好的技术氛围,管理者就需要鼓励使用工具,鼓励工程师引入工具或者创造工具。

比如各种工作流,能够使用系统在线解决的,就不要让工程师拿着单子跑来跑去找人。能够做事后审核的,就不要做事前审批。能够自动化的,就不要派个专人。繁琐的流程一定会导致优秀人才的流失和责任感的退化。

比如技术文档,能用 git、wiki 或者 google docs 管理的,就不要用邮件发来发去了。

比如开发环境的建立,能够做成一个一键建立的工具的,就不要再让开发者对着文档到处下载安装了。

比如软件上线发布,能够做成一个发布系统的,就不要再写发布文档交给运维一步一步操作了。

现在随着云计算和SaaS的兴起,有非常多的云服务和第三方软件可用,非常建议现在的管理者采购一些好用的工具,以及鼓励工程师自研一些定制化的工具。在创造和使用工具上,工程师的热情是高涨的,围绕工具的讨论也会促进技术氛围的提升。

要建立和维护好团队的技术氛围,需要自上而下的技术导向,需要成员之间的分享精神,需要鼓励自下而上的创新,需要建立效率优先的工具文化。文化的建立和传承是个润物细无声的过程,管理者自己需要真正认可技术文化,在工作中不断打磨细节,才能起到效果。

有技术背景的管理者,对技术文化的认可一般不会有问题。但如果你的CEO或者合伙人还没有形成这个认知,那么不断的影响他们,给他们灌输技术文化的重要性,让他们真正把技术重视在心里而不是口头上,这个可能其实是你最重要的工作之一。