带开发团队几个月，我发现每天要处理的摩擦大多不是技术问题，而是大家对一些没说出口的默契各有各的理解：代码评审多久该回、“完成”到底算到哪一步、在 Slack 上催第二次算不算失礼。谁都没错，只是我们从来没把规则讲清楚。
解决办法有个很无聊的名字：团队规范。Center for Creative Leadership 的定义是“一套塑造团队成员互动方式的规则或运作原则”。听起来像 HR 的表格，其实就是把大家以为不言自明的东西写下来。
说服我的那项研究#
Google 的 Project Aristotle 研究了公司内部 180 多个团队，想弄清楚好团队到底好在哪。答案出乎意料：团队里有谁，远不如团队怎么协作重要。就算凑齐一屋子高手，要是协作方式一团糟，结果照样平庸。
研究找出了区分强团队的五个要素：心理安全感、可靠性、结构与清晰度、意义感、影响力。其中作用最大的是心理安全感——敢问蠢问题、敢承认错误，而且不用为此付出代价。相关的数字很难让人无视：解释了 43% 的绩效差异，生产力高 19%，创新多 31%，离职率低 27%。
我最喜欢这份清单的一点是：五个要素没有一个是天生的性格，全都是团队可以刻意建设的东西。而规范就是建设它们的工具。
日常里的规范长什么样#
从会议入手最容易，因为坏习惯最显眼：议程提前发，准点开始准点结束，反驳之前先复述对方的观点。我很喜欢那条不留情面的规则：没有议程就不开会。
沟通规范更重要，但更难被看见。我的原则归结起来就是：宁可多说也别少说，决策写在所有人都找得到的地方，别让会议成为唯一的渠道。八个人的会上总有人一句话不说，那就直接去问他们。视角多元的团队胜过同质化团队的证据很多，但前提是那些视角真的被说出来了。
至于分歧：先假设对方是好意，跟问题吵而不是跟人吵，去挖对方真正需要什么，而不是纠缠他摆出来的立场。极少数吵不完的架，就请中立的第三方来。
怎么定规范才不变成官僚主义#
我认可 CCL 推荐的做法：从经验出发，而不是从理论出发。每个人讲讲自己待过的最好和最差的团队，一起挖为什么会那样，再把浮现出来的模式变成针对这个团队的具体行为——讨论出来、达成一致，而不是自上而下发文件。事先说好有人违反了怎么办（包括经理违反的时候），写在显眼的地方，隔段时间回头看看。
我只想补充一条：一开始只定三到五条。规范要变成习惯才起作用，没人能同时养成十个习惯。
容易垮掉的地方#
杀死规范最快的方式，是无视规范的领导。如果我以“太忙”为由跳过议程规则，团队马上就能看穿，整件事立刻变成表演。负责人的言行一致，比任何一条规范的措辞都重要。
另外几个我留意的坑：新人靠口口相传“领悟”规范，而不是在入职时被明确告知；全球化团队把自己的默认当成所有人的默认（把隐含的假设讲明白）；还有把整件事当成走过场的人——对付这种情况，最有效的不是说教，而是拉他们一起来写规范。
知道规范在哪里被强化也很有用。对高绩效团队的研究反复发现同样三个习惯：像样的 kickoff、定期的一对一、还有回顾会。共识是在这些场合里形成、被检验、悄悄更新的，不是在制度文档里。
我不觉得规范是魔法。但 Google 的数据和我目前的体会指向同一个方向：团队怎么协作，胜过团队里有谁。所以我们的规范会保持简短——几条共识，写在所有人看得见的地方，不符合现实了就改。至于有没有真的落地，半年后再问我吧。