《极客与团队》这本书是在看《技术管理猪鸡-1 开篇》注意到的：

Google 的芝加哥 office 有两个技术领导：Brian Fitzpatrick 和 Ben Collins-Sussman。他们合写了一本书，叫做 Team Geek。

这本书的副标题是“软件工程师的团队生存秘笈”，毕业一年认识到和同事合作、如何更高效的推进工作也十分重要，正如作者在书一开始提到了书的宗旨：

本书旨在帮助程序员改进理解他人、与人沟通，以及与人合作的能力，进而使其在编写软件的过程中变的更有效率。

这本书的核心是“HRT”，即“谦虚”，“尊重”，“信任”，不算是什么秘诀，但却非常难做到，一遍读，一遍想着工作中的一幕幕，感慨良多，希望能在阅读完这本书之后，在下一份工作中有更好的表现吧。
把书中的内容要点，以及一些随想简单的记录如下，方便日后查阅。

注重团队合作和分享

公开透明和信任可以极大的降低成本，以及强化公车因子。

公车因子：：一个项目里，需要有多少个人被公交车撞到才能令其完全瘫痪。

扩大“公车因子”，避免出现领地感。

分享协作，然后有良好的文档积累，可以让单个人免于四处救火，想起了《凤凰项目》里的超级员工“布伦特”。另外团队合作带来的荣誉感和激励作用也非常大，过去一年的工作所在的团队并没有让我有这种感觉。

三支柱（HRT）：谦虚，尊重，信任

谦虚

没有人是宇宙中心。谁也不是万能的，谁都会犯错。你必须不断地提高自己。

尊重

你必须真心实意地关心同事。他们都是活生生的人，他们的能力和成绩都需要得到肯定。

信任

要相信别人的能力和判断力，在适当的时候懂得放权。

HRT 实战

• 放下自负
• 学会批评和接受批评
  • “别把你的自尊和你的代码等同起来”
• 快速失败；学习；迭代
  • “失败是可以接受的”
  • “不要等到完美的时候再出来”
  • “真正的检讨应该包含有关学到了什么，以及怎么改正等经验教训的详细注解”，为了方便以后查看，和总结积累经验。
• 为学习预留时间
• 学习保持耐心
• 对影响保持开放的态度
  • “你越是容易受影响，你就越能影响别人；你越是示弱，你就越强壮”
  • “同事是合作者，不是竞争者”

团队文化

作者在这里说的文化，其实更像一种团队氛围，以及团队内形成的默契，而不是阿里那种强价值观的文化。好的文化可以薰陶新人，让团队健康的运作，最终的目的都是带来更高效的产出。

“如果你想要优秀的工程师为自己的团队工作，首先的就是雇佣出色的工程师”，优秀的人总是倾向于和优秀的人一起工作，能够保持更好的节奏，也更好沟通，也常常见到劣币驱逐良币的情况。

优秀的人，大多数都很有主见和想法，可以说是比较难“管理”，一群平庸、溷日子的人好管理，但是毫无战斗力。“基于共识决策的团队”，是让团队成员都有主人翁精神和责任感，这个时候，好的TeamLeader不会担心自己的地位受到威胁，而应该注重团结，和倾听意见。

对付害群之马

这是第四章的内容，但是作者在团队文化这章提到了，就给总结到一起了。

要剔走的是行为本身，而不是人。

害群之马：

• 不尊重别人的时间
• 自负
• 过分索求
• 幼稚或者莫名其妙的偏执妄想
• 完美主义

一些解决方法：

• 转移完美主义者的注意力
• 别去搭理挑衅的家伙，无视是最好的办法
• 别太感情用事
• 抓住重点处理问题
• 对付挑衅要不卑不亢
• 知道什么应该放弃
• 关注长远

这一部分还是需要看书中的详细解释才好回顾，只看这些有些宽泛。

沟通

“沟通的指导原则之一就是在同步沟通的时候（比如开会），人越少越好。而在异步沟通的时候（比如E-mail），涉及的听众越多越好。”
更重要的是，你必须确保文档里的信息要尽可能地让所有人都看到。

想起之前一份工作，公司强烈依赖IM 工具，不胜其扰。而且某些领导一点小事就喜欢开个会，“聊一下”，然后一部分人放下手头工作去了之后，只是站了几十分钟，回来还得拿起刚刚放下的事情，非常要命。

高层面同步

制定任务宗旨，准确定义产品的方向和范围，这样大家知道努力方向，同时出现分歧的时候，结果能够更好的达成一致。

开会要有效率,开会的五条小贴士

• 只邀请一定要参加的人
• 开会前要决定好议程，而且要事先通知所有人
• 达成目的后应该提早散会
• 注意别跑题
• 镜像币会议安排在休息时间前后（比如午饭时间，下班前等）。

远程团队要多沟通，同时也要勇于见面

注重文档的编写和积累

---

日常沟通

• 邮件列表
• 在线聊天
  • 尽量群聊
  • 聊天记录可检索

使用Bug 跟踪系统

代码注释

“注释应该尽量解释为什么代码要那么写，而不是去解释代码做了什么”，“注释不应该涉及过多细节”，“过犹不及”。

代码署名

作者不建议在代码中进行署名，更好的方式应该是通过版本控制工具，在里面进行跟踪，例如git。
之前工作中，需要写很多监控脚本，为了以后找到对应的负责人，会在脚本开头署名，不过如果当初大家通过git 协作的话，就没这个必要了。

代码审查

“代码改动应该尽量短小以保证审查的质量。”

测试和发布

测试和发布流程应该尽可能的自动化，测试自动化程度越高，“在修复bug 和添加新特性的时候就越自信”，也容易更早得发现问题。发布流程越自动，越流畅快速，可以让产品迭代得越快。

团队主管

“传统型经理关心的是怎么完成任务，而主管只关心完成了什么任。。。。（并且相信团队能自己想出解决方法）。”，主管只需要负责设定大方向，这也是“信任”的一种表现。

仆人式领导

“仆人式领导要为团队填补前进道路上的裂缝，并在必要的时候给予建议，同时还要勇于冲到第一线。仆人式领导唯一要做的管理工程师就是对团队的技术和人事健康情况负责。”

反模式

• 雇佣听话的人
• 无视表现不佳的人
• 无视人际关系
• 和谁都是朋友
• 降低招聘标准
• 把团队当小孩子

领袖的处事之道

• 放下自负
  • “如果你能鼓励这种提问，你才能有更多的机会听到谏言，这能让你成为一个更好的领袖，团队也会变得更加成功”
• 做一个禅师
• 保持澹定和冷静
• “工程师来问你建议通常是不是你去解决他的问题，而是要你帮助他解决问题，所以最简单的方法应该是问问题”，“正确的做法是在HRT 的原则下，帮助他解决分析问题，从而达到让他自己解决问题的目的”，“这通常能引导工程师得出答桉，最重要的是，这是他自己想出来的答桉，因为也就回到了本章开头所讲的主人翁精神和责任感。”
• 成为催化剂
• 引导大家达成共识
• 给予团队安全感
• “在遭受失败的时候指责个人则不利团队，而且会从根本上阻碍承担风险的意愿”，“个人的成功可以在众人面前表彰，但个人的失败最好还是私下检讨”，“需要公开批评某一个人的情况几乎是不存在的，绝大多数时候这样做都是很过分，很残忍的。团队里的其他人肯定早就知道这个人把事情办砸了，所以完全没必要重复讲。”，应该抓住机会帮助团队从失败从成长起来。
• 当一个导师
• 三个条件：
  • 熟悉团队的流程和系统
  • 向他人解释事物的能力
  • 估计被知道的人到底需要多少帮助的能力
• 设置明确的目标
• 坦诚
  • 警惕三明治赞美法，即先赞美，再批评，再赞美。
• 记录团队的快乐程度
  • 建立信任，建议一对一会议结束的时候问“你还有什么要求吗”，考虑团队成员的诉求。
  • “绝对不要以为人人都是工作狂----对别人在工作上能投入的时间不要有不切实际的期望。否则很容易失去别人对你的尊敬，甚至彻底绝望。”
• 不必事事躬亲，但也不能当甩手掌柜
• 寻找接班人
• 知道什么时候要做恶人
  • 不符合团队要求的人，拖的越久，对团队伤害越大
• 保护团队不受溷乱干扰
• 帮团队遮风挡雨
  • “在条件允许的情况下，应该尽可能的和团队分享信息，但是也不要把那些不太可能会直接影响到他们的事情告诉他们，这种组织性的溷乱只会让他们分析”
• 告诉团队他们干得很好

激励

• 给工程师一个目标；
• 让工程师有机会学习新技术和提高技术。

操作组织的艺术

这一章作者列了一些工程师遇到具体问题该如何处理，节选几句印象深刻的话。

“要尽可能确保你的经理以及团队之外的人不但知道你在干嘛，还要知道你干的很棒”

“在做承诺的时候要谨慎，而干工作的时候要尽最大努力”

“不管技术债务有多少，团队也永远不应该花超过三分之一甚至一半的时间和精力去做防御性的工作，否则就等于政治自杀”

写邮件求助要采用“三个论点和一个行动”，绝对不能有其他内容，让他人能在10秒内读完。

和用户的关系

软件要服务的是用户，最后一章列了一些例如“要多沟通”，“注意第一印象”，“关注用户”，虽然都很有道理，比较杂乱，是一些经验之谈，读完就要用起来非常难。

整本书的内容都是围绕HRT，不过人和人之间，总是能和HRT 扯上关系。 每章的独立性其实不是很强，作者在讲很多论点的时候，会穿插其他内容。总之，看完也很难记住，只能记住HRT，好好工作，多实践。