新品平台-望沉

技术氛围就是研发同学在整个团队乃至公司中，能被足够的重视，被确定价值，让他们感受到未来可期。

背景

在互联网公司中，研发团队可谓是第一生产力，往往决定了公司的根基走向和创新方向，然而技术氛围是研发团队必不可少的。简单讲，技术氛围就是研发同学在整个团队乃至公司中，能被足够的重视。团队中的大部分人，能热爱技术，喜欢折腾，乐于分享。在这样的环境下，一方面能激发团队不断的推陈出新，另外一方面也能使团队成员有持续的我的成长。若是团队领导只是把成员当成螺丝钉，以春蝉到死丝方尽的理念用他们，那结果就很明显了——你们天天都很累，感受身体被掏空，没有精力去学习新技术，去分享技术。长此以往，以为没有成长，就离开了。显然这种方式无异于杀鸡取卵，他们是一群充满活力的年轻人，须要被确定价值，让他们感受到未来可期。

什么是团队技术氛围？

个人认为，从公司角度来说，有自己的开源项目（公司内外沟通渠道）；定期组织内部技术讨论分享会（内部沟通渠道）；每一位负责具体模块的程序员都能了解自己所在项目组的整体架构（避免眼光局限）；鼓励员工在业余时间做自己喜欢的项目并分享（鼓励员工成长）。

为什么要建设团队技术氛围？

1. 有助于长期帮助公司笼络和稳定人才；
2. 有助于公司创新，尤其对一些有技术门槛的公司，技术氛围所带来的创新至关重要；
3. 有助于团队成员的成长，提升个人价值；

怎样才能建设团队技术氛围？

技术导向

有技术导向的价值观，是保持好的技术氛围的最关键的事情。

现象上来看，从个人导向上，大部分程序员都希望在工作中能有技术的提升，业务场景中使用的技术越先进，程序员就越兴奋，这也是程序员未来能在职场上竞争的重要筹码。所以有一个技术导向的团队，非常受程序员的欢迎，也会是这批技术人员渴望聚集的团队，这是双向导向的结果。那么，一个团队如何做到技术导向的氛围。

首先，从最高层开始就需要重视技术，尊重工程师。如果连CEO都认为工程师只不过是用来实现产品需求的资源，那么技术团队的负责人不管怎么做，也不可能保持住技术氛围的。这里说的尊重工程师，不是说给高薪之类的，而是说理解工程师的思维方式和做事方法，用客观的、有逻辑性的方式来带领团队。比如重视数据、使用 A/B test 等方式来辅助决策、信息公开透明、不随意更改需求、开发周期主导权由工程师把握等。鼓励工程师对产品发表意见甚至介入决策过程也是很好的实践。

其次，自上而下的推行技术平台化建设、推行DevOps、推行自动化构建、测试和部署流程。这几样事情虽然不直接产出产品，但可以显著提高团队的开发效率和技术水平，以及能够提升开发者为自己的产出物质量负责的意识，这也是一个好的技术团队必要的素质。所以要打造一支专注于技术能力的升级和基础组件维护的团队，因为有这个团队的存在，各个产品线可以保持相似的技术栈和开发方式，在基础组件升级换代的过程中也可以避免出现新旧版本混乱的情况。同时，由于脱离了产品压力，这个团队可以有更多的时间来考虑精益求精的技术问题，可以持续不断的推动整个公司的技术氛围。

分享精神

技术分享是快速交流思想的一种有效方式。

萧伯纳说：“你有一个苹果，我有一个苹果，彼此交换一下，我们仍然是各有一个苹果；但你有一种思想，我有一种思想，彼此交换，我们就都有了两种思想，甚至更多。”鼓励分享可以使得技术讨论的气氛活跃起来，碰撞出新的想法，也能更容易让优秀的人脱颖而出，成为团队中的具备影响力的一部分人。

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

其次，除了这种比较重的强制分享机制，还需要为团队成员提供轻量通畅的分享交流渠道，当任何人发现一个有点意思的信息时，都可以没有心理包袱的分享出来。这种基于主题聚合的聊天频道的设计，可以鼓励交流，同时不会对正在专心工作的人产生干扰。代码也需要分享，分享的手段就是 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 。这对促进团队间交流，提高跨团队工作效率，避免大公司病是很有益处的。

上面说的都是内部分享，对外的分享包括公司间交流、技术大会分享、代码开源等等。这些相信大家都已经深刻理解了可以带来的益处，就不多说了。在一个工程师团队内，荣誉激励要比经济激励要有效的多，工程师最大的成就感就来自与自己的水平被同行认可。分享正是提供了荣誉感的来源。

鼓励创新

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

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

任何工程师希望引入一个新技术，除非看到明显的问题（比如从现有技术无法平滑的切换过去），都会鼓励工程师进行尝试，用数据和效果来证明新技术的价值。一旦证明新技术可用且有效，就会进行全面的技术升级。尝试失败了，对工程师也不会有任何惩罚。

管理者对于创新需要有一个统一的认识：即创新都是有风险的。所以我们要经常宣导，多做才多错，不错是因为没做。要避免的是没有在错误中成长，而不是犯错本身。

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

在招聘时，我们特别喜欢招聘喜欢“折腾”的人，即喜欢关注新技术，勇于尝试，不畏惧失败的人。这些人是真心喜欢技术的，团队里这样的人一多，管理者再给予鼓励，自下而上的创新就会自然而然多起来。另外，举办或者参加 Hackathon 也是工程师释放创新动力的一个途径，Hackathon 往往更偏重产品层面的创新，这里就不多说了。

工具文化

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

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

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

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

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

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

总结

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

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

消费者平台-闲行

技术氛围更重要的是在于“氛围”，即技术人员愿意投入精力、乐在其中、精益求精的这种氛围，而这也是技术驱动的公司需要去考虑和通过行动营造的。

谈到技术氛围的时候，可能第一反应是 Google、Apple、IBM 这些大公司，觉得可能雇佣的技术人员多了，技术业界第一了，这就叫技术氛围，但是技术氛围只需要技术水平就够了吗？

分享一个最近听到的冷知识，小时候经常玩的《打砖块》游戏，竟是乔布斯一生中唯一参与开发制作的游戏。这背后有个很有意思的故事，这事还要从 1972 年，两名开发者制作出的世界上首款街机电子游戏《乒乓》说起，玩家可以在街机上操控滑板来回击球。后来雅达利接手了这款游戏的发行，但忘记了申请专利，爆火的同时，各种盗版的游戏也蜂拥而至。因此雅达利决定开发一款单人游戏，这个项目落到了第 40 号员工乔布斯身上。由于当时技术有限，街机游戏机是通过芯片上集成晶体管电路，让晶体管控制电路开关来运行的，当时雅达利的工程师开发一款游戏大约需要用到 150 个晶体管，但晶体管价格非常昂贵，因此雅达利给乔布斯承诺，如果一个月内开发完成，可以拿到 900 美元报酬，每节省一个晶体管，将多获得 100 美元。这在当时的美国可是一笔巨款，乔布斯找来他的朋友沃兹一起开发，在接下来的四天里，两人几乎不眠不休，没想到居然真开发出来了这款足以载入史册的《打砖块》，而且仅仅用了 44 个晶体管。更厉害的是，这份作品的设计精妙绝伦，除了沃兹没人能玩得明白，直到另一个雅达利工程师用了 100 多个晶体管重新实现才得以量产，不过雅达利最终还是兑现了承诺，乔布斯收了巨额奖金。后面的故事大家应该都熟悉了，雅达利在街机游戏领域越做越强，“街机始祖”名副其实。

在这个故事里，我们能感受到雅达利里的这股技术氛围。4 天不眠不休的开发，不得不佩服乔布斯和沃兹的技术水平和优化实力，这个结果必定也是他们俩精益求精、不断精进获得的。乔布斯和沃兹愿意为这款游戏做出如此精妙的设计，自然也离不开公司为技术买单的魄力。通过技术人员的优化，为公司降低了巨额成本，再通过奖励犒劳技术人员，鼓励技术创新。这样的公司里，技术人员自然更愿意投入到更精妙的技术中，更加专注于技术本身。因此我认为，技术氛围更重要的是在于“氛围”，即技术人员愿意投入精力、乐在其中、精益求精的这种氛围，而这也是技术驱动的公司需要去考虑和通过行动营造的。

结语

每个人对于氛围的感知都不同，无论什么职位，都有自己不同的见解，你认为好的技术氛围是什么呢？评论区留下你的看法吧~