架构师眼中的文化：组织不扁平，3天后信息衰减到20%

  如果你穿着西装，打着领带去参加一个重要的会议，那么你绝对不会在会场内随便扔垃圾，这是环境给你的暗示，跟制度、规范无关。好的文化会帮助团队营造一种舒适的环境，让每个成员工作更加愉悦。正所谓，强势文化造就强者，弱势文化造就弱者。在体育界，有一个词汇叫“冠军文化”，这就是一种团队文化，每个团队都有自己的性格，当遭受挫折的时候，是一蹶不振，还是强势反弹？冠军文化可以让一支球队在最关键的时刻咬牙挺住，而挺住就意味着一切。

团队文化就好比土壤，要培养什么样的员工，就要有适合他的土壤。传统企业常常去互联网公司挖一些高级技术人才，但是挖过来之后，高级技术人才要么很快就辞职了，要么失去了以前在互联网公司的风采，一个很重要的原因就是无法适应传统企业的团队文化。好的文化会吸引好的人才，并激励他们留下来用最佳的状态工作。

为什么团队文化如此重要

一个经验丰富的职场人士，通过日常工作就能感受到一个企业的文化是开放的还是封闭的，是自由的还是严谨的，是更重视长期发展还是更重视目前收入。管理大师德鲁克曾经说过：“Culture eats strategy for breakfast”。大概意思是说“文化可以把战略当早餐吃掉”，在不好的文化面前，再好的战略也会在一顿早餐后忘掉，团队文化才是战略中的“战略”。每个伟大的公司都有自己非常清晰的团队文化。如Facebook强调的是分享、连接，Airbnb强调的是归属感，Google强调的是透明、发声的权利。

在传统的研发模式下，我们往往忽略了团队文化的重要性，研发流程更像流水线，而研发人员则像流水线上的工人。实际上，一个效率很高的工程师完成的工作量可能是一个效率低下的工程师的几十倍甚至几百倍。

传统企业和互联网公司所信奉的管理文化差异非常大，下面通过一个例子来估算一下成本。

在传统企业，技术经理接到一个单点登录的功能需求，架构师A大概花了一个星期调研，又花了一个星期编写PPT，在某个内部会议上进行架构决策，会议中各方面领导提出了各种质疑，认为某开源方案缺陷太多，漏洞百出。会后A进行返工，最终一个月时间才确定了架构文档，而实际负责开发的可能是工程师B、C、D。A分别对B、C、D进行了大量的解释，B、C、D又给测试人员、运维人员进行了大量的解释。最终这个功能大概花了一个架构师和三个工程师各2个月时间，一个测试人员1个月时间，以及一个运维人员半个月时间。如果架构师的薪资为每月5万元，开发人员每月为2万元，测试人员每月1万元，运维人员每月2万元，那么这个功能预计要花费24万元才能实现。

在互联网公司，根据前面的任务拆分，某工程师A领到了单点登录的功能需求，花了一个星期进行调研，认为某开源产品可以满足80%的需求，经过团队内非正式的讨论，最终决定基于开源产品进行改造。A花了一个星期研究源代码，一个星期进行测试，再经过一轮内部讨论，然后花一个月时间改造代码，一个月时间测试及上线。整个过程不到三个月时间都是以A为主导，如果这个工程师的能力比较强，薪资大概是5万元，和传统企业的架构师持平，那么这个功能预计要花费15万元。

当然，这只是一个粗略的计算，有人可能会质疑，互联网公司打造研发环境、工具所消耗的费用，同样互联网公司也没有计算技术经理/项目经理的管理费用。一个实际的例子，Instagram Video（15秒短视频）从需求到上线花了30个人一个月的时间，包括iOS和Android客户端、服务端，甚至包括市场及推广，在这期间为了解决防抖的问题，甚至花了7天时间收购了一家公司集成进来。

李开复曾经说过：“我们进入了信息社会，这个社会跟工业社会不一样的就是，顶尖人才和普通人才的差异化不再是20%、30%了，而是五倍、十倍甚至一百倍的差距。”

从结果上来讲，互联网公司的研发模式效率要更高，除了流程的问题，还有一个重要的原因就是团队文化。我认为，团队文化可以刻意塑造。一个团队的文化改变很难，管理者对团队文化的影响力巨大，他的所有言行都会影响团队文化，因此改变团队文化最简单的办法就是换管理者，但是这在很多场景下显然是不现实的。

组织结构

团队规模导致的问题

随着团队规模的扩大，我们通常能见到以下几种严重的问题。

（1）缺乏信任。由于人数众多，难于管理，只能通过制度、流程、规范、绩效约束。因为一切都是以KPI为前提的，那些跟KPI无关的工作是很难推动的。公司的执行力确实很强，员工绝对服从，不容易出错，但是效率却非常低下。

（2）没有责任感。高层管理者忙着开各种决策会议。除了管理者，没有人愿意去决策，因为决策失误将是非常大的责任，而领导决策后，就算出现什么问题，也有领导扛着。结果就会出现大量的架构文档，大量的内部汇报材料，取悦领导的优先级高于服务客户的优先级。如果没有人能够承担责任，那么就靠严格的流程，每个人都严守关口，否则出了问题自己要“背锅”。

（3）部门墙。跨部门协调还不如与第三方合作。我曾经工作过的一家互联网公司便有这类情况，有的部门宁愿去外部买一个系统，也不用兄弟部门的产品，原因是内部跨部门沟通效率太低。

（4）不尊重专业人士。当所有的生杀大权都掌握在少数人手中的时候，就非常容易形成“一言堂”，领导的话会被仔细推敲，而某些领域的专家可能因为在汇报中，思维不够敏捷，不善于表达，而得不到尊重。

（5）管理层级太深。管理层级太深导致的问题很多，因为管理者不知道下面的人在干什么，不知道钱花得值不值，只能通过汇报，那就会导致了很多会议和汇报文档。

康威定律

“康威定律”（Conway’s Law）包括如下四条。

· 第一定律：Communication dictates design，即组织沟通方式会通过系统设计呈现。

· 第二定律：There is never enough time to do something right, but there is always enough time to do it over，即时间再多，一件事情也不可能做得完美，但总有时间做完一件事情。

· 第三定律：There is a homomorphism from the linear graph of a system to the linear graph of its design organization，即线型系统和线型组织架构间有潜在的异质同态特性。

· 第四定律：The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems，即大的系统组织总是比小系统更倾向于分解。

康威定律中最经典的一句话“Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.”即设计系统的组织，其产生的设计和架构等价于组织间的沟通结构。通俗来讲，就是什么样的团队结构，就会设计出什么样的系统架构。如果将团队拆分为前端、后端、平台、DB，那么系统也会按照前端、后端、平台、DB结构隔离，如图10-1所示。

如果将团队按照业务领域进行拆分，系统就会按照业务领域隔离，如图10-2所示。   

图10-1  系统架构（一）        图10-2  系统架构（二）

因此当我们在进行架构设计的同时，也应该相应地调整组织架构。特别是在采用微服务架构的同时，应该建立全功能团队，开发、测试、产品应该在一个团队内。项目管理、团队负责人并不一定是专职的，可以由产品或者开发兼任，但最好不是一个纯管理人员。某些公司还设置轮岗，效果不错。

扁平化的组织

“沟通漏斗”是指工作中团队沟通效率下降的一种现象：如果一个人心里想的是100%的东西，当你在众人面前、在开会的场合用语言表达心里100%的东西时，这些东西已经漏掉20%，你说出来的只剩下80%。而当这80%的东西进入别人的耳朵时，由于文化水平、知识背景等关系，只存活了60%。实际上，真正被别人理解了、消化了的东西大概只有40%。等到这些人遵照领悟的40%具体行动时，已经只剩20%了。三个月后信息衰减得有可能只剩下5%了。

沟通漏斗模型，如图10-3所示。当管理层级太多时，就会造成信息传递衰减，轻则执行力差，重则军心涣散。据说Amazon实施微服务架构的初衷就是为了减少沟通，而很多伟大的互联网公司都试图通过扁平化的组织文化来弥补因为公司规模导致的沟通不畅、责任感下降等问题。

图10-3  沟通漏斗模型

软件研发型公司应该尽量减少中层管理者，特别是纯粹的“中层管理者”。公司的董事长应该关心中层管理者每天的工作内容，大多数层级比较多的公司，中层管理者的工作就是每天不停地开会、汇报。如果董事长要看1页PPT，总裁可能要让下面的总经理准备10页PPT，总经理会让下面的部门经理准备100页PPT，部门经理会让团队负责人准备1 000页PPT。假设，每个PPT新建加修改需要2天，一年汇报3～5次，PPT产量就会很高。减少一个层级，工作量就会降低十分之一。另外，在这个信息传递的过程中，部门经理为了弄明白小团队负责人的想法，不知道要开多少次会。

独裁的管理方式还是民主的管理方式

实际上这个问题并不好回答，因为无论是民主的管理方式还是独裁的管理方式，在当今的商业社会都有成功的案例，也都有失败的案例。

独裁的管理方式更强调个人能力，一位远见卓识的领导者可以将这种管理方式发挥得淋漓尽致，乔布斯就属于这种人。据苹果的员工描述，乔布斯不会给任何员工面子，经常在公司内大发雷霆，在乔布斯面前，没有任何民主可言。下面通过两个故事来描述一下苹果公司的管理风格。

据说新员工入职的时候会安排他们见乔布斯，可以见到自己的偶像员工们都非常兴奋，但是新员工们的热情提问，往往换来的只是冷冰冰的几个字，既简短又粗暴。乔布斯如果觉得问题不好或者不想回答时，干脆直接说下一个。有一位新员工曾问乔布斯：“您觉得最快乐的事情是什么?”乔布斯不耐烦地回了一句：“没有比这个问题更傻的了。”这让提问者无比尴尬。

另外一个故事，据说在1997年乔布斯刚回到苹果的时候，因为大规模的“砍项目”，乔布斯把暴君形象发挥得淋漓尽致。那个时候，说不定哪天，某个项目组就会突然被解散，平时在一起办公的同事会突然走过来向你告别。苹果内部流传着一个听来让人不寒而栗的故事，说不定哪天坐电梯的时候就会遇上乔布斯，他会问你：“你叫什么名字？在哪个项目工作？你的工作重点是什么？对公司有什么价值？未来有什么计划？”几乎没有人可以在让人窒息的电梯间里，在乔布斯威严气场的笼罩下，顺利回答上面这几个问题。而一旦员工的回答让乔布斯不满意，员工在电梯里听到的最后一句话就一定是：“好吧，你明天不用来上班了。”

这种独裁的管理方式强依赖于个人能力，当这个企业的领袖能力较强时，这种管理风格高效、快速，拥有强大的执行力，但是如果领袖犯错，那么企业也会跟着走向万丈深渊。因此，这种方式不是每个企业都适合的。虽然乔布斯的管理风格让很多人不舒服，但是乔布斯的能力毋庸置疑，可以说是当时世界上最好的产品经理和市场经理，通过一个人带领一个公司的产品走向成功。乔布斯的产品理念更多的是引领用户，解决了甚至连客户都未曾考虑到的问题，而不是根据用户的反馈来进化产品，这跟很多互联网公司的理念是不一致的。

对于一个独裁者来说，首先，可能自己没有意识到自己正在犯错；其次，用自己过去的经验做决策。第一代iPhone受到了当时微软的CEO鲍尔默的嘲笑，因为他认为六七百美元的价格太高了，而苹果开创了另外一种营销模式——和运营商合作，按月支付。摩尔定律已经提出了半个世纪，并且似乎还在按照这个趋势发展，谁能保证这个定律一直有效呢？也许未来会打破这个定律。

而民主的管理方式认为世界上不存在完美的人，一个人的决策不可能都是对的，要充分发挥每个员工的能力。由于独裁者通常都比较严苛，下属生怕说错话遭到鄙视、摧残或粗暴对待。因此，这种管理方式无法发挥下属的潜力。民主的管理者更像是一名园丁，通过不断“修剪、浇水、施肥”，让每个人充分发挥出自己全部的天赋，服务大于管理。作为一线员工，你无须关注听命于谁，而是更多的要拥有主人翁精神，在这种民主的企业里，一线员工最重要，这里讲一个Facebook的故事。在Facebook，当几个程序员在一起解决问题的时候，主管会去几公里以外的地方买回来丰富的点心，管理者通常更像后勤人员一样为程序员提供服务。很多企业也会有能力不行的人做管理，显然这种管理者是指挥人员，拥有至高无上的权力。

在民主的企业中，通常创始人或者企业领袖会给公司制定规则，进入公司即代表你认同规则，所有人都要遵守。例如玩一种扑克牌的游戏，假如你感兴趣就一起来玩，但是不允许任何人违反规则，在规则内可以自由发挥。民主通常伴随着透明、公开，这种文化意味着更强大的创新能力。另外，在民主的制度下，不会去设置更多的障碍和流程，更强调自主决策和责任感，一旦偏离了轨道，就只能被淘汰。

民主也会有很多弊端，例如统一思想的成本会非常高，执行力较差，不容易协作完成一件事。

民主的团队如何做决策

前面谈到，民主的团队在决策的时候是痛苦的，即很难统一所有人的意见。如果让该领域的专家决定，那么他的思路有可能不够开阔，没有高度；如果让管理者决定，那么他又可能缺乏该领域的专业知识；如果让所有人投票决定，那么效率又太低。

实际上，我认为一种好的决策机制应该是这样进行的。

（1）由领域专家做一些简单的前期调研，收集材料，初步计划。

（2）通过邮件发给决策团队，决策团队成员不应该人数太多。

（3）开会讨论，大家各自发表意见。

（4）进行投票，少数服从多数，可以先投出前两名，然后各自发表意见，再针对前两名投票决策。

这是一种非常公平的做法，每个人的意见都得到了充分讨论，如果不能按照自己的意见执行，也应该心服口服。关于这个问题，《原则》一书给了我们很好的启示。

可信度加权决策法：充分考虑到每个人的专业背景，然后对不同专长的人提出的意见赋予不同的权重，最后加权计算进行决策。也就是在针对一个重大决策征询意见时，该领域的专业人士的意见权重就会更大，非专业人士的意见权重更小，比如讨论的是一个医疗问题，有医疗背景的人提出的意见所占的权重就应该更高。

相对于一个人做决策，这种流程还是比较复杂的，需要开会、投票，只有涉及重大问题才有必要采用，否则效率会很低。

环境氛围

公开透明的工作环境

如果你撒了谎，就要不断提醒自己曾经和谁撒过谎，这会消耗你相当大的一部分精力，而真实、透明可以让你轻松很多。在企业中也一样，越是公开透明，效率就会越高，就越能得到理解，满意度就会越高。不要告诉员工，管理者都是天才，是不会犯错的。实际上，公开透明的工作环境是彼此信任的基础。

每个人每天的工作、会议，包括领导的，公开透明地展示给其他人，当然这不需要通过写工作日志来展示，可以利用工具。如果你是一个技术经理，可以在Outlook中共享每天的会议日程；如果你想约见领导，绝对不需要跟领导的秘书沟通，也不用问领导什么时间有空，而是到Outlook上查一下领导什么时间有空，如果会议时间和某个人有冲突，完全可以拒绝或者建议修改会议时间。

当然，为了提升工作效率的一切行为都是值得提倡的，工作中，我们常常会被乱七八糟的事情打断，因此，我建议每个员工都应该有不打卡的权利，有不在工位工作的权利。例如，当某个项目紧张的时候，马上面临交付时间点，开发人员为了不被其他人打扰，选择在家办公是应该被鼓励的，你认为这么紧张的时刻他会钻空子吗？当生产环境出了问题需要解决的时候，你认为解决问题的人会去浪费时间吗？如果真的有，那这个人就不应该存在于这个团体里。

学习型组织

如果仔细研究企业的生命周期，不难发现，一个企业是很难长时间生存的，“百年老店”屈指可数，无论你现在看到的企业有多么强大，它最终都会退出历史舞台，并且这个时间不会太长。如何才能不断地刺激团队，让团队焕发活力呢？那就需要建立学习型组织，使团队不断改进，获得持续的竞争优势。

并不是只有看书才叫学习，学习充斥在各个角落，例如，Code Review就是一个相互学习的过程。通过如下方式可以建立一个学习型组织。

· 让团队拥有共同的愿景、目标。NBA最经典的一句话是“永远不要低估一颗总冠军的心。”当一个团队有了共同的愿景之后，成员就会忘记自己的角色，只要是对团队有利的就去执行。

· 让团队持续学习。学习不是一次性的，是一个持续的过程。当害怕自己说的话可能是错误的时候，就应该去学习了。

· 团队成员平等、自由。只有拥有平等的氛围，才能换位思考，不以过去成功的经验轻易否定一些创新性的想法。

· 团队成员自我驱动、自我管理。不依靠严格的制度管理团队，团队成员具备自我管理的意识。

· 团队积极、有凝聚力。团队成员积极乐观，具有主动性，不推卸责任，团队气氛融洽。

— 团队内部，应该通过不断交换意见获得成长，寻找机会刺激团队成员去思考、分享。

— 团队外部，应该通过一些外部会议、论文、书籍等来开阔团队成员的眼界。

减少正式的汇报

试想，如果你在一个大公司，让你实现一个邮件服务，你可能会去学习现有的邮件系统，分析竞争对手，引进竞争对手的人，借鉴竞争对手的架构，使用一堆架构模式、方法论、框架，分析我们如果完成一个这样的系统会在哪些方面超越竞争对手，这是一个大公司的正常逻辑。等我们忙活了半年真正实现了，结果用户可能不会买账，因为没有任何新意，但是我们每次都汇报得不亦乐乎。这就是一个大公司花高额的年薪聘请了高学历的人才做着平庸的产品的生命历程。大家只关心KPI，而KPI是由你的主管决定的，如果按照这个套路至少不会“犯错”，因为所有人都“错”不起，结果顶尖人才不是在汇报就是在写PPT。

与此形成鲜明对比的是，那些伟大公司的领袖都有减少汇报的要求。乔布斯不允许使用PPT汇报，不仅仅是因为做PPT浪费时间，还因为乔布斯希望他的团队能够进行激烈的争辩和批判式思考，而不要依赖PPT。据说比尔·盖茨也不会让下属去给他汇报，他会走到下属的工位，随便聊几句，用一个便利贴记住谈话的结论。这种随机聊天反倒会得到最有效的、没有经过修饰的信息。

有人会问，领导怎么了解进度啊？怎么识别风险啊？怎么判断谁干得好，谁干得不好啊？出了问题该由谁来负责啊？我认为，公司内部的项目管理工具上应该能直观地看到进度，这是动态的，绝对比汇报的内容要更真实、更快捷。软件做得好不好应该由用户去评价，一方面通过用户的反馈意见，另一方面通过自己收集到的数据综合判断，而不是通过几页PPT去了解。至于谁干得好，谁干得不好，应该由和他朝夕相处的人去判断。另外，团队成功才是真正的成功，如果害怕大锅饭导致效率低，完全可以换一个更好的搭档。

高效的会议

开会的目的和意义是什么？晨会、周例会、月例会、计划会议、总结会议、行政管理会议等各种会议，作为会议的主持者或者团队领袖，在会议中应该扮演什么样的角色？

会议的效率低下，主要可以总结为如下几个原因。

· 参会人数太多。如果一共20人参会，平均每人花费6分钟，那么两个小时就过去了。

· 不明白为什么要开会。实际上好多会议的目的并不明确，导致参会的人思维特别发散，会后没有任何成果。

· 会议没有主持人或者引导者，思维太发散。

· 会议中存在分歧，短时间内很难达成共识。

· 会议中的不平等，会议中有的人不敢说话或者插不上话。

会议最主要的目的是达成共识。少数人服从多数人，说服决策者。

缩小会议范围。除了培训之外，如果参会的人只是听，而不发言，那么此人不应该参会。不发言意味着他对会议议程和结果不会产生影响，同时他有很多其他途径可以获得会议内容及结论。要么带着问题参会，要么带着信息和观点参会。如果你让他参会就应该给他发表意见的机会，而不是让会议变成“一言堂”，或者是几个思维敏捷者的会议。在这种情况下，会议主持者应该学会自己聆听，分析所有人的意见。一个高效的会议，聪明的会议主持者是必不可少的。他可以让所有参会的人都发挥出最大价值，而不是所有人的观点都偏向某位领导或者意见领袖。此时，整个会议的价值大大降低，只剩下少数人的价值得以发挥。

常规会议不应该超过45分钟。怎么做到呢？答案就是会前要准备充分。据说在Amazon会议前10分钟是用来看文档的，让每个参会的人都了解今天的会议内容，当然这10分钟也可以放到会议之外，看完文档直接讨论，这样一般会议时间可以控制在半小时以内。另外，如果存在巨大的分歧，无法形成妥协，最好暂时停止会议，经过一段时间的思考，重新决策，而不是一直在会议中争论。

限制“意见领袖”的发言时长。会议主持者要控制“意见领袖”的单次发言时长、发言的频率，以平衡所有参会者的发言时间。关于这一点，可以参考法庭，无论是原告还是被告，都认为自己是正确的，需要轮流发言，如果不加以限制，就会乱成一锅粥。如果存在一个经验丰富的会议主持者，可以不断总结、概括，将会使会议的效率大幅提升。尝试让不爱发言的人先发言，这样有利于不爱发言的人提早进入角色。

提供平等的会议氛围。统计表明，机长驾驶飞机出事故的概率高于副机长驾驶飞机出事故的概率，因为机长驾驶的时候，就算副机长发现有什么不对，一般也不敢指出。而副机长驾驶飞机时，机长在旁边监督，一旦发现问题，机长是没什么顾虑的，可以直言不讳。机长就像是领导，往往会议中机长说了太多的话，出问题的概率更高，因此领导更应该学会聆听。

会议中不允许开小差。开会时，如果一会儿接电话，一会儿发邮件，每个人带笔记本电脑不停地打字，或者在底下不停地摆弄手机，那么这个会议将变得非常低效。这时候会议主持者就需要起作用了，时不时地发问，让每个人进入思考模式。总之，开会时所有人都应该聚精会神。

会议中的分歧不应该延伸到会议之外。讨论过程中可以自由发挥，分别阐述自己的思路，会后要保持一致，不应该因为会议中自己的观点没有得到支持而怀恨在心，应该从别人的角度尝试考虑一下。

以上会议规则应该贴在会议室中，时不时地提醒开会的人遵守，甚至要通过预定会议室的时间来限制会议时长。我从未见过超过一个小时的会议还能让所有参会者保持很高的专注度的。总之，会议室是一个企业文化的体现，企业文化的形成需要企业领袖不断地推进、示范。

关于如何高效率开会，可以参考《罗伯特议事规则》，这本书是美国国会开会的规则，应用十分广泛。

量化指标致死

量化指标是指能用具体数据来体现的指标，以数据反映人类各种活动。常见的量化指标如KPI、某个产品的性能等。我并不反对量化指标，但是反对量化指标的考核方式，反对不成熟的量化指标，反对一厢情愿的量化指标。

海底捞的掌门人张勇用自己的经历说明他的KPI量化指标是怎么被打败的，值得深思。海底捞的服务好不好？有很多吃饭的人都是冲着它的服务来的。但是以前海底捞的KPI是量化的，例如杯子里必须要有水，那海底捞就设定了一个指标，客人杯子里的水必须达到一半。后来发现，有的客人吃完饭要走了，说：“我不喝了”，服务员说：“不行，我得给你满上”。更好笑的是手机套，客人表示不需要，服务员就趁你不注意的时候给你的手机套上，我在海底捞亲眼见过类似情景。

这就是量化指标，也可以说是硬性指标。并不是说量化指标不好，而是说以量化指标来考核，特别容易导致考核畸形，会让被考核的人忘了指标原本的目的。当然这些指标是可以有的，可以用来做报表、做统计、做参考。软硬结合也是不错的，不过千万不要高估自己对指标的理解能力。

话说我曾经工作过的一家公司以前是不打卡的，非常自由，这个公司在业内的口碑还不错，实际上大多数人并不会因为不打卡就觉得工作少，打卡与工作量根本没有关系，这个谁都知道。有一天老板上午11点到公司发现好多员工刚刚进门，一怒之下，要求员工不但打卡，而且加薪的时候日平均打卡时间必须满9个小时。我觉得这样的结果是老板比较安心了，看着指标开心了，而公司的口碑下降了，招人难了，还会有很多员工比较难受，琢磨怎么应付。

再说KPI量化的问题。实际上，量化对小团队的管理者是有帮助的，年底绩效考核的时候会有依据，比较容易区分。但是还是有问题，例如，你平均写的代码行数、发布次数、故障率、可用性等，工程师们一定知道怎么绕过。员工多了，真的不好管理，特别是基于不信任的前提下的管理。

对于程序员这个人群，柔性管理往往起到的效果更好。

举个例子，很多刚入职的女程序员认为她们被歧视了，不好找工作，我并不这么认为。如果面试官是我，我会适当降低标准把女程序员招进来，因为我让她来不完全是写代码的，所谓男女搭配，干活不累。有的时候比你给下属打个A起到的效果都好。张勇也举过这类例子，他的一个非常优秀的员工离职了，原因是前台那个女员工明确告诉他不喜欢他。

本文节选自《持续演进的Cloud Native：云原生架构下微服务最佳实践》一书,王启军 著。电子工业出版社出版。

点击阅读原文，可直接购买此书

往期推荐：

技术琐话 

以分布式设计、架构、体系思想为基础，兼论研发相关的点点滴滴，不限于代码、质量体系和研发管理。