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


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

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

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

s26354473.jpg

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. 放下自负
  2. 做一个禅师(保持冷静和理性)
  3. 成为催化剂
  4. 当一个导师
  5. 设置明确的目标
  6. 坦诚(三明治赞美法)
  7. 记录快乐程度

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

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

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


开给自己的处方:

  • 上面提到的最佳实践
  • 谦逊:谦逊一些,低调一些,向他人学习
  • 坚毅:认准目标,稳步前行,不放弃
  • 信心:信念也许可以重建,但是对自己始终保有信心,也许会错,但是要相信自己的判断
  • 开会技巧:超过 5 人的会用单向宣讲更有效

原文链接: https://blog.alswl.com/2016/02/team-geek/
3a1ff193cee606bd1e2ea554a16353ee
欢迎关注我的微信公众号:窥豹

Comments

comments powered by Disqus