工程师的疑惑
最近在豆瓣关注了一个网友，发了很多关于工作的片段化判断。例如关于站队抱团问题、关于新旧技术的迭代、关于怎么包装结果去获得晋升。看到他的帖子，就像看到我的一个朋友，他在工作的早期也遇到了这些问题。不过他后面通过换公司，一定程度上少了很多类似的困扰。
这位网友，看起来像是在字节工作。我很好奇，宣扬坦诚清晰的字节，为什么还会有站队斗争的问题，为什么还会有过度包装成果以换取晋升的问题。因为正如前面分析过的《战略历程》所言，公司不是给员工提供政治斗争的决斗场，而是一个提供交付、提供产品服务给到客户的地方。
工程师与团队
这个问题的起源，我仔细想了想，大概是作为geek的工程师，在面对团队中的人的关系时，表现出的正常的困惑。就这个问题，我的那位朋友，多少也遇到了（虽然没有字节老哥夸张）。我的这位朋友会好奇，什么样的团队是能够产出优质产品和服务的团队。作为工程师，我们的能力上限在哪里，团队的意义是什么。如何作为一个受欢迎的工程师，融入团队，带领团队营造出色的团队氛围。
带着上述疑问，我阅读了《极客与团队》一书。这本书的起源，是谷歌开发者们，就版本管理的开源社区发生的事，总结而出的经验。关于geek、关于怎么运营好一个开源社区的。后来逐渐抽象成了，作为工程师，如何借助团队的力量，如何避免那些害群之马，如何培养出色的团队文化。
工程问题都很简单，但人际关系却很难把握。这对于刻板印象下，呆板、木讷的程序员来说，可不是一个好消息。然而一个人的力量始终有限。只有借助团队，优秀工程师的能力，才能得到放大。相信聪明的工程师读者们，有能力习得一些技巧。
没有天才
在软件开发领域，常常会流传很多天才传说。例如一个人写出Linux、写出语言框架这种。但要知道，他们其实只写了一部分代码，后续的工作完善，其实有上百名工程师参与。这件事要传达的意思在于，软件的成功不在于你的代码多么神通，而在于你能否很好的合作。忘掉那些单打独斗造神的故事吧，即使比尔盖茨、乔布斯他们，在早期也是好几个人搭伙做起来的。
在程序员里面，流行这样一种思维：我得把代码藏好。这就说到很多大厂的开源项目。网上会批评国内的一些大厂，能赚钱但很少开源代码。不过也有人指出，它们不开源不是因为这是核心机密，而是因为代码写得太烂了... 在程序员里，也会有这种思维。其实这就是没有安全感的一种表现。害怕被别人看笑话被批评，或者是同事看到自己的代码想法，抢先发布了我的特性。
分享是有好处的。这点我的体验也是如此，很多模型框架，帮助了我们获得快速的起步。分享给别人，你能够发现自己是不是在重复造轮子。也能够快速尽早地检验方向。对于团队来说，这也可以强化公车因子（即通勤公车上困多少人，会影响到项目）。越多的人了解项目，公车因子就越大。
团队才是王道
想必看我文章的同学都多少经历了一些软件开发项目。你一定会发现，这东西是集体项目。如果你的节点很小，那很可能就是个单点项目了（这种项目很危险，上期的文章也有讲应对策略）。
经历过不同团队的你也一定发现，有些团队待得很难受。大家相互提防，各说各话。在一个会议上，迟迟得不出有效结论。你做的东西别人不信任你，你也不想用别人造的垃圾轮子。而在硬币的另一面你会发现：大家彼此都很友善，沟通的节奏很频繁，在会议上也能得出有效结论。在完成工作后，对方还会感谢你的付出。
这两种文化氛围，我的朋友都呆过。第一种人员流失严重，变动巨大，但那几个把持领导位置的leader却稳坐钓鱼台。第二种，即使团队做出了广受世界范围喜欢的产品，大家仍然保持谦逊，保持尊重和信任。一开始，我以为是因为第一种的考核方式有问题。它们会在每月进行绩效考评，需要数字来说明你的贡献。在这个过程中出现了很多“虚假”数字。对业务毫无帮助却能分到大额奖金。后来我发现，自己其实只看到了表面。真正驱动它们考核差异的点在于，背后的团队文化。
在第二家公司里，大家提倡的是有话直说，以理服人的文化。同时，由于扁平化的架构设计，没有来自title的直接压力，大家能就事论事，进行充分的讨论，以事实为依据，推动事情发展。
出色团队文化的三大要素
从上面的两个场景，我们能够提炼出出色团队氛围的三大特点：谦虚、尊重和信任。谦虚是放下自负，用平等的态度去对话，而不是论资排辈。尊重则在于，尊重对方作为独立个体的能动性。无论他是你的下属，还是对接部门的一线同学。提出建设性的批评，而不是人身攻击。信任彼此，不会为了不出错，而进行防守。相反，鼓励从错误中学习：学到了什么，下次将怎么样去改进。
小结
社交不是勾心斗角或操纵他人，核心在于相互借力成就事业。保持一定的空闲思考时间，开放倾听，将会是一种好的开始。
这部分只是个总起，后续将针对工程师与团队展开讲讲。主要包括如何打造好的团队文化，如何区分管理与领导，如何驱逐害群之马，如何应对不同类型的组织（向上管理）。
喜欢的朋友记得点个赞，明天同一时间不见不散。
