如果你穿着西装，打着领带去参加一个重要的会议，那么你绝对不会在会场内随便扔垃圾，这是环境给你的暗示，跟制度、规范无关。好的文化会帮助团队营造一种舒适的环境，让每个成员工作更加愉悦。正所谓，强势文化造就强者，弱势文化造就弱者。在体育界，有一个词汇叫“冠军文化”，这就是一种团队文化，每个团队都有自己的性格，当遭受挫折的时候，是一蹶不振，还是强势反弹？冠军文化可以让一支球队在最关键的时刻咬牙挺住，而挺住就意味着一切。
团队文化就好比土壤，要培养什么样的员工，就要有适合他的土壤。传统企业常常去互联网公司挖一些高级技术人才，但是挖过来之后，高级技术人才要么很快就辞职了，要么失去了以前在互联网公司的风采，一个很重要的原因就是无法适应传统企业的团队文化。好的文化会吸引好的人才，并激励他们留下来用最佳的状态工作。
为什么团队文化如此重要
一个经验丰富的职场人士，通过日常工作就能感受到一个企业的文化是开放的还是封闭的，是自由的还是严谨的，是更重视长期发展还是更重视目前收入。管理大师德鲁克曾经说过：“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 系统架构（二）
因此当我们在进行架构设计的同时，也应该相应地调整组织架构。特别是在采用微服务架构的同时，应该建立全功能团队，开发、测试、产品应该在一个团队内。项目管理、团队负责人并不一定是专职的，可以由产品或者开发兼任，但最好不是一个纯管理人员。某些公司还设置轮岗，效果不错。
