技术之外
2016-02-29
这是一天一本书的第二次执行，这次选了一本比较薄的书，上周的书看了一天，脑仁疼。
----
在我组织团队新兵训练营（入职之后一段时间内容集中的培训）时候，
经常和新同事聊到一个词：软实力。
我将其描述为专业技能之外的能力。每个人都这种能力的解读可能会不一样，
我将其拆解为：「对工作的热情；观察力和反思能力；做计划和决策是否周全」。
这种拆解是不全面的，「多年」以后，我意识到，硬实力考衡的是专业的能力，
而软实力则是考衡人的因素。这种晚来的意识让我在一段时间里面，
将自己的工作陷入困境，并且得不到解药。
Google 的两位工程师 Brian W. Fitzpatrick 和 Ben Collins-Sussman
写了一本书[极客与团队](http://book.douban.com/subject/21372237/)，通过他们的视角，
告诉大家想要在团队中获得成功的另一面。不要被书名误解，我觉得「开发者和团队」是更好的名字，
虽然没那么酷。
<!-- more -->
> 要在团队中获得成功，你必须以**谦虚**、**尊重**和**信任**为核心原则。
要做的第一件事情，应该就是沟通了。让自己成为一个玻璃玲珑人，
其他人可以看到你的方向、目标和里程碑，同时可以看到你的进展和问题点。
这样不但可以获得工作中的肯定，当个人的目标设定和团队出现偏差，
又或是开发过程中在一个点停顿了太久，可以有其他人参与进来或直接伸出援手。
这种透明度对上对下都应该如此。团队的领导，
应当在开发周期内的早期就明确告知团队愿景、目标和设定的里程碑。
产生共鸣的愿景可以让人对目标有渴望，对自己工作有认同。
各位还记得中国中小学开学第一周里，大多都有一个开学典礼讲话。讲的好的领导，
会阐述自己的教学理念，去年取得的成绩，今年的教学着重点。
讲的差的领导就是泛泛而谈，每年都是一套话术，完全看不到长进。
缺失沟通，还会将个人陷于单打独斗的境地，一个篮球队需要 5 个人大，
一个人牛逼没屁用。
提高工程质量的一个有效手段就是 CI（持续集成），将开发过程中一点点的小进展都以一种机械的方式呈现出来，
并进行测试。另一个有效手段是 Code Review，不但推荐要 CR，更是要尽早、快速的 CR。
避免屎积压多了拉，太臭。
我突然想到一条实践：即便是做一个人的项目，在精简程度上也保持最小的一个阈值，
想象明天就要长假，工作要交给别人维护，如何在交付物里面有足够的信息让其他人知晓细节。
而不是丢给后继维护者一句冰冷的话：「看代码」。
沟通必须是有效的，我想任何人都不想听一个嘴碎的人在那边逼逼一下午。
有很多结构化、一部的沟通可以显著提高沟通效率：
项目看板、设计文档、Code Review、代码注释、数据字典等。
第二个重要的观点是，接受失败，承认自己不是无能的。你可能很聪明，但所做的事情不一定完全都是正确的，
连上帝都会犯错，何况是普通人。犯错不可怕，但是犯错还认识不到可怕。犯错并且认识到了，
但是拒绝承认错误的人，不是可怕，而是应该要被淘汰，这类人会极其难以合作。
如何你周围都是这样的人，或者你上司是这样的人，也许你可以考虑换一个地方，在拉钩搜索「堆糖」试试吧。
关于接受失败的另外一个隐含后续发展就是「成长」。意识到这个世界是动态发展的，
「要以发展的眼光看待事物」是一个非常非常有用的认知。
能自己意识到失败，并且会主动复盘，重新认知自己的人，往往会成长的极为迅速。
关于成长的话题可以讨论很深，以后可以单独拎出来讨论。
书中提到一个失败后回顾的清单：
> 1. 简要
> 2. 时间的时间线，从发现到调查，再到最终见过
> 3. 事件发生的主因
> 4. 影响和损失评估
> 5. 立即修正问题的步骤
> 6. 防止事件再次发生的步骤
> 7. 得到的教训
我就哈哈哈了，这不就是我大堆糖的故障报告模板么？
第三点，如何成长？简单来说，去冒险，去承担自己能力之外的任务，
去挑战没有经历过的任务。有一条[彼得定律](https://zh.wikipedia.org/wiki/%E5%BD%BC%E5%BE%97%E5%8E%9F%E7%90%86)：「在组织或企业的等级制度中，
人会因其某种特质或特殊技能，令他在被擢升到不能胜任的职位，相反变成组织的障碍物（冗员）及负资产。」。
前半段含义是，大部分情况下面，并不是具有了相应能力才去承担，而是试着去承担任务。
无论成功与否，对当前去挑战的人来说，都能够得到历练，从而能力得到提升。
第四点是：成为 Leader，而不是 Manager。
一个团队是一艘危机四伏的海面上一只船，如果没有一个船长，那么就前途叵测。
在职业生涯的某些阶段，你可能自然成为船长，也许是一个项目的船长，也许是一个小 Team 的船长。
那么切记，船长是 Leader，而不是 Manager，是能力综合，可守可攻，顺风时候会把舵，
缺人时候可以顶任何岗位的船长。而不是手持大鞭的 Manager。
我觉得新闻联播里面描述的人民公仆，就是一个很好的 Leader。
一年多前之前和铁柱聊过，一个 Leader 是否需要要以能力服众。
我仍然保持当初的观点：「是的」。在目标管理、方向把握上面，
强大的技术背景可以有魄力的开展工作，挖掘新技术，推动变化。
在遇到困难时候，可以决策、解决问题。
这是由这个行业特质决定的，互联网是依赖创造力的脑力劳动，而不是根据人数线性增加产出的体力劳动。
但毕竟不是每个人都一定拥有 Leader 特质，难道就要一辈子做技术得不到上升？
Google 的一种做法，可以很好解决这个问题。分离 TL（techlead）和 TLM（techleadmanager），
前者更着重技术，后者不但关心技术，还关心手下工程师的成长。
用国内互联网的职责分工描述，大概就是有技术专家和团队负责人的区别。
关于这条，书中的几点最佳实践非常棒：
> 1. 放下自负
> 2. 做一个禅师（保持冷静和理性）
> 3. 成为催化剂
> 4. 当一个导师
> 5. 设置明确的目标
> 6. 坦诚（三明治赞美法）
> 7. 记录快乐程度
最后聊一下对书本身的评价。黄易山在 Quora 写过一段非常有名的
[为什么工程师管理这么难？](https://www.quora.com/What-makes-engineering-management-hard)。
这本书讨论的内容要比黄易山那篇回答范围更大，讲述的也更详细（废话，这是书）。
作者是典型的工程师，书目结构易读，第五章从反模式来思考问题非常赞。
我读过几本技术管理相关的书籍，印象深刻的有两本，一本是温伯格的[成为技术领导者](http://book.douban.com/subject/1132623/)，另外一本是此书。温伯格的行文比较跳跃、比较抽象，不容易读。
而这本书不但通俗异动，也添加了非常具有可操作性的最佳实践。
从创造力驱动的角度出发，技术开发者都是管理者。因为他们需要设计方案，创造价值，而不是重复劳动，
所以我推荐每个开发者阅读。
好了，学习够了充分的理论，下面就是做起来了，「知行合一」。
----
开给自己的处方：
* 上面提到的最佳实践
* 谦逊：谦逊一些，低调一些，向他人学习
* 坚毅：认准目标，稳步前行，不放弃
* 信心：信念也许可以重建，但是对自己始终保有信心，也许会错，但是要相信自己的判断
* 开会技巧：超过 5 人的会用单向宣讲更有效
----
原文链接：http://blog.log4d.com/2016/02/team-geek/
查字典图书网
