《极客与团队》是一本由[美]Brian W. Fitzpatrick/Ben Coll著作，人民邮电出版社出版的176图书，本书定价：29.00元，页数：2012-3，特精心从网络上整理的一些读者的读后感，希望对大家能有帮助。

　　《极客与团队》读后感(一)：技术之外

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

　　----

　　在我组织团队新兵训练营（入职之后一段时间内容集中的培训）时候，

　　经常和新同事聊到一个词：软实力。

　　我将其描述为专业技能之外的能力。每个人都这种能力的解读可能会不一样，

　　我将其拆解为：「对工作的热情；观察力和反思能力；做计划和决策是否周全」。

　　这种拆解是不全面的，「多年」以后，我意识到，硬实力考衡的是专业的能力，

　　而软实力则是考衡人的因素。这种晚来的意识让我在一段时间里面，

　　将自己的工作陷入困境，并且得不到解药。

　　Google 的两位工程师 Brian W. Fitzpatrick 和 Ben Collins-Sussman

　　告诉大家想要在团队中获得成功的另一面。不要被书名误解，我觉得「开发者和团队」是更好的名字，

　　虽然没那么酷。

　　lt;!-- more -->

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

　　要做的第一件事情，应该就是沟通了。让自己成为一个玻璃玲珑人，

　　其他人可以看到你的方向、目标和里程碑，同时可以看到你的进展和问题点。

　　这样不但可以获得工作中的肯定，当个人的目标设定和团队出现偏差，

　　又或是开发过程中在一个点停顿了太久，可以有其他人参与进来或直接伸出援手。

　　这种透明度对上对下都应该如此。团队的领导，

　　应当在开发周期内的早期就明确告知团队愿景、目标和设定的里程碑。

　　产生共鸣的愿景可以让人对目标有渴望，对自己工作有认同。

　　各位还记得中国中小学开学第一周里，大多都有一个开学典礼讲话。讲的好的领导，

　　会阐述自己的教学理念，去年取得的成绩，今年的教学着重点。

　　讲的差的领导就是泛泛而谈，每年都是一套话术，完全看不到长进。

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

　　一个人牛逼没屁用。

　　提高工程质量的一个有效手段就是 CI（持续集成），将开发过程中一点点的小进展都以一种机械的方式呈现出来，

　　并进行测试。另一个有效手段是 Code Review，不但推荐要 CR，更是要尽早、快速的 CR。

　　避免屎积压多了拉，太臭。

　　我突然想到一条实践：即便是做一个人的项目，在精简程度上也保持最小的一个阈值，

　　想象明天就要长假，工作要交给别人维护，如何在交付物里面有足够的信息让其他人知晓细节。

　　而不是丢给后继维护者一句冰冷的话：「看代码」。

　　沟通必须是有效的，我想任何人都不想听一个嘴碎的人在那边逼逼一下午。

　　有很多结构化、一部的沟通可以显著提高沟通效率：

　　项目看板、设计文档、Code Review、代码注释、数据字典等。

　　第二个重要的观点是，接受失败，承认自己不是无能的。你可能很聪明，但所做的事情不一定完全都是正确的，

　　连上帝都会犯错，何况是普通人。犯错不可怕，但是犯错还认识不到可怕。犯错并且认识到了，

　　但是拒绝承认错误的人，不是可怕，而是应该要被淘汰，这类人会极其难以合作。

　　如何你周围都是这样的人，或者你上司是这样的人，也许你可以考虑换一个地方，在拉钩搜索「堆糖」试试吧。

　　关于接受失败的另外一个隐含后续发展就是「成长」。意识到这个世界是动态发展的，

　　「要以发展的眼光看待事物」是一个非常非常有用的认知。

　　能自己意识到失败，并且会主动复盘，重新认知自己的人，往往会成长的极为迅速。

　　关于成长的话题可以讨论很深，以后可以单独拎出来讨论。

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

　　gt; 1. 简要

　　gt; 2. 时间的时间线，从发现到调查，再到最终见过

　　gt; 3. 事件发生的主因

　　gt; 4. 影响和损失评估

　　gt; 5. 立即修正问题的步骤

　　gt; 6. 防止事件再次发生的步骤

　　gt; 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），

　　前者更着重技术，后者不但关心技术，还关心手下工程师的成长。

　　用国内互联网的职责分工描述，大概就是有技术专家和团队负责人的区别。

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

　　gt; 1. 放下自负

　　gt; 2. 做一个禅师（保持冷静和理性）

　　gt; 3. 成为催化剂

　　gt; 4. 当一个导师

　　gt; 5. 设置明确的目标

　　gt; 6. 坦诚（三明治赞美法）

　　gt; 7. 记录快乐程度

　　最后聊一下对书本身的评价。黄易山在 Quora 写过一段非常有名的

　　[为什么工程师管理这么难？](https://www.quora.com/What-makes-engineering-management-hard)。

　　这本书讨论的内容要比黄易山那篇回答范围更大，讲述的也更详细（废话，这是书）。

　　作者是典型的工程师，书目结构易读，第五章从反模式来思考问题非常赞。

　　而这本书不但通俗异动，也添加了非常具有可操作性的最佳实践。

　　从创造力驱动的角度出发，技术开发者都是管理者。因为他们需要设计方案，创造价值，而不是重复劳动，

　　所以我推荐每个开发者阅读。

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

　　----

　　开给自己的处方：

　　* 上面提到的最佳实践

　　* 谦逊：谦逊一些，低调一些，向他人学习

　　* 坚毅：认准目标，稳步前行，不放弃

　　* 信心：信念也许可以重建，但是对自己始终保有信心，也许会错，但是要相信自己的判断

　　* 开会技巧：超过 5 人的会用单向宣讲更有效

　　----

　　《极客与团队》读后感(二)：说出了我一直在做但是总结不出来的东西

　　“本书是写给程序员看的，一本教你怎么交朋友、怎么影响他人的书。书中充满了操作性极强的建议和意见，让你在技术团队中过得更开心，变得更有效率，更加如鱼得水。”

　　—艾德利安·霍罗瓦第，Django创始人之一

　　“作者说出了我一直在做但是总结不出来的东西。”

　　—吉多·范·罗苏姆，Python之父

　　“请把本书送至：

　　保罗-海宁·坎普

　　FreeBSD核心团队

　　必须在1994年3月之前送达。”

　　—保罗-海宁·坎普，FreeBSD项目程序员

　　“作者无意为孤独的程序员唱赞歌，相反他们决心要亲手埋葬这个传说。他们撰写了一系列文章来指导那些靠谱的程序员如何对付他们这辈子最复杂的难题：怎么处理好和团队的关系。本书说明了为什么最有人情味的软件往往都是最会合作的人创造出来的，而且它还教你如何同时做到这两点。”

　　—约翰·托尔瓦，芝加哥市政府CTO

　　《极客与团队》读后感(三)：绝对是书中瑰宝

　　“这是一本有关软件开发社会学的出色著作，它同时照顾到了开源项目和大公司的需求。对所有新踏入职场的工程师来说，有关管理和应对办公室政治的那个部分绝对是必读的。我的建议是不管你是什么背景的工程师都应该读一读这一章！这是我见过的第一本写给工程师看的、专门有讲到办公室政治的读物，而且可读性非常强。在‘怎么和难以相处的人一起工作’里分享的奇闻异事和实用小贴士都是金玉良言！千金难买哦。”

　　—蓝俊彪，ArEngineeg’s Guide to Silicon Vauer Startups和Startup Engineering Managerrerg作者

　　“本书绝对是书中瑰宝，作者分享的理念能让程序员们更好地为团队作出贡献。我们终于有幸可以开诚布公地探讨这个领域的话题，而且还是以这么平和幽默的方式。要是在21岁的时候有这样一本书让我研读领会就好了。”

　　—布莱恩·奥沙利文，Facebook

　　《极客与团队》读后感(四)：程序员们，好好学吧

　　“你可能已经听过所谓的‘十倍程序员’传说了吧，它的意思是顶尖程序员的生产力比普通程序员要高一个数量级。但巨大的影响力不仅来自经验和技术，更少不了来自同事和用户的共鸣感，而且无论多少聪明才智都弥补不了后者的缺失。好在这本书可以帮你磨练这项软技能，以期给世界留下更深的烙印。”

　　—鲍勃·李，Square支付CTO

　　“作者设定了一个基本的信条—谦虚、尊重和信任—并围绕它们提供了大量的情景案例。这些宝贵的经验和智慧能够帮助绝大多数需要团队合作的工程师（也就是我们）变得更有效率。”

　　—格雷格·巴罗斯，Facebook产品工程部副总裁

　　“软件是由人创造出来的。只要能运用本书中所列出的准则，这样的团队无论是在思路、代码品质上，还是在产品发布方面，都可以完胜任何单打独斗的黑客。程序员们，好好学吧！”

　　—乔纳森·南丁格尔，Mozilla Firefox工程部高级主管

　　《极客与团队》读后感(五)：《极客与团队》读书笔记

　　写于 2017-02-18 。

　　两位作者 Brian W. Fitzpatrick 和 Ben Collins-Sussman 都有在开源项目（Subversion）和大公司（Google）管理工程团队的经验。

　　作者们认为，优秀的工程师文化的核心是 HRT：谦虚（Humility），尊重（Respect）和信任（Trust）。整本书就是对 HRT 的阐释、示例和应用建议。同时还夹杂着创建维护优秀工程师文化的各种经验和技巧。

　　# 主要内容

　　### 优秀的个人依托于优秀的团队

　　现代社会大部分的工作对于单独个体来说已经太过复杂，要把事情做成功，只能依靠协作。应该正确认识社交的意义：“ 社交……是通过建立起人与人之间的关系来把事情做成功，而且这种关系延续的时间肯定比项目本身更长。”

　　团队文化的定义和维护是每个成员的事，而不仅仅是创始人和负责人的事。关于这一点，拉兹洛·博克在《重新定义团队：谷歌如何工作》中也有类似的观点。他认为“任何人都有能力成为一名创始人，也可以成为所在团队的文化创造者”。

　　### 优秀 Leader 的素质

　　Leader 应该关心做什么而非怎么做，相信团队能自己找的解决问题的方法。设置明确的目标，也是让团队齐心协力的有效方法。最好的激励方式，就是项目对每个成员来说都能够成为内部激励。对于工程师来说，只需提供三样东西：自主、精通和目标。

　　提问是提供帮助有效形式。Leader 的眼光应该放长。不应只关心这一个问题的解决，而是要帮助成员成长。通过提问的方式一步步引导，让成员依靠自己的力量找到答案，是对他们技术、主人翁意识和责任感的培养。

　　允许失败。因为 即使失败了，相比于只尝试那些你知道自己肯定能完成，你所得到的会多得多。

　　坦诚。如果有什么不知道，那就明确地表示不知道。如果有什么事情不能说，就明确地表示不能说。

　　### 对事不对人

　　好的团队文化，能不断吸收有益的元素，同时也能保护成员不受偏激和恶意行为的影响。注意要对事不对人，带来负面影响的是行为，而非个人。为一个人定性是很幼稚的想法。需要从团队中剔除和改造的是行为和想法，而非一个个的成员。

　　### 在大组织中发展的一些技巧

　　对不确定的事情提出疑问，不要害怕和上级争论，但一定就事论事。

　　在经理问你进展之前，就主动汇报自己在干什么。

　　不管技术债务有多少，永远不应该花超过三分之一的时间做防御性的工作，因为这些工作产生不了“看得见”的结果，否则就等于政治自杀。

　　沟通的指导原则就是在同步沟通的时候（比如开会），人越少越好。而在异步沟通的时候（比如 Email），涉及的听众越多越好。

　　内部沟通强烈推荐采用群聊的方式，这样大家的发言都是当着团队所有人的面。一方面每个人说话前会更慎重，一方面也方便其他人以自己喜欢的方式获取信息。

　　不在源代码中署名，因为很多人只能接触到一小块代码，署名会让大家在修改代码时产生更多顾虑。

　　# 我的看法

　　HRT 的着眼点是每个人应该怎么样，而不是团队应该怎么样，所以这些原则适用于任何团队。

　　**谦虚**

　　年纪越大，就越知道自己的局限。知识越丰富，越知道自己的无知。绝大部分时候，我们的想法和行为只是历史洪流中微小的一部分。对自己和对外界的看法，依赖于我们的认知地层，后者又依赖于学识和阅历。回顾过去，当时认为重要的东西，现在看来价值有限。曾经自认为的独一无二的想法，原来只是千万个类似想法中的一个。

　　**尊重**

　　“出身”很重要。一个人的发展，很难超越自己的出身太多。总要付出一整个青春的努力，才能进入更高一点的阶层。位于阶层顶部的人，往往是经过了几代人的奋斗，一点一点积累而来。我们的优秀，建立在先辈们的优秀之上。所以和别人比没有意义，起点不同。要和自己比，和先辈们比，看有没有通过努力让自己站得更高，走得更远。

　　一人一个活法。每个人有自己的世界观价值观，以自己的狭隘妄自评判别人的生活，是幼稚的。每个人至少能比别人更知道自己想要什么，想过什么样的生活。哪怕想法一样，同样的努力，最终结果也会大相径庭，各有各的难处。成熟的一个表现就是接受差异，尊重不同。

　　**信任**

　　人总有长处和短处，哪怕都是长处，时间精力也不能让我们事必躬亲。科学技术的发展，每一件事背后的复杂性大大增加，要做成一件事，越来越依靠协作。组织制度健全程度的一个评判方法，就是你对陌生人有多信任。公司内部也是如此，如果别人辜负了你的信任，最终给对方带来的损失比你自己的更大。

　　《极客与团队》读后感(六)：项目经理和技术领导的必读书目

　　“这本书为建立健康的软件开发文化提供了基本的蓝图。它应该成为项目经理和技术领导的必读书目，甚至那些想要了解团队动力学是如何留住顶级人才以及影响软件质量的非技术主管也不应该错过本书。”

　　—布鲁斯·约翰逊，Google工程主管

　　“编程技术能让你混口饭吃，但要是能把它和与人合作的能力结合起来，你就可以改变世界。这本书教你的并不仅仅是当一个更好的程序员，它还要你当个了不起的程序员。”

　　—克雷·约翰逊，The Information Diet作者

　　“本书就如何构建成功团队和产品的话题进行了极富洞察力的探索，探讨的是多年来我们程序员在职业生涯里都经历过的痛苦和挣扎。这种轻松愉快的办法不但能同时解决技术团队里的技术问题和人际关系问题，更以一种有趣的方式转化成文字，实在是所有程序员书架上必不可少的书目。”

　　—乔纳森·勒布朗，X.Commerce首席工程师

　　《极客与团队》读后感(七)：作者所有演讲里的精华

　　“编程现在涉及的已经不仅仅是代码和机器了，它更像是把已有的组件按照新的方式拼装在一起—而这些组件背后的作者都是活生生的人。本书的作者对此了然于胸，无论给出什么样的建议，他们要传达的信息都是非常简单直观的：只要像在代码上那样在人际关系上狠下功夫，你不但可以变成更快乐的程序员，更可以让其他程序员也变得快乐起来。这本书来的正是时候！”

　　—傅凯，Open Tech Strategies LLC联合创始人

　　“很少有人会谈及和极客合作时该怎么处理好人际关系这方面的东西，所以多年来我一直通过博客记录本和傅攀勃在各种大会上的演讲。现在我很高兴能方便地在一本书里就读到他们所有演讲里的精华，而不用再追着他们满世界跑了。”

　　—罗伯特·凯，MusicBrainz首席极客

　　《极客与团队》读后感(八)：老外也有办公室政治的

　　其实这本书给自己的收获并不多，原因有二：一是自己看了不少介绍软件工程师团队如何工作的书；二是自己在工作中也在不断思考如何才能更有效率地工作，更好地与同事和领导相处；因此，这本书中介绍的内容对于自己来说没有太多的新意。

　　新意没有太多，但是倒是有一二处启发。

　　一，我对团队文化有了更深一步的认识。书中第31页提到：“每当有新人加入时，她并不是只从团队负责人那里了解团队文化，而是从一起工作的每个成员身上学习。例如，你在仔细检查新同事的代码的时候，会向她解释为什么你的团队是按照某种方式写代码的，这样她就很快明白团队重视的是代码的哪些部分。她还会同感观察团队的工作，交流，以及解决冲突的方式来学习团队文化 ”。自己的理解是：团队文化不是上嘴唇一碰下嘴唇就有的，她是在公司的各个角落，产生于面试的时候，产生于公司如何对待离职的员工，产生于同事之间的争论，她无时无刻不存在。行动是建立文化的唯一方法，而不是标语和演讲！

　　二，搞清楚哪些事情是不能做的，对于团队也是很重要的。我们常常在想自己能做什么，而忽略了自己不能做什么。其实搞清楚不自己能做什么，剩下的就是我们都能做的了。

　　三，面对用户数量上升的时候，不是提供更复杂的功能，而是应该提供更简介的界面、更友好的交互。因为“当用户的数量上升时，他们的平均技术水平会递减，因为有越来越多的普通大众变成了你的用户。如果此时增加产品的复杂度，用户失望的程度会直线上升”。

　　四，老外那里也有办公室政治啊，而且一点也不必国内的差！但是，不管你接受不接受，它都在那里，自己要做的就是尽可能地保护自己不受其伤害。就像作者说的，也许你对目前的处境非常满意，但是获得更高职位会让自己在灾难来临的时候有更大的机会全身而退。

　　备注：人们的认识都是有局限性的，因为人们总是根据自己身边发生的事情去下结论，妄图进而将其推广到所有人那里。但是人们自己经历的事情总是有限的，事情的发生也都有“上下文”的，因此，根据这些事情得出来的结论也会带有一定的局限性。譬如，作者是根据自己在Google的工作经历以及自己的朋友的工作经历写出了这本书，那么，这本书应该比较适合类似Google文化的公司或团队，至于自己目前所在的团队嘛，只有试过才知道行不行啦！

　　《极客与团队》读后感(九)：精彩至极，直指人心

　　“精彩至极，直指人心！哪怕你不觉得自己是极客，它提供的建议也值得一读。”

　　—文顿·瑟夫，Google首席互联网专家

　　“我和工程师已经打了三十几年交道了。经验告诉我，人际关系在工作中的重要性并不亚于科学技术，但很多工程师都不愿意尝试了解如何与人合作。如果你想要更有效地进行创新，那绝不能错过本书。”

　　—狄恩·卡门，DEKA研发公司创始人

　　“作者为软件开发团队搜集了一套令人惊艳的模式和反模式。无论你是开发人员本身还是经理，或是任何有一点关系的人，只要你觉得自己难以理解为什么这些东西能让团队更有活力，你就应该读一读这本书。它道出了很多出色的开源项目程序员与生俱来的特质。我当初要是有这么一本书就好了。”

　　—布莱恩·贝伦多夫，世界经济论坛CTO

　　《极客与团队》读后感(十)：我打算让Samba团队人手一本

　　“软件开发是一项团队运动。如果你想要扬名立万，市面上有无数本教你如何磨练技术水平的好书，教你当好经理的书也不少。但这本书却另辟蹊径，教你应该如何与团队合作，以及如何当好合作伙伴。这个领域早就需要这样一本书了。”

　　—彼得·诺维格，Google研发主管

　　“如果你想要组建一支能专注开发优秀软件的团队，那绝不可错过本书。作者将谦虚、尊重和信任等感性的话题漂亮地转变成极富技巧的建议，哪怕是最挑剔的工程师也会欣然接受的。”

　　—埃里克·伦特，BrightTag 联合创始人兼CTO

　　“这本书太精彩了。它探讨的是计算机编程里最难的问题，怎样和其他程序员打交道。我打算让Samba团队人手一本。”

　　—杰瑞米·埃里森，Samba作者之一