转载

技术之外

这是一天一本书的第二次执行，这次选了一本比较薄的书，上周的书看了一天，脑仁疼。

在我组织团队新兵训练营（入职之后一段时间内容集中的培训）时候，经常和新同事聊到一个词：软实力。我将其描述为专业技能之外的能力。每个人都这种能力的解读可能会不一样，我将其拆解为：「对工作的热情；观察力和反思能力；做计划和决策是否周全」。

这种拆解是不全面的，「多年」以后，我意识到，硬实力考衡的是专业的能力，而软实力则是考衡人的因素。这种晚来的意识让我在一段时间里面，将自己的工作陷入困境，并且得不到解药。

Google 的两位工程师 Brian W. Fitzpatrick 和 Ben Collins-Sussman 写了一本书极客与团队，通过他们的视角，告诉大家想要在团队中获得成功的另一面。不要被书名误解，我觉得「开发者和团队」是更好的名字，虽然没那么酷。

技术之外

要在团队中获得成功，你必须以谦虚、尊重和信任为核心原则。

要做的第一件事情，应该就是沟通了。让自己成为一个玻璃玲珑人，其他人可以看到你的方向、目标和里程碑，同时可以看到你的进展和问题点。这样不但可以获得工作中的肯定，当个人的目标设定和团队出现偏差，又或是开发过程中在一个点停顿了太久，可以有其他人参与进来或直接伸出援手。

这种透明度对上对下都应该如此。团队的领导，应当在开发周期内的早期就明确告知团队愿景、目标和设定的里程碑。产生共鸣的愿景可以让人对目标有渴望，对自己工作有认同。各位还记得中国中小学开学第一周里，大多都有一个开学典礼讲话。讲的好的领导，会阐述自己的教学理念，去年取得的成绩，今年的教学着重点。讲的差的领导就是泛泛而谈，每年都是一套话术，完全看不到长进。

缺失沟通，还会将个人陷于单打独斗的境地，一个篮球队需要 5 个人大，一个人牛逼没屁用。

提高工程质量的一个有效手段就是 CI（持续集成），将开发过程中一点点的小进展都以一种机械的方式呈现出来，并进行测试。另一个有效手段是 Code Review，不但推荐要 CR，更是要尽早、快速的 CR。避免屎积压多了拉，太臭。

我突然想到一条实践：即便是做一个人的项目，在精简程度上也保持最小的一个阈值，想象明天就要长假，工作要交给别人维护，如何在交付物里面有足够的信息让其他人知晓细节。而不是丢给后继维护者一句冰冷的话：「看代码」。

沟通必须是有效的，我想任何人都不想听一个嘴碎的人在那边逼逼一下午。有很多结构化、一部的沟通可以显著提高沟通效率：项目看板、设计文档、Code Review、代码注释、数据字典等。

第二个重要的观点是，接受失败，承认自己不是无能的。你可能很聪明，但所做的事情不一定完全都是正确的，连上帝都会犯错，何况是普通人。犯错不可怕，但是犯错还认识不到可怕。犯错并且认识到了，但是拒绝承认错误的人，不是可怕，而是应该要被淘汰，这类人会极其难以合作。如何你周围都是这样的人，或者你上司是这样的人，也许你可以考虑换一个地方，在拉钩搜索「堆糖」试试吧。

关于接受失败的另外一个隐含后续发展就是「成长」。意识到这个世界是动态发展的，「要以发展的眼光看待事物」是一个非常非常有用的认知。能自己意识到失败，并且会主动复盘，重新认知自己的人，往往会成长的极为迅速。关于成长的话题可以讨论很深，以后可以单独拎出来讨论。

书中提到一个失败后回顾的清单：

简要
时间的时间线，从发现到调查，再到最终见过
事件发生的主因
影响和损失评估
立即修正问题的步骤
防止事件再次发生的步骤
得到的教训

我就哈哈哈了，这不就是我大堆糖的故障报告模板么？

第三点，如何成长？简单来说，去冒险，去承担自己能力之外的任务，去挑战没有经历过的任务。有一条彼得定律：「在组织或企业的等级制度中，人会因其某种特质或特殊技能，令他在被擢升到不能胜任的职位，相反变成组织的障碍物（冗员）及负资产。」。前半段含义是，大部分情况下面，并不是具有了相应能力才去承担，而是试着去承担任务。无论成功与否，对当前去挑战的人来说，都能够得到历练，从而能力得到提升。

第四点是：成为 Leader，而不是 Manager。一个团队是一艘危机四伏的海面上一只船，如果没有一个船长，那么就前途叵测。在职业生涯的某些阶段，你可能自然成为船长，也许是一个项目的船长，也许是一个小 Team 的船长。那么切记，船长是 Leader，而不是 Manager，是能力综合，可守可攻，顺风时候会把舵，缺人时候可以顶任何岗位的船长。而不是手持大鞭的 Manager。我觉得新闻联播里面描述的人民公仆，就是一个很好的 Leader。

一年多前之前和铁柱聊过，一个 Leader 是否需要要以能力服众。我仍然保持当初的观点：「是的」。在目标管理、方向把握上面，强大的技术背景可以有魄力的开展工作，挖掘新技术，推动变化。在遇到困难时候，可以决策、解决问题。这是由这个行业特质决定的，互联网是依赖创造力的脑力劳动，而不是根据人数线性增加产出的体力劳动。

但毕竟不是每个人都一定拥有 Leader 特质，难道就要一辈子做技术得不到上升？ Google 的一种做法，可以很好解决这个问题。分离 TL（techlead）和 TLM（techleadmanager），前者更着重技术，后者不但关心技术，还关心手下工程师的成长。用国内互联网的职责分工描述，大概就是有技术专家和团队负责人的区别。

关于这条，书中的几点最佳实践非常棒：

放下自负
做一个禅师（保持冷静和理性）
成为催化剂
当一个导师
设置明确的目标
坦诚（三明治赞美法）
记录快乐程度

最后聊一下对书本身的评价。黄易山在 Quora 写过一段非常有名的为什么工程师管理这么难？。这本书讨论的内容要比黄易山那篇回答范围更大，讲述的也更详细（废话，这是书）。作者是典型的工程师，书目结构易读，第五章从反模式来思考问题非常赞。

我读过几本技术管理相关的书籍，印象深刻的有两本，一本是温伯格的成为技术领导者，另外一本是此书。温伯格的行文比较跳跃、比较抽象，不容易读。而这本书不但通俗异动，也添加了非常具有可操作性的最佳实践。从创造力驱动的角度出发，技术开发者都是管理者。因为他们需要设计方案，创造价值，而不是重复劳动，所以我推荐每个开发者阅读。

好了，学习够了充分的理论，下面就是做起来了，「知行合一」。

开给自己的处方：