我曾经在不少类型的公司里工作过：有外资的公司，也有国内的公司；有做外包项目的，也有做产品的公司；有传统IT行业的，也有互联网公司；有小作坊式的创业公司，也有号称“百年老店”的行业巨头……可以说在不同的公司中领略到了截然不同的各种公司文化。丰富的经历让我的适应能力得到了锻炼，能够快速适应各种公司文化（除非实在是突破下限）。同时，也让我经常思考：究竟什么样的文化才是最好的？
很遗憾，并没有一个客观标准的答案——每个公司的文化都不同，都是有利有弊，而且对于每个人来说，“最好”这个定义都不一样。随着我自身的工作职能向着质量与工作效能领域的转变，渐渐的我所追寻的目标变成了——什么样的文化才是高效而可靠的？
有这么一种说法：每一家公司都是科技公司，即便是银行也只是拥有银行牌照的IT公司而已。这种说法虽然略显激进（实际上它的例证却比较有说服力——2003年，欧洲的汇丰银行雇用的软件开发人员比Google还多），但是也说明了一个事实：在信息时代，几乎任何一家公司想要创造价值都离不开科技工作者、也即是软件工程师的贡献。想想看我们现在的日常工作就知道了，绝大部分工作都是通过各种软件来进行的，至少也是外购系统。而很多业界领先的企业一般都有专门的软件开发部门，来实现业务方的各种定制化的需求。任何一项业务上的决策或者变更必然会带来软件系统上的改动。所以，软件工程师在各公司实际上扮演着越来越重要的角色。
不幸的是，在很多公司，软件工程师的价值往往被低估。很多业务驱动型的公司，无论是属于传统行业，还是传统行业往互联网转型，甚至可能是互联网业内的，都认为业务部门才是创造价值的核心，软件开发部门只是附庸，甚至是只会增加成本的部门。这类公司平时并不注重IT部门的建设，只有在现有软件无法满足业务需要或是出现重大线上问题的时候才会跑去指责IT部门的过失。很明显它们无法在现在这瞬息万变的商业环境中取得先机，甚至可能因为反应太慢而被行业淘汰。原因很简单：在这个时代，既然“任何一项业务上的决策或者变更必然会带来软件系统上的改动”，那么反过来软件系统的改动没有ready业务也无法开展，这样的公司只能眼睁睁的把机会拱手让给更能适应变化的竞争对手。
另一方面，关注软件工程师价值的公司在这个时代更能得到迅速发展。一项统计表示，2018年全球企业市值排行榜前5，全部都是狭义上的科技公司，分别为苹果、Google、微软、亚马逊、腾讯，第6到10分别为Facebook、伯克希尔哈撒韦、阿里巴巴、摩根大通和爱存不存，市值前10有7家都是科技公司。特别是前2的苹果和Google，已经连续霸榜好几年，而在10年前的全球企业市值排行榜Top10里，都还没有这两家的身影。
同时我们可以注意到，上榜的这7家科技公司，其企业文化都是在业内有口皆碑的，就算有个别地方不尽如人意，但是瑕不掩瑜。而这7家公司最大的共同点就是始终把技术摆在非常重要的位置上，鼓励技术创新，认同工程师文化。与之相应的，工程师们更愿意把自己的知识与价值贡献给这样的公司。在2018年福布斯最佳雇主榜Top100，上面的7家公司中除了中国的两家，剩下5家公司都有上榜，其中Google、微软和苹果分列第1、2、4位。这样就形成了企业与员工互相认同其价值的良性循环，业绩自然蒸蒸日上。
到这里，工程师文化对于当代企业的重要性已无需再多阐述，特别是对于技术依赖性最强的互联网企业来说，建设高效而可靠的工程师文化应该是重中之重。那么问题来了，应该如何做起呢？
首先需要关注于“人”
有句老话说得好：科技以“人”为本。工程师的能力对软件开发有着举足轻重的作用：所有的设计都是人作出的，所有的代码都是人写的。显而易见，如何招到合适的人来做事应该是万里长征的第一步。
说起招人，我的观点就是“始终要坚持招最好的工程师，高标准要求，宁缺毋滥”。这一点说起来很简单，但是背后的道理并不是人人都清楚。
首先，软件开发是一种特殊的知识性工作，在很多场合都证明了：一名高能力的软件工程师可能薪酬上要比一名能力普通的软件工程师贵一倍，然而前者能创造的价值却不只是后者的两倍或者三倍，而可能是10倍20倍——假设高能力工程师的月薪是2万，普通工程师是1万，5名高能力工程师创造的价值可能相当于50名普通工程师，而前者的总成本仅仅是后者的1/5或者更少。同时更少的人员所需要的硬件设施也更少，以及更小的办公室。所以说看起来单个高级人才成本高，但是实际上坚持只招募高能力工程师却会带来总体成本的下降。
其次，始终坚持高标准招人可以使你保持小团队的优势。我们都知道在企业里，软件开发是一项需要沟通协作的工作。而软件工程师们往往都是不善于与人沟通的——对他们来说，对着电脑撸代码比与人沟通容易多了。所以保持小团队、让沟通成本尽量小是非常重要的。同时小团队还可以保持灵活性，更能适应外界业务的变化。团队的体量越大，在外界环境迅速变化时想要转身就越困难，这一点在我的前东家“蓝色巨人”爱被摸公司想要追逐云计算潮流却转型失败的案例中被体现得淋漓尽致。
第三，高能力的工程师可以吸引更多其他高能力的工程师。在Google有一条招人的准则，它们把人才划分为3类，分别为“A Player，B Player，C Player”，“A Player”代表着顶尖的人才，B为普通，C就代表着比较差的人员。而Google的准则就是坚持只招“A Player”。因为这些“A Player”进来以后再去面试招人，一定会尽可能的去寻找其他的“A Player”。这是因为他们对自己的能力有自信，富有激情，勇于接受挑战，所以更愿意和自己相同level甚至比自己更强的人一块儿工作。反过来，如果团队里已经有了一名“A Player”，也会更容易吸引其他的“A Player”来加入。不幸的是，如果是一名“B Player”去招人，他找来的人大概率可能不是“B Player”，而是“C Player”。因为他能力不足，自信心也就不足。为了保住自己的工作或职位，他可能会选择尽量避免竞争，于是会尽量找能力不如自己的人，这就是人们常说的“武大郎开店”。根据“破窗效应”，一旦团队里出现了一名“B Player”而没有及时清理出去，随着团队或者公司的成长，人员越来越多，人员质量也会逐步下降，“B Player”和“C Player”会越来越多，甚至可能出现“劣币驱逐良币”的现象。这是每一位管理人员都需要随时警惕的。
招募高级人才是一方面，招来了人如何把人留住也是同样重要的一环。悔创阿里杰克马曾经指出：“员工离职说来说去就两个原因，一是钱没给到位，二是心受委屈了”。再总结一下其实就是：公司对员工的价值不认同。因为这种不认同，公司没有提供给员工相应的报酬（钱），或者没有提供给员工相应的发展空间（心委屈了），要么两者皆是，自然员工就会选择离开公司。所以大多数员工都还是很单纯，他们想要的东西也很简单，就是“被认同感”。
作为老板，以及公司的管理层，哪怕是基层管理层，都应该时刻关注手下的员工的被认同感。公司也可以采用各种手段及措施来奖励员工，提升员工的被认同感。这些奖励不一定是金钱上的，也可以当众给予荣誉性质的赞赏，或是额外的休假，又或是其他的一些小福利。HR和行政人员最擅长做这类工作，但是管理层不能仅仅只是依赖他们，因为这样很容易把鼓舞人心的奖励变成例行公事，那奖励就失去了它的效果和意义。
当然，仅仅通过奖励来提升员工的被认同感是不够的。只有公司真正地认同员工，员工才会认同公司，积极主动地为公司做贡献。怎么才算真正地认同员工呢？在我看来，首先公司应该认识到的一点就是每个员工都是独一无二的，每位员工都有他独有的技术栈，有的是UX专家，有的是设计高手，有的是代码狂人……这些人是互相不可替代的。团队leader需要根据每人的特点与优势给他们安排工作，让他们互相合作，就像一个足球队需要分为前锋中场后卫守门员一样，只有各司其职配合流畅才能取得最后的胜利。
我曾经工作过的一家离岸外包公司，因为随时可能来新项目，又随时有项目结束，所以老板组建了一个“人员池”——所有从刚完成的项目中释放出来的人员都会回到这个池里，而当有新项目来的时候就从这个池里挑人去做。这种做法导致很多人员因为时机的关系无法被配备到合适的位置，比如java工程师被拉去做.Net的项目，完全不懂日语的测试要每天研读大量的日语需求说明书，而精通日语的项目经理被陷在泰国的项目里……由于人们终日处于这种混乱的状况中，士气低迷，工作效率低下，导致大量的项目最终失败、延期甚至无法交付；项目失败导致公司的财务每况日下，大量的人员也因为工作得不顺心而离职，导致更多的项目缺人、失败、如此循环……
这家公司犯的错误很明显，就是没有认同每个员工的价值。因为他们当时刚过CMM/CMMI5，老板对“流程”十分的迷恋，奉行的原则是“人不重要，最重要的是流程。人是随时可替换的，流程才能保证人去做正确的事以及正确地做事”。在这样的背景下，没有员工觉得自己被认可，人们只是为了那不高的薪水每天机械地上下班和加班，工作没有激情，项目是否成功跟他们没有任何关系（老板也这样认为，所以不会因为项目成功对员工做任何奖励）。这样的工作态度有可能写出高质量的代码吗？有可能开发出高质量的产品吗？答案当然是No。所以要想激发员工的潜力创造出更多的价值，公司首先要尊重和认同员工，承认他们的价值，并且明确地让员工感觉到，这样员工才会认同公司，心甘情愿地为公司贡献自己的光和热。
坚持小团队
前面我们提到过软件开发中，小团队有优势。沟通成本尽量小是一方面，人越少越容易达成共识，整个团队都有一个明确的共同目标，有更强的凝聚力，齐头并进。而人越多，团队的沟通成本就越大。在《人月神话》里我们就了解了沟通成本的计算公式：假设一个团队的人数为N，那么这个团队的沟通渠道数或者说沟通成本就是N(N-1)/2——5个人的沟通渠道数为10，6个人为15，7个人为21，10个人为45，20个人为190，50个人为1225……随着人数的增长，需要的沟通渠道数成指数级增加，沟通成本将难以承受。
另一方面，团队越大，团队成员之间的熟悉程度越低，成员之间互相不了解对方的特长、工作重心等分别是什么，那么成员之间互相能够提供的帮助就越来越少。这个乍一听有点违背常识，但是仔细想想确实是这样的。打个比方，我们去参加一个大的会议或者参加某人的婚礼，几百人都在一个大厅里。在这种情况下想要在有限的时间里跟所有人都熟悉起来并交谈实际上是不可能的，人们最终更愿意和自己熟悉的人扎堆说话。在团队里也是一样，一个大团队随着时间的推移很容易出现小团体。大团队里的小团体，跟完整职能的小团队不同，由于职能不全，能够提供的互相帮助是有限的，还容易引起小团体之间的内耗。
保持小的团队体量，还可以保持团队的灵活性，强迫团队将任务拆分得足够小，这样才能满足“迭代开发、快速试错、小步快跑”这条业界最流行的准则。团队的管理者们要尽力压下自己往队伍里加人的冲动（在官本位思想下，人们总希望自己的手下人数越多越好），时刻关注团队的工作效率和灵活性，而不是人数。
那么多小的团队算小呢？最有名的说法就是亚马逊创始人杰弗里·贝索斯提出的“两个披萨团队”原则（two-pizza team rule）：就是说任何一个团队，不应该超过“点两个披萨就能喂饱团队里所有人”的规模。贝索斯认为超过这个规模的团队在沟通上就会存在浪费甚至是内耗。事实亚马逊也一直是这样实践的，后来结果大家都知道了，亚马逊成为全球顶尖的科技公司，AWS在云计算领域无人能敌，而贝索斯本人也在2018年登上了全球首富的宝座（据2018年7月16日统计，贝索斯身价已超过1500亿美元，是杰克马的3.4倍，为现代史首富）。
两个披萨就能喂饱，如果不是有大胃王的存在的话，一般代表这个团队人数在5-10人之间，6、7人比较理想，超过10人的话就应该考虑拆分团队了。当然并不是说坚持了这个原则就能成为世界首富，只是说这是一个比较科学的划分团队的方法。
小心地设计组织架构
在国内，组织架构是最容易被忽略的一点。很多公司宣称自己是互联网公司，但还是延用了传统行业的组织架构。最典型的就是命令控制型组织：大老板或者高管负责观察市场，制定战略方针，中层经理们负责拆解任务传达指令，底层员工负责具体执行。这种结构从公司制诞生起就一直延用了一个多世纪，是传统公司最主流的组织结构。同时，它跟中国几千年的中央集权式政府组织结构又很类似，所以在国内特别有市场。
然而，到了互联网时代，这种组织结构就玩不转了，因为它并不能适应快速变化的市场环境。首先它全靠老板或者占全员人数少数的高层去观察市场，所以对于市场的变化从感知上就要慢半拍。其次在感知到市场变化后，又是由少数高管来做决策，再通过层层传达命令到基层员工，才完成一次组织对市场变化的响应。这对于处在互联网时代的企业来说是相当慢的节奏。往往在指令还没传达到基层的时候，市场又已经变化了，于是高管重新做决策，再由中层重新层层传达，然后基层员工再次收到的指令就是废弃掉刚做出来一半的产品，转去做新指令要求的产品，如此往复，造成非常大的浪费……
那么在互联网时代应该怎么玩呢？上面已经提到互联网行业最大的特点就是市场变化快，需要公司的产品具有随时能够快速反应的能力。这就需要在做产品的系统架构设计的时候就要注意其灵活性和可扩展性，模块之间耦合性要低，关注于系统架构如何进行演化和迭代开发。只有设计出高灵活性而且能够快速演化以适应迭代开发的系统架构，才能在市场竞争中快人一步，获得先机。
等等，不是在讲组织架构么？怎么扯到系统架构去了？实际上系统架构与企业的组织架构之间联系紧密。这就是著名的康威法则（Conway’s Law）了：设计系统的组织其产生的设计等价于组织间的沟通结构——也即是说我们设计的系统的架构，跟我们所在的组织的组织架构有一层映射关系。比如像上面那种命令与控制型的集中式组织架构，开发出来的产品大多以单块应用（Monolith）居多，发布周期很长，客户响应速度慢，高耦合性，很难做出变更。而如果要想做微服务架构的设计，那么组织结构一般都是一个个小的Service Team，每个团队各自负责各自的模块，团队之间以接口协议的方式进行沟通，可以最大限度地降低团队即模块之间的耦合性，做到灵活可变。
另外，光是注意团队之间的组织架构还不够，还要注意小团队的内部结构。我们已经明确了需要追求团队之间的低耦合性，目的就是为了降低团队之间的依赖。那么很明显的，每个小团队都需要是全职能团队，而不能说：“这项工作我们现在没法做，得等xxx团队的人来做”。当团队之间存在这种强依赖，灵活可变就无从谈起。
那么什么叫全职能团队呢？顾名思义，就是一个小团队里要包含我们在开发产品时需要的所有职能，比如一个团队内部同时拥有产品、开发、测试、运维等等。这些都是指的职能，可以一个人身兼一到二职，但是需要每个职能都有人做，这就是所谓的“麻雀虽小，五脏俱全”。有了这样的全职能团队，每个团队都关注于他们需要提供的“服务”，可以进行快速的设计——开发——测试——部署。整个研发流程都在小团队内部解决，灵活而高效。而团队之间注意以接口协议的方式进行交流，维持低耦合性，可以保证沟通无障碍又没有因为互相依赖而产生的推诿扯皮。无论是团队内部还是团队之间，都关注于解决问题，而不是互相指责。像这样具有灵活性的组织架构，才能够主动适应快速的市场变化，开发出高质量的产品，取得令人满意的成果。
把产品的质量放在第一位
前面我们说过了互联网公司需要快速适应变化无常的市场环境，很多互联网公司都宣扬自己是这么做的，只不过他们都把关注点放在了“快”上面。特别是在前两年的互联网大潮中，各种各样的互联网创业公司如雨后春笋般涌现。这时不知道谁提出了一句“天下武功，唯快不破”的口号，引得各种从“‘人人’转来的产品经理”趋之若鹜。大家都宣称“互联网就是要快”、“要快才能抢占市场”，做个PPT就能拉来投资，想不出好的产品就“抄”，万事俱备找个程序员就能开发产品，快速上线几天就能形成一个爆点，总之就是突出一个字——“快”。然而，当互联网大潮的泡沫散去、资本严冬到来之时，我们看到的是一片一片的互联网公司死在了沙滩上，就连曾经引发爆点的公司（比如足迹）也只能是苟延残喘而已。
为什么？我只能说是这些公司没有理解“快速适应变化无常的市场环境”的含义，这句话的重点不在于“快”而在于“适应”。公司的关注点不应该是“快”，而是要随时保持适应变化的能力。因为你“快”别人也能“快”，所以“快”并不能成为一个公司的核心竞争力，而“适应变化的能力”才是左右公司生死存亡的胜负手。
“适应变化的能力”，是一个很大的课题，涉及到方方面面。但我认为最重要的，就是要把产品的质量放在第一位。
在互联网行业，如何获得用户是公司最重要的课题之一。而要吸引用户来使用我们的产品、以及增加用户粘性，最重要的就是要给用户好的用户体验。这里的“用户体验”并不单单指“UX设计师”那样的视觉、UI方面的用户体验，而是一个广义的范畴：UI、视觉效果、功能性、性能、可用性、易用性、bug的多少等等等等。用户在使用产品的时候会对我们的产品有一个全面的评估：这个产品是否看起来很酷？它的功能是否满足我的需求？它用起来复杂吗？用起来卡吗？在使用过程中有没有遇到什么令人讨厌的bug？……等等。所有这些因素综合起来的结果就是我们的产品对用户的吸引程度，而这一切最终都只能归结为一点——产品的质量。
要知道用户看重的肯定只会是产品的质量，而不是产品功能的数量。比方说我们进行了一次版本的更新，用户拿到新版本进行体验后一定只会说：“这（几）个新增功能不错，我很喜欢”，而不会说：“太棒了！这波更新居然增加了34个新功能！”。这就是“贵精不贵多”的原则：完全解决一个问题要好于部分解决两个问题；开发出一个完整的功能要好于开发出两个半成品。可惜的是，在国内很多公司的产品开发过程中，由于各个业务部门或者产品部门都希望自己的需求能够在下次发布的时候上线，于是拼命地向研发团队塞一堆需求，而且个个都是第一优先级——当所有的需求都是第一优先级，也就没有了优先级。研发团队拿到这些超出他们工作能力的需求，只能拼命加班才能赶出来。像这样赶工出来的功能，质量能有多高，用脚指头都能想到。
把产品质量放在第一位，不能只是一句口号。每位团队成员都应该以此为自己工作的指导方针。
对于优秀的软件工程师来说，把质量摆在第一位是毋庸置疑的，他们总是会身体力行地实践这一原则。这也是为什么之前我们一直强调要招聘优秀的人才。他们的优秀之处并不仅仅限于高超的技术，更多的还是他们本身对于产品的ownership，用中文说就是主人翁精神。
在Google有一个非常著名的真实的故事：早在2002年，那会儿Google刚创立了4年，还属于一家初创公司。在一个周五的下午，创始人Larry Page正在Google搜索引擎上试用自家的产品，想看看按关键字搜索出的广告会是什么样子，毕竟卖广告是当时Google的主要盈利模式。然而结果让他非常失望：搜索出的广告跟他输入的关键字相差甚远，这样下去广告商们肯定不愿意加大在Google的投入，直接带来的是经济上的损失。令人意外的是，Larry Page并没有立刻找来相关责任人来问责，或者开会研究对策，而是把他所有的搜索结果打印出来，然后划出重点，写上“这些广告糟透了”，再贴到公共区域台球桌旁的墙上，就自己下班回家了。除此之外没有告诉任何人这回事。
第二周周一的凌晨5点，一位名叫Jeff Dean（对于现在的软件工程师来说这个名字已经如雷贯耳）的工程师向全公司群发了一封邮件，邮件里说明了他们看到了Larry Page贴在墙上的留言，然后详细地分析了出现这种问题的原因，并提出了一份解决方案，还召集了几位小伙伴一起花了一个周末的时间将这个解决方案的原型做了出来，并提供了测试结果，证明了这个解决方案比现有的算法优秀在哪里。实际上，这个问题本来并不属于Jeff Dean的业务范围，他和他的团队只是偶然来到台球桌旁，然后偶然地看到了Larry Page的留言，他们完全可以当做没看到而后走开。然而正是因为他们对公司的产品拥有特别强的ownership，始终坚持把产品质量摆在第一位，才会主动牺牲自己的周末时间，去寻求解决问题的关键。而正是他们做出来的这个方案，催生了Google后来的核心产品——AdWords引擎，从而产生了一条价值几十亿美元的业务线。
建立有效的质量保障体系
人是感性的动物，容易受到外界环境的干扰，也容易犯错误，特别是在巨大的压力（如上线时间临近）下，哪怕是最优秀的工程师恐怕都难以避免。这些错误造成的后果可大可小，也许只是产生可承受范围内的技术债务，也可能会造成影响巨大的线上事故。所以我们必须建立一套质量体系，来帮助我们的软件工程师们少犯错误。
说是质量体系，其实并不是像很多人想的那样要去设定一大堆的流程，干什么事都要先走paper work，事后还有一大堆的audit。虽然说我以前也进过SEPG（Software Engineering Process Group），还在CMM/CMMI5的公司待过，或者说正是因为我有这样的经历，我才会认为这些东西对于现在的互联网公司来说其实完完全全就是在浪费时间。流程是有用的，但是过于冗长的流程就成了形式主义，宝贵的时间和精力被耗费在了提交各种表格和等待签字审批上面，产生不了任何价值。
优秀的软件工程师们一般都拥有谦逊的品格，他们能够预先意识到“人总是会出错的”，所以会主动利用技术手段来保障自己做正确的事。当优秀的软件工程师们聚集在一起的时候，自然而然就会形成一套质量保障的制度。这种制度并不是一堆表格和签字，也不是一堆大而空没法落地的理论，而是由一系列的最佳实践以及自动化的工具组成。比如，在开发中，优秀的软件工程师都明白自己写出来的代码不是完美无瑕无懈可击的，所以都会坚持主动进行Code Review，不光是请同伴做Code Review，还会利用各种自动化的代码静态检查工具，来保证自己的代码质量。Code Review和静态检查只是第一层保障，我们的工程师还会主动编写单元测试（Unit Test,UT）和集成测试（Integration Test，IT）并且自动化，让自己能够始终在第一时间得到关于代码质量及产品质量的反馈。有了这些也还不够，因为代码并不只是一个人写的，多人共同开发就涉及到代码集成的问题，于是我们的工程师就会引入持续集成，持续不断地做代码集成、自动化测试，将集成代码的痛苦降到最低，同时也能降低因为集成代码而出问题的风险。持续集成再进一步，我们的工程师们又研究出了各种办法，比如蓝绿部署、金丝雀发布、黑启动等技术，来保证团队拥有随时向生产环境安全部署的能力，降低线上事故率，从而做到了我们所说的持续交付。
如果我们拥有足够多的优秀软件工程师，所有的一切都可以通过他们自觉完成。因为他们始终有一颗质量第一的心，那么他们的行为自然而然都是以此为准则的。普通的工程师可能只会说：“嘿，你开发的这个功能这里有个bug”，而优秀的工程师则会说：“嘿，兄弟，你开发的这个功能这里有个bug，它是由这一段代码引起的，我这里写了一段代码可以修复这个bug，同时这边是我写的测试，验证了这个bug确实已经被修复了，还验证了我的修复代码是没问题的。”如果一个团队的软件工程师们都能这样积极主动地对代码负责，何愁产品质量不好？这样的团队必定是不可战胜的。
当然，理想和现实总是有差距，即便是Google，要保证自己团队里全是A Player也是要花大力气的。所以总是可能会有部分不那么优秀的软件工程师在团队之中。我们不希望他们对团队产生负面的影响，这时候就需要引入一些制度和工具来约束他们，使他们的行为能够达到优秀工程师的水准。比如前面提到的持续集成/持续交付框架，自动化测试框架，自动化部署框架等等。和人相比，经过验证的代码肯定是更不容易出错的，所以这些自动化的框架就成了提高工程师水准的工具，我们的目的就是利用这些框架和工具，再辅以互相检查的Code Review，“使人们更容易做正确的事情，而更难以做错误的事情”。
管理好技术债务
只要在软件开发行业内稍微待长一点，就肯定遇到过“这个新版本必须在xxx时间节点上线”的情况。特别是在国内，大部分公司都习惯于做团队人员固定、时间固定、新功能点固定的项目，即便是做产品也经常因为业务方的压力将产品开发项目化。在这种条件限定下，在研发时间不足时，产品质量就是最容易“被妥协”的一项。
这种情况很普遍，而且实际上我认为这也能接受。有的人可能就要问了，你前面不是讲要“把产品质量放在第一位”吗？为什么你现在又说牺牲质量没问题？
那么由我慢慢解释：前面已经多次说过互联网公司与传统公司相比最大的区别就是处于快速变化的业务环境。当一个巨大的热点出现的时候，需要产品立刻响应，上线相应的功能，才能抢占市场。我们都熟悉项目管理的三角理论——时间、范围、质量三者是相互影响相互制约的，这种情况下时间已经固定，需要上线的需求也固定，那么质量这一要素也就被限定死了。这就是我们所说的为了抢占市场而对质量进行的妥协。
但是，对质量进行妥协并不是说质量就不重要了。团队所有人都必须清楚这是为了抢占市场而不得不作出的妥协，是团队欠下的技术债务。
既然叫技术债务，那么就像我们在生活中借钱或者贷款一样，需要制定详细的还款计划，然后按期还款。在生活中逾期还款会被罚利息，而技术债务逾期的话则会以降低产品质量为代价。团队中每个人都必须清楚我们现今的技术债务是什么样一个程度，是否在可接受范围内？在每个迭代中我们需要安排专门的时间来解决之前留下的技术债务，不一定要一次性完全解决，可以分期。同时我们还要注意不要欠下新的债务，以免债务扩大化。如果不好好管理技术债务甚至无视它，那么它就会像滚雪球一样越滚越大，最终会导致产品的质量差到无可挽回，整个团队无力承担技术债务，那么产品只能以失败告终。
所以，千万不能忽视技术债务，“出来混，迟早都要还的”。一旦对质量作出了妥协，未知的bug就成了埋藏在生产环境中随时可能引爆的炸弹。所以我们在一开始就要判断是否能够借这笔钱，欠下这笔债是否超出了我们的偿还能力，能不能在炸弹爆炸前解决它。要牢记：技术债务是高利贷，举借须谨慎。
创造自由而安全的学习环境
这里所说的学习环境并不是指公司要搞各种技术培训，要让员工有自我提升的时间等等，这些是任何公司都应该做的，并不是互联网公司的专利。创造自由而安全的学习环境，是指公司要允许犯错误，不要总是把关注点放在“你做错了什么？”，而是要放在“你从错误中学到了什么？”上面。
有的创业小公司的老板，看了几本类似《从0到1》、《精益创业》这样的书，就天天喊着要“小步快跑”、“快速试错”、“迭代开发”的口号，然而他们并不理解里面真正的含义，也不能接受团队犯错误。他们只是很片面的把这几个概念理解成了“产品开发要快”而已。而只求快自然不会去关注质量，每当产品出现了什么问题，这些老板就把整个团队痛骂一通，甚至认为团队不行，一波又一波地换人。然而换了再多人，业务也没什么起色，因为问题的根源其实就在这些老板身上。
人总是会犯错误的，从来不犯错误的人在世界上、在历史上都不存在。认识到这一点是第一步。同时人又有很强的从错误中学习的能力。这两点其实是人类爬上生物链顶端的关键，也是人类历史发展的关键。最终，对于团队成长和公司业务发展来说，也是关键。
“失败是成功之母”，这句话人人都耳熟能详。人类历史上的所有成功都是在无数次的失败之后才换来的，比如托马斯爱迪生失败了2000多次，才发明了电灯泡。公司老板以及团队管理层首先需要认识到团队犯错误并不是坏事，而是好事——犯错误说明团队又消灭了一种错误的方法，从而向成功又迈进了一步。所以管理层需要给团队一个安全的试错环境，让他们知道犯错误并不会带来可怕的后果，这样才能不再束手束脚，放心大胆地去做各种尝试，尽快找到通往成功的金钥匙。
而团队自己，也需要明白每一次犯的错误都是一次学习的机会，这样才不会浪费时间再次犯同样的错误。与此同时团队也需要理解“小步快跑”的含义——将功能、任务拆解得足够小，每次以“最小可行产品”（minimum viable product，MVP）的方式发布更新，这样在犯错误以后的损失才能被降到足够低，公司也能承受，也才会继续支持团队快速试错。倘若团队总是犯下难以弥补的大错，再大度的老板也吃不消对不对？
对优秀的软件工程师来说，自由而安全的环境就是他们创新思维的源泉。去掉了束缚，有了保障，他们只需要一心一意去研究各种困难的问题，提供各种解决方案。在这种环境下，他们的工作效率将得到最大的提升，他们的工作成果则会直接反馈给公司。公司的业绩增长，业务发展迅速，从而更能保障软件工程师们的工作环境安全。如此良性循环，快速迭代，才是公司走向成功的理想道路。
高效可靠的工程师文化
到这里，我们已经介绍了为什么互联网公司需要建立工程师文化，以及建立高效可靠的工程师文化的七个要素。我们再来简单回顾一下这七个要素的作用：
首先最核心最基础的一点是要关注于人事。要不惜高价地去吸引优秀的软件工程师，因为一名优秀的工程师的产出可以抵过10名20名普通工程师；招来了优秀人才之后还要随时注意他们的“被认同感”，不光是让他们认同公司，公司也要认同他们，并在各方面让他们感受到，这样才能维持团队的战斗力。而团队的建设方针要以发挥小团队的灵活性为主导，要执着地关注于效率而不是人数。随着团队建立起来，就要小心地设计公司的组织架构，因为这和我们产品的系统架构是密切相关的——大而笨重的组织架构只会拖累产品的更新，阻碍业务抢占市场。我们所做的这一切都是为了提高产品的质量，只有优质的产品才能在市场竞争中留住用户，取得先机。而因为我们总是把产品质量摆在第一位，自然而然的就会形成一系列质量保障体系，通过技术手段来减少人所犯的错误。当然错误也是难以避免的，特别是在业务压力大的时候总是会人为妥协，这时候就需要我们好好管理由妥协带来的技术债务，控制好风险，避免带来不可挽回的损失。在现实中，损失也是总会存在的，我们能做的一是将功能、任务拆分得足够小，每次上线一小块，即使有损失也能承担；二是要接受犯错误，将每次犯错误看做是学习的机会，不断学习提升自己，持续学习持续改进，最终通向成功。
高效可靠的工程师文化并不是一朝一夕就能建立起来的，也不是只要交给HR或者行政部门去搞搞就能成的事。它需要全公司从上到下齐心协力，从转变思想入手，按照我们提到的七要素一步一步脚踏实地渐进式地去改变现状。在这个过程中可能会遇到各方面的阻力，又或者被各种突发状况打倒，但是我们必须铭记一句话：“失败并不是跌倒，而是拒绝再爬起来”——建立高效可靠的工程师文化本身也是一个快速试错小步迭代的过程。坚持是值得的，因为在瞬息万变的互联网时代，高效可靠的工程师文化是公司通往成功的一条捷径，更是实现弯道超车的有力武器。
转自微信公众号：胖大蛮
