小红书重视技术氛围和工程师文化的塑造，关于上述问题的答案，听听小红书社区技术负责人风笛怎么说。
1024 程序员节前夕，小红书社区技术负责人风笛受邀出席中国计算机学会举办的“第二届 1024 中国工程师文化日” ，在大会上分享了自己对工程师文化的思考。当天包括 CCF 理事长梅宏院士、CCF 前理事长郑纬民院士、CCF 副理事长周明、航天科技集团五院“天问一号”火星探测器总设计师孙泽州等 20 多位国内外技术大咖，也分享了对工程师文化的看法。
大家好，非常感谢 CCF 的邀请，能跟大家在1024的前一天，一起交流和讨论“如何在互联网企业中打造一支卓越的工程师团队”。
一、技术人不能自high，首先要快速交付用户和企业价值
对于互联网企业原生的增长驱动力，不同的公司也有不同的基因，大致可以分为三类：业务、产品和技术的驱动。
不论哪种模式，技术都是互联网公司背后的强大支撑——技术团队都在其中扮演着非常重要的角色。纵观高增长的公司，往往会看到其中工程师团队在员工总数里面大约占到一半甚至以上，由此也可以看出在互联网行业中工程师团队的重要性。
当然现实世界中，不论是哪种增长原动力，也都会受到一定程度的制约。比如对于技术创业者而言，经常会出现技术很好但市场反响遇冷，这里面很大的陷阱就是技术自嗨。
中国绝大多数互联网公司中都更偏业务驱动。有人说在整个世界互联网行业中，中国企业是业务创新最快的，甚至比湾区业务创新速度都要快。
过去十年是中国互联网产业发展非常快的十年，这十年中走出来的企业，不管它有什么样的特点，工程师团队都有如出一辙的特点：快。这个快并不仅仅是说交付效率快，更是交付用户价值，交付企业价值的速度要快。
二、卓越工程师团队的三大文化特征：热情、自由和效率
我自己心目中卓越的工程师团队应该具备这三大文化特质，我们在小红书技术团队中也正努力实践传递这种文化。
热情：对生活有热情，对技术有追求，对同学有感情、对目标有激情
小红书1024程序员日
衡量一个工程师团队是否是卓越，最终是以结果为导向——这个团队是否能做出卓越的技术或者是产品?
这些东西离开了热情，离开了热爱是很难做出来的，热爱会驱使我们孜孜以求。不论是对于技术能力还是对于产品迭代的目标，都需要有非常深度的热情才能把事情做好。
自由：信息平等流动、Peer Review、不做流程的奴隶
“自由”是工程师同学非常喜欢的一个词，工程师不喜欢被各种各样的东西约束。比如说在计算机领域里，有一类文化称为极客文化，极客文化也是对自由非常强的追求。
对于工程师团队而言什么才能够带来真正的自由?
·真诚表达
·自我驱动
·Peer Review
·信息平等
·不害怕犯错
·不做流程的奴隶
不仅是工程师团队，不论什么样的团队，当人数增多层级增加的时候，就会出现信息传递上的路由节点。举例来说，假如有500位工程师，一个人的最佳管理半径是7~8人，500个工程师就要分好几层。在这些层级之间，如果信息不能自由流动，就会有人吃信息差，这会导致团队低效。真正工作在研发一线的工程师，如果没有完整的信息，很难做出最好的选型和决定。
“Peer Review”和“没有权威”，这对一个工程师团队来说也是非常重要的，工程师团队中层级是最不重要的东西，当我们面对具体的产品或者是技术问题时候，谁拥有最多的信息，谁有最多可能的执行路径或者点子，谁就是这个问题的 owner。与声音大小、高低，资深与否并不直接相关，而是与谁掌握更多的信息相关，和前面的自由是相互呼应的。
最后一点是不做流程的奴隶，大家可能看过德国工程师换下水道盖子的过程，其中的流程非常严密，甚至包括贴瓷砖等等的SOP。但是流程是为人而服务的，目的是解决问题，而不是把人安装到流程上成为了“螺丝钉”。
效率：简化不是简陋，是正确的抽象和高质量的交付
工程师更倾向于去做那些具有创造性的事，而对于机械的、流程化的，持续执行的，换句话说就是做久了会使人的脑子很僵化的东西，会自动简化。这对于提高团队效率，产出更高水平的工作非常重要。
这里也会诞生一种亚文化，工程师团队对于工具的重视度。
工程师团队技术水平高还是低，非常重要的一个度量指标是这个团队是否能够持续产生可以提升效率的工具，是否能够不断把频繁发生的事情自动化掉。有个玩笑说是懒惰推动了技术的进步，其实我们今天更多的更加先进、更加高阶的技术都是想着怎么简化，怎么节省更多的时间和步骤。
三、业务研发面临的困难
在“永远做不完的需求”面前如何沟通和取舍?
在互联网做研发会有一个像魔咒一样的东西，叫做“永远做不完的需求”。这和整个中国的应用创新环境有关，这种情况下，产品和研发的比例有 1:3 、1:5，甚至有 1:2 的，这里会发现一个特别的现象，想要交付掉所有的需求几乎是不可能的，需求永远都在排队，这时候就必然要做排序和取舍。
可以看到在整个研发的流程中，随着软件复杂度的增加和软件生存周期的变长，呈现出两极的态势。
其中一类软件会持续使用下去，规模也越来越大，另外一些模块跟功能可能只存在一天，最短的甚至只有几个小时。以马上到来的“双十一”为例，比如抢红包雨可能只存在一小时，之后这个功能就下线了。对于这样的功能如何提升它的研发速度，怎样做质量保障?这是摆在不同企业面前的问题。
如何避免团队越大，实际做事的人越来越少?
团队越来越大，人越来越多时，会出来很多新的工种，甚至专门有人来做组织流程优化。可是我们会发现流程越来越重，看着工程师做事情的人越来越多，实际做事情的人却越来越少。真正在一线做事情的就是在土上挖沟的人，其他的人是来层层监督，看他有没有按照流程设计的时间点把沟挖好，所以这里会产生大量的内耗，这和一个高效卓越工程师团队追求的初心和理念有非常大的 gap。
对于工程师而言，有一类不好的趋势就是随着技能的分类，工程师团队也越来越细分。比如说连前端工程师都会区分我是写 review 的还是写别的，我是写 vue 的还是 react 的，做 A 的就不能做 B，更别说其中的流程监控和质量保障。
对工程师而言我们会更提倡技能尽可能全，我们需要更多的“T形”人才。他在某一个领域里需要足够精深，但是这一“横”也要足够宽，能 cover 到我们的常用技能，能看到在构建软件中相同的部分，而不是不同的部分。
技能“全”的同时，也要能做“小”事。一个团队开始臃肿起来就是因为那些看似不起眼，没那么重要，却非常影响团队运转的“小”事没有人做。
四、打造工程师团队要面临的几个核心矛盾
接下来分享几个针对于工程师团队从小到大，在逐渐变化中面临的矛盾，这个几乎是所有团队负责人，特别是到中高阶技术负责人面临的挑战。
产品 VS 技术：业务需求的持续增长与团队有限交付能力之间的矛盾
在互联网行业里有个笑话，说产品经理和研发工程师是一对永远解不开的死疙瘩。刚才提到一个观点，就是需求是永远做不完的，但如果是技术完全拿到决定权在业务侧也会带来灾难。这一对矛盾在不同的企业里有不同的解决方式，但是有一条非常重要，就是技术首先要守住自己的本职工作，能够在关键的技术方案中判断什么行和什么不行，以及在技术条件实现的边界和可持续性上能够给出自己的明确判断，避免过度承诺。
同时技术和产品要有比较好的互动方式，其中就需要有非常清晰的决策流程。每家公司不一样，比如业务驱动型公司在解决冲突的时候，充分把信息对齐，把问题和矛盾表露清楚，最后由业务做决定，这是很重要的解决分歧的过程。
算法 VS 工程：如何客观看待算法这个新工种的价值
算法是大概从2009年、2010年之后在互联网行当研发序列中逐渐出现一个新的工种，曾经也是高薪的代名词。在很多研发团队的构建中，到底需要少而精还是人数多，存在着一定的矛盾。我们应当更加客观的看待算法和工程的投入，不能厚此薄彼，好的系统实现也是非常重要的。
特别是和人工智能相关的算法，也有着很多应用的边界。比如说在信息分发的场景下，我们以大家熟悉的今日头条、抖音、小红书信息流为例，从过去的编辑推荐走向全自动化、智能化的推荐算法分发，可能会带来几倍、十倍以上的效率增长，从0到1有非常大的提升。但是这时也会有边际递减，基本上红利一年到两年就吃完了。这时候对于算法，对于AI技术的投入，在整个技术团队视角就要能够看到它的边际效益点，更多的投入不见得比整个工程系统的升级带来的收益要多很多。
算法工程很多从业者来自于非计算机科班专业，比如数学、物理、自动化等等理工类专业的同学。所以这里非常重要的一点就是，当更多非科班非计算机系的工程师入行后，他们同样需要有很好的系统架构的视角。尤其是对于人工智能类的系统，很多都是“死”在了高并发和规模化的这条路上。看上去结果很美，但是一旦上规模就很难。
而且很多人在学校时，看到的更多是那些新的模型和新的演算方法的提出，对于加入企业会存在很多不切实际的幻想，觉得自己80%的工作是在改造这个世界。而实际上场景中80%的工作是在建设底层系统，解决数据流、数据一致性等方面的问题。所以理性的看待团队中不同技术类型工种，特别是近年新兴起的算法和工程之间的差异也是一个重要的矛盾视角。
研发 VS 测试：维持“1:10”的测试研发比还是逐渐走向无测试
以往我们会看到不同公司都有测试工程师，最奢华的公司测试工程师和研发工程师的比值可以做到 1:1。在互联网行当里，基本上 1:3 到 1:5 是比较合理的数字，1:5 比例的公司更多是做APP，是直接有用户 UI 界面的真正偏后端的团队，没有直接 UI 交互的团队会达到 1:10 甚至 1:15。
在软件工程领域做得非常靠前的，比如说谷歌这样的公司，甚至能做到工程师只需要把代码写完提交上去，后面就不用管了，现场出了故障基本不会追责到工程师。因为他们已经完全把测试工具化、流程化掉了，甚至有测试驱动开发的人员在里面。所以如何在团队里设置质量团队、QA 工程师的数量，以及他们的定位到底是偏测开还是偏功能测试，也有全自动化的在云上的测试。今天在小红书的技术团队里，已经可以进展到可以对几十种甚至上百种机型做到自动化的 UI 测试。
五、我理解的工程师文化以及如何建立工程师文化
我理解的工程师文化：
·它不是“衣着休闲、时间自由、不修边幅、免费三餐与工位装修”
·它不是“自high文化，完全由技术说了算，喊着技术驱动业务”
·它是“以共同解决实际问题为目标的团队文化”
·它是“内心欲望和恐惧的外在表达，因欲望而创造，因恐惧而改造”
这其中的核心是以共同解决实际问题为目标的团队文化，更多是构建工具、解决未知，能持续提升效率这样的一种欲望，驱动我们不断对技术，对团队内部流程工具去改造。
那么如何建立工程师文化?
自己和团队一起工作，要能做自己-2的事情。
·我自己对于团队中的技术 lead 会有一个要求，就是这是一个蛮高的要求，也是从陆奇老师这边借鉴的：能做自己-2的事情。其实能做自己-1就已经很了不起了，做自己-2的事情，而且要求团队里的 lead 都做到，是更有挑战的事情。
·没有 Leader，只有 Owner
·一切以数据说话，分析数据的本质
·可以加班，但拒绝无意义的加班
·工程师团队很简单也很单纯，更多的人每天是兢兢业业的坐在那里贡献着自己的代码，贡献着自己的力量，希望每一位技术 lead，每一家公司都有一支属于自己的卓越的工程师团队，我的分享就到这里，谢谢大家!
（免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。 ）
