团队价值观要尽量保持一致，否则代价你承受不起

神译局是36氪旗下编译团队，关注科技、商业、职场、生活等领域，重点介绍国外的新技术、新观点、新风向。

编者按：现在企业在文化建设时往往很看重多元化，因为可以取长补短、提高决策质量，提升创新能力等。但大家的价值观必须尽量一致，这个不是什么空虚飘渺的套话，会产生实实在在的影响，对小团队的影响尤其更大。文章来自编译。

这篇文章总结了我看一场演讲（题目为平台作为价值观的体现）的收获。演讲令人大开眼界，它帮助我理解了为什么我过去会跟部分团队成员一次次地发生同样的分歧。

让我们想象有这么一个宇宙，你和我都是一支小型工程团队的成员。

我这个人很重视测试。我相信以下几点：

• 自动化测试可以防止软件在生产环境中出现回归问题

• 测试容易的代码调试也不难。毕竟，调试过程通常是编写测试过程的前奏！

• 编写测试是确认自己做的正是自己想做的东西的绝佳方法。

你很看重简洁。你可能会相信以下这些：

• 代码库越简单，隐藏错误的地方就越少。

• 由于活动件较少，一旦知道了bug到底是什么，就更容易修复好bug。

• 设计越简单，实现起来就越简单，从而呈现在用户面前也越容易。

我们俩都认为测试很好！我们俩都认为简单代码比复杂代码要好！套用 Cantrill 的话来说，没人一觉醒来的时候会希望自己的代码运行缓慢、难以阅读、难以调试、脆弱且难以测试！

但虽说我们都认为这些是好事，但大家的核心价值观却不一样。我们花时间去深入思考和推动的事情也不一样。实际上，这意味着，当面临处理工作的优先事项时，我不会选择你会选择的东西。

在这个宇宙里，你直接提交了一堆代码。但为了让测试更容易些，我得“修复”你的代码变更，添加依赖项注入或将 I/O 从逻辑当中分离出来。在此过程中，我引入了回归（由于缺乏严格测试，所以没有发现bug！）

在同一个宇宙里，你很快将想法变成了代码，然后“准备部署”。你的代码没有错误。不是“我认为没有错误”，而是确实没有错误。但我的回应是“让它更难读懂来证明这一点”。坚持要引入“测试实现”的单元测试。最后，有些只需 5 行代码的函数现在变成了 25 行，还隐藏了 2 层抽象。

我一层一层地编写服务，你得把它们拼凑在一起才能得到一条从 A 到 B 的直线。对服务层如何交互的困惑导致交付的功能完全不符合规范，因为 10 行的规范最终需要触及 5 个不同的文件。

你在 6 个不同的地方写了同样的遍历逻辑，却没意识到这是同一件事。一旦出现逻辑错误，我就得重构。我可以为这些遍历引入测试，但这些是否是你期望的语义却很难把握。

这些事都可以解决。但究其根本原因是我们之间的价值观差异。我们可以在出问题的时候再解决，但同一个话题你还想争多少次？治标不治本可能会让人沮丧，但如果原因纯粹是主观上的话，那就更让人沮丧了！

团队有一套价值观，团队成员也有自己的价值观。如果大家的价值观完全一致的话，你可能会说一定还存在盲点（编者注：潜台词是多样性可能有助于消除盲点）。但如果大家高度一致的话，则盲点几乎就不重要了！

同时，如果团队就两个人，而且双方价值观差异很大，那么除了正常的开发工作外，他们的工作现在就会变成一场拉锯战。

实际上，如果说你的小团队还没有分裂的话，那就可以说团队成员很可能价值观有很好的一致性。

在大一点的团队里，大家价值观完全一致是不太可能的。不同的小组或团队成员可能会有些价值观一致，这导致了团队内部的多样性。结果？各团队根据自身的特长做出贡献，不同价值观的团队共同推动整个项目的成功。尽管偶尔会有争论，但成员间不会觉得孤独，因为总会有些人支持他们。

在规模更大的团队里，你可以用结构化的机制来处理价值观上的差异。借助更加正式的协调工作，讨论可以不再依赖情感，而是基于规格说明、时间表或KPI来达成共识。虽然价值观的正式化工作需要付出很大的努力，但这能帮助团队更加舒适地应对不同的价值观，减少因个人观点不同引发的争论。

在小团队里，价值观不一致可能会更加明显，甚至对团队生存产生致命影响。小团队之所以能生存下来，通常是因为团队内部的价值观强烈一致。所以，一旦新成员无法很好地跟团队的价值观对齐，问题就会被放大。届时局面不再是“一对一”，而是“一打四”。抵触会更加强烈，在一些问题上新成员往往很难找到同盟。

新人非常关心的事情会遭到强烈反对。通常这些讨论会陷入到优先事项之争。“我们可以晚点再做这个”是常见的口头禅，但在这样的语境下，“晚点”其实上就是“永远不做”的意思。至少在目前的团队构成下不会做。

最终的结果是，很多人都会感到沮丧，因为谁都没错。他们只是价值观不一致而已。

大家一般会希望团队里面技能不一样的人，从而帮助提高团队的整体技能。技能跟价值观不一样，但一般来说，人擅长自己在乎的东西。小团队能不能承担存在不同价值观的成本呢？我不敢肯定。

译者：boxi。