这是一天一本书的第二次执行，这次选了一本比较薄的书，上周的书看了一天，脑仁疼。
在我组织团队新兵训练营（入职之后一段时间内容集中的培训）时候， 经常和新同事聊到一个词：软实力。 我将其描述为专业技能之外的能力。每个人都这种能力的解读可能会不一样， 我将其拆解为：「对工作的热情；观察力和反思能力；做计划和决策是否周全」。
这种拆解是不全面的，「多年」以后，我意识到，硬实力考衡的是专业的能力， 而软实力则是考衡人的因素。这种晚来的意识让我在一段时间里面， 将自己的工作陷入困境，并且得不到解药。
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 写过一段非常有名的 为什么工程师管理这么难？。 这本书讨论的内容要比黄易山那篇回答范围更大，讲述的也更详细（废话，这是书）。 作者是典型的工程师，书目结构易读，第五章从反模式来思考问题非常赞。
我读过几本技术管理相关的书籍，印象深刻的有两本，一本是温伯格的成为技术领导者，另外一本是此书。温伯格的行文比较跳跃、比较抽象，不容易读。 而这本书不但通俗异动，也添加了非常具有可操作性的最佳实践。 从创造力驱动的角度出发，技术开发者都是管理者。因为他们需要设计方案，创造价值，而不是重复劳动， 所以我推荐每个开发者阅读。
好了，学习够了充分的理论，下面就是做起来了，「知行合一」。
开给自己的处方：
- 上面提到的最佳实践
- 谦逊：谦逊一些，低调一些，向他人学习
- 坚毅：认准目标，稳步前行，不放弃
- 信心：信念也许可以重建，但是对自己始终保有信心，也许会错，但是要相信自己的判断
- 开会技巧：超过 5 人的会用单向宣讲更有效
原文链接: 技术之外 | Log4D
3a1ff193cee606bd1e2ea554a16353ee
欢迎关注我的微信公众号：窥豹
