工程师文化

最近在酷壳上看到陈皓的《什么是工程师文化？》，很有感触。

最近入职新公司不久，带领一个新的团队做一个新的项目。项目之初，缺乏规范，缺乏信任。为此整理”团队开发规范“。《什么是工程师文化？》中提到的内容很有借鉴意义。可以在自己的项目中选择适用的部分作为指导。

文章的部分内容如下：

今天，每个从事计算机行业的技术人员都应该感到幸运，因为，我们不但选对了行业，也出生在了正确的时代，可以感受到前所未有的刺激和变化，相比起我们的父辈，我们的人生，能经历这样的时代，实在是一种幸运。所以，选对了职业并出生在了正确的年代的我们，此时只需要思考的一个问题，那就是，我是否呆在了正确的地方用正确的方式做事？

在我看来，这个世界上有三种商业公司:

运营或销售驱动型的公司。这类的公司以运营和营销见长，技术对于他们来说，更多的只是为了支持大规模的营销活动，以及成本上的控制，所以，基本上来说不太需要技术创新。这种公司最大的问题就是缺乏安全感。
产品驱动型的公司。这类公司以产品见长，通过创造能提升用户生活体验的产品见长，技术对于他们来说，除了支持大规模的在线用户之外，他们会更多的去寻找那些为了增强用户体验，提高整个业务流程效率的技术创新。比如：UI的交互方面的，整个业务流程方面的。这种公司最大的问题，就是容易被别人模仿和抄袭。
技术驱动型的公司。这类的公司相信技术能改变世界，他们更多的是用强大的工程技术来创造有颠覆性的东西，更多的是用各种自动化的技术取代人类。比如：近代的蒸汽机技术取代了大量的人工，数字技术取代了大量信息传递的人工，现代，这类公司还希望通过人工智能来取代愚蠢的人类来做决定。这种公司最大的问题就是可能做出叫好不叫座的东西。
这三种公司都可能成功，也都有问题，但是，无一例外，他们都需要强大的技术支撑，只不过，他们把技术所放在的位置不一样。

工程师文化的特征

简单说来，我可以简单的把这多的工程师文化的总结成两大类：“自由” 和 “效率”。

针对于工程师文化来说，尤其是软件工程，提升工程效率的具体表现如下：

• 简化。简化不是简陋，简单的东西通常意味着用户更好理解，也意味着更容易的维护和运维。就像阿里推行的“小而美”，就像乔布期推崇的“没有产品手册简单易用的产品”，就像Amazon推行的Working Backwards里说的那样，一个新的产品或功能，产品经理需要写三个文档：媒体公关文、用户手册、常见问题，三个文档总共加起来不超过两页A4纸，且不准用任何图片说明，目的就是为了让产品简化和容易使用。
• 残酷无情的推行自动化。编写程序的最本质的目的就是自动化，看看人类发展史上自动化了多少东西。对于自动化来说，不仅仅只是消除人肉的重复劳动，更重要的是，很多事情人完全干不过机器。比如：加一台机器，程序在秒级就可以完成，而人是永远不可能达到这样的速度的，再比如：电商中用程序管理数量巨大的订单的自动化系统，加再多的人都完成的不可能像机器那样完成的又好又快。自动化需要大力开发提高生产力的工具，比如：持续集成，持续部署，自动化运维，基础自动化运维，甚至自动化的运营工具。（Amazon的软件工程中对自动化和简代相当迷恋）
• 避免无效率的组织架构和无效率的管理。这体现在这些方面：1）扁平化的组织架构，2）努力用自动化工具取代支持型的工作，3）不超过10个人的全栈小团队，4）不按人员的技能分工而是按其负责的产品或功能分工（关于分工，请参看《让我们来谈谈分工》），5）开会不是解决问题，开会是表决提案，6）通过产品的目标或信条Tenets来减少沟通和决策过程（Amazon里的每个部门，每个团队，每个产品都有自己的Tenets，这个Tenets标明了要什么不要什么，这样可以避免很多扯皮和难缠的trade-off的决择，比如：AWS的几个信条：运维是最高优级的——这意味着只要是会让运维变得复杂的需求都可能会工程团队被拒掉，Throughput & Latency不能更差——这意味着，功能要为性能让路，因为性能变差了，用户就要买更多的资源）
• 正确的组件抽象。抽象是简化的一部份，一方面，抽象意味着重用和通用，另一方面抽象意味着强大的扩展性，以适配各种可能性。最重要的是，抽象意味着技术能力的输出，无论是内部的其它团队还外部的团队。比如：Google的MapReduce/BigTable/ProtoBuffer，FaceBook的Thrift，还有Amazon内部的WebService框架Coral Service、处理日志监控的Timber，以及全线AWS产品都用到的Amazon Lock Framework（一个分布式锁框架）……
• 开发高质量的产品。因为高质量的代码，不但可以容易的修改和维护，还可以因为少处理线上故障，从而有更多的时间去为未来做更多创造性的工作。这意味着需要有非常严谨的Design Review，Code Review，以及测试，关于Code Review，可以参看这篇文章《从Code Review 谈如何做技术》，关于严谨的测试，可以参看这篇文章《如何做性能测试》
• 不断的提高标准以及招聘最好的人。取法其上，得乎其中，取法其中，得乎其下，取法其下，法不得也。如果一个公司或一个团队想变得越来越好，越来越强大的话，就必需要不断的提高自己的工作标准，提高工作标准意味着要不断地培养和招聘更好的人。在Amazon和Google的招聘官中都有一个叫Bar Rasier的人，这个人就是为了提高招聘标准而设立的。
• 创建一个持续改善的文化。一个好的组织，一个好的团队，是需要不断反思前进的，这需要全体员工一起来的。微观层面上，在项目做完后需要有一个总结会分析项目中的得失，在故障出现后，需要有故障分析会，反思得失，在Amazon，严重的故障，需要写一个COE（Correction of Errors）的文档，其中有一节叫“Ask 5 Whys”，让你自己问自己至少5个为什么。在宏观层面，一个公司每年都应该做一定的工作数据分析或是员工调查，比如，是否招聘到了不错的人、工作的投入产出比，员工在哪些地方花时间了，等等，然后不断的用技术手段来改善。（Amazon每年的工程师员工调查表是我活那么大见过的最细最细的调查表了， 问题除了对公司、经理、文化的，还有从，日常工作、开发环境、持结集成，测试自动化、产品质量、软件架构、软件维护、线上问题处理、年度计划、数据仓库建设、通用工具投票……这个员工调查直接导致公司的对工程的投资方向）

工程师文化如何落地
如果你要让任何文化在公司内得到执行，你有下面几个手段可以选择：

• 通过政治手段：你需要把住三个地方——招聘、绩效考核 & 升职。比如，你要落地工程师文化中的简化和自动化，那你你在招聘的时候，你需要把懂简化和喜欢自动化的人招进来，然后在绩效考核和升职的地方设置上一条硬性指标——你今年简化了什么？自动化了什么？如果没有，对不起不但不能升职，绩效可能还不达标。
• 通过经济手段：让不做这事的成本 > 要做这个的成本。然后，正常的人类都会选择成本低的方案。比如，如果你要推行Design/Code Review/UT以提高质量，你就把QA和OPS团队全挪到一边去，让Dev团队自己测试，自己负责，这样等这些Dev重复多次手动测试，处理多次线上的弱智故障，他们就会自然而然的写自动化测试和做Code Review了，而QA和OPS团队只是帮Dev你做工具罢了，而测试和运维的事全是你DEV的Ownership，出了故障也是Dev自己负责，于是，他们就会发现，不做Code Review和UT的成本远远大于做C Code Review/UT的成本，他们就会去做成本低的事的。

最后，工程师文化要落地，还有几个小条件，

第一，团队要小，Ownership很重要，Eat Your Own Dog Food。 没有人帮你擦屁股，自己的屎自己吃，没有痛苦，不会产生想进步的动力。
第二，热爱学习和尝试，学习尝试新的技术，开拓眼界，学习尝试新的思维方式，否则，呆在原地，原有的思维方式只会让你在原地打转转。
第三，老板更多的相信技术而不是管理。相信技术会用技术来解决问题，相信管理，那就只会有制度、流程和价值观来解决问题。

说了这么多，时代还在发展，不过，这是我这么多年经历或看到的工程师文化的东西了。最后吐几个槽——
对于996和加班这个事，对于工程师来说从来都不是问题，在解决技术问题或是创造的时候，工程师是个很自觉的群体，基本不需要有别人驱动，工程师是最乐意Work Hard的人了。我相信几乎所有走上编程这个职业的人来说，基本上都是兴趣所至，觉得编程很有趣，但却被各个公司996搞得对编程毫无兴趣。为什么，你们这些公司要向中国的教育学习呢？人家本来对这事有比较高的兴趣的，但就是要通过考试/KPI/996这些东西把人家的兴趣一点一点的磨灭掉，把人变成机器、奴隶、牲口，让人对学习和工作产生了厌倦和讨厌，会是你们这些管理者们所希望的？是不是只有把人变得不思进取了，你们才会管理？就像《软件开发中的两种管理方式》中说的第一种人一样？

另外，我不知道，为什么我一说这些东西，就会有很多人（包括程序员自己）来和我说我是个理想主义者，这些已经不是什么理想了，已被很多成功的公司用了很多很多年了。只是你没有见到过罢了。还有的人说，因为中国的国情不同。这更让我费解了。这让我想到了当年大清朝派了一堆人出国考察后回来后，说外国的那套共和的东西不符合中国国情，最终也在历史的潮流中被淹没掉了。另外，什么叫“中国的国情不同”？中国有全世界数一数二的互联网用户，也有全世界数一数二的市场，不再是以前那个一穷二白的年代了，中国的国情到底有哪些不同呢？

我不知道各位工程师是为什么活的？但我觉得，我们选择了一个刺激的职业，也赶上了这个行业大发展的时代，我们不妨扪心自问一下，你是否愿意让自己的能力、青春和热情就这样被磨灭了？

扩展阅读：

bar raiser
抬杠者

什么是工程师文化？
https://coolshell.cn/articles/17497.html
简介：

2016年09月18日  陈皓 评论  109 条评论  63,713 人阅读


四年前，我在QCon上演讲了一个《[建一支强大的小团队](http://www.infoq.com/cn/presentations/Form-powerful-team)》（整理后的[PPT分享于这里](http://vdisk.weibo.com/s/gN-sQ/1351485199)）提到了工程师文化，今天，我想在这里再写一篇关于工程师文化的文章，一方面是因为我又有了一些想法和体会，另一方面，因为我也正走在创业的道路，毫无疑问，要建一个有浓重的工程师文化的团队或公司，所以有必要把自己的相关想法形有成白底黑字的“字据”，以供打自己的脸——“要是未来没有做到，这篇文章就打我未来的脸” || “这篇文章太幼稚了，未来的我会打我现在的脸”，当然，如果要打脸，我希望是前者。
Again，**这篇文章不是招人的贴子，因为我觉得，招聘第一重要的事，不是发招聘广告或是找猎头挖人，而是先得让自己变成一个能配得上真正工程师的公司，然后再谈吸引人的事**。

亚马逊招聘内幕：Bar Raiser狂刷应聘者
http://www.ebrun.com/20140109/89507.shtml

简介：

一位与Facebook和Twitter都有过合作的人力资源顾问表示，几乎没有公司能像亚马逊一样能坚持自己的招聘流程，他们不仅仅是招聘最优秀的人才，而且愿意去寻找最适合自己的人才。要成为一个Bar raiser之前要处理过几百场面试，而且在问面试问题和分辨优秀员工方面要有一定的阅历。通常来应聘的员工都会由其他部门的Bar raiser来面试，Bar raiser会向他们提出具有挑战性的问题来测试应聘者的分析技能。做过Bar raiser的员工都说这项工作既是一个荣耀，也是一个负担。

还有一位亚马逊的硬件开发员工表示他在亚马逊的8年中参加过700多场面试，但是他不愿意成为一名Bar riser，因为占用的时间太多了。在创建这个招聘策略的时候，亚马逊CEO贝索斯想要创造一种持续的合作的公司文化。亚马逊的高层认为，这个程序涉及的面试官比较多，需要大家意见统一才能确定招聘的人选，这样就减少了招聘上的失误。曾经帮助亚马逊开发这个项目的员工说，这个严格的面试程序是为了筛选掉那些适应性较差人，只有能经历这种轮番面试的人才能适应亚马逊的工作氛围。

一位曾给亚马逊提供招聘咨询的人力资源师说，亚马逊招聘的是一个能适应公司的任何角色的人，而不是为了单纯的填补职位的空缺。虽然这样招聘看起来费时费力造价昂贵，但是贝索斯却对这种方式很满意，因为他认为如果招聘到了错误的人选则会付出更大的代价。