本书是专门写给程序员看的团队管理书籍。比起其他管理书籍，这本书比较薄，才170多页。我没看此书此前，在自己项目管理中或多或少用了里面的一些理念，这本书很好的把精华写出来了。本书其实围绕如何维护一个健康有效率的社区，很多经验可以借鉴一下。
此书分为六章。第一章以天才程序员开头，毕竟天才极少，还是要靠团队完成任务。由此引出去全书的主题：HRT(hummer respect trust)，谦虚、尊重、信任。第二章培养团队文化，文化是啥？为什么要培养团队文化？以及一些好的方法。第三章把项目经理（主管）比作是大海航行的船长，”仆人式主管”，须为团队服务，然后还讲了领导的一些处世之道和激励。第四章将如何对付害群之马，保护团队。第五章如何管理团队组织。第六章程序员也要有服务用户意识，软件需要用户友好，需要包装和营销。
第一章 天才程序员的传说
帮我把代码藏起来
- 人的本性——没有人喜欢人批评，特别是未完成的工作。缺乏安全感，可能会隐藏更大的问题。
天才的传说
- 迈克尔·乔丹、莱纳斯·托瓦兹、比尔·盖茨。集体荣誉算在一个人身上。
- 我们需要榜样的激励。
隐瞒是有害的
- 闭门造车。
- 确保失败尽早发生，尽快发生，经常发生。尽早分享不仅仅可以防止一开始就步入歧途和检验创意。
- 公车因子，保证工作的可替代性。
- 足够多的眼睛可以确保你的项目保持正确的方向。
团队才是王道
- 软件开发是集体项目
三大支柱
- 谦虚、尊重、信任
HRT实战
放下自负
学会批评和接受批评。建设性批评，谦虚的把问题归到自己头上。别把你的自尊和你的代码等同起来
快速失败-学习-迭代
不要等到完美的时候才出来，只要产品大致可以，就立刻把他按照原样公布给大众。
事后检讨。”学到了什么”，”怎么改正”。
简要 时间线 主因 影响和损失评估 立即修改正问题的步骤 防止此事再次发生的步骤 得到的教训 为学习预留时间。人一旦攀至顶峰，往往就会停止学习。偶尔跳出舒适区，接受挑战。
学习保持耐性。
学会示弱。承认自己的无知
培养出色的团队
什么是文化
- 团队文化就像是一块含有酵母的面团：酵母(团队创始人)能将菌群培养物植入生面团(团队新人)，从而变成一块好吃的面包(团队)。
- 团队文化不仅仅包含编写代码的方式或者是成员之间的相处之道，它还包含所有人都认可的经验、价值观、目标。
为什么要关心它
- 接受有益改进，同时防御有害的激进变化的团队文化。
- 将大部分的时间放在开发优秀软件上面。
- 近朱者赤近墨者黑。自我选择。
- 招聘文化契合度高的人。
文化和人
- 让出色的工程师们放心地分享创意，并且在决策过程中拥有发言权。
- 基于共识决策的团队。”共识”是指每个人都对产品的成功抱有强烈的主人翁精神和责任感，同时领队愿意倾听团队的意见。
- 大方向一致，设立章程。
优秀团队文化中的沟通模式
- 同步沟通，如开会，人越少越好。异步沟通，如Email，听众越多越好。
高层面同步
- 任务宗旨。准确定义好产品的方向和范围。什么该做，什么不该做。任务宗旨应该是与时俱进的。
- 开会要有效率。
- 只邀请一定要参加的人。
- 开会前要决定好议程，而且要事先通知所有人。
- 达成目的后应提早散会。
- 注意别跑题。
- 尽量把会议安排在休息时间前后(比如午饭时间，下班前等)。
- 地理分散的团队，除了用媒介沟通，还应该时不时的见见同事。
- 设计文档。随项目变化而变化。权衡时间，不要唯设计文档论。
每日进行讨论
- 邮件列表
- 在线聊天
使用bug跟踪系统
沟通也是工程的一部分
- 代码注释。一般是用来说明代码里缺失的部分，以及起得不好的名字，然后把代码的功能注释一遍。注释应该尽量解释为什么代码要这样写，而不是解释代码做了什么。
- 在源文件署名。团队中，可以不署名，在版本控制中可以查到谁的修改。
- 每个提交都经过代码审查。
- 真正的测试和发布流程。高自动化，方便可以频繁发布
说到底真正重要的还是代码本身
大海航行靠船长
市面上写给经理们看的管理书很多，而本章却是专门写给那些客串管理的工程师看的
自然界中没有真空地带
- 软件项目就和船一样：如果没人领航，那群极客只会闲坐在那里无所事事。
@Deprecated Manager
- 以前的经理对待的员工的办法通常和赶骡车的马夫用的差不多：”萝卜+大棒”，但是工程师需要时间和空间进行创造性思考，这种方式不适应。
主管才是新经理
经理要关心怎么干，而主管只负责设定大方向。
TL(技术主管，tech leader)： 负责产品整体（或者部分）技术走向。
TLM(技术主管经理，tech leader manager)：除了负责产品整体（或者部分）技术走向，还需关系手下工程师的职业发展和愉快程度。
唯一要担心的就是……好吧，所有的事
- 管理工作不好量化，会感到成就感低，但是要反过来想，如果领导一支优秀工程师组建的团队，那代码的产量能达到多少！
仆人式领导
- 遵循HRT，消除官僚作风。
反模式
- 反模式：雇佣听话的人。
- 反模式：无视表现不佳的人。设定好一个期限，完成一些目标。目标要设的小点，循序渐进。手把手帮助表现不佳的员工。
- 反模式：无视人际关系
- 反模式：和谁都是朋友
- 反模式：降低招聘标准
- 反模式：把团队当小孩
领袖的处事之道
放下自负，鼓励多提问，学会聆听，学会道歉
做一个禅师。保持淡定和冷静。多问问题，引导工程师解决自己的问题。
成为催化剂。引导大家达成共识。
让你的团队了解到你的帮助他们解决障碍的意愿和能力。
给与他们安全感，培养敢于冒风险的氛围。
当一个导师。三个基本条件：
- 熟悉团队的流程；
- 向他人解释事物的能力；
- 估计被指导的人到底需要多少帮助的能力。
设置明确的目标。每个人都在同一方向上使劲吗？定期检查他们有没有偏离方向。
坦诚。坦诚有些事不能告诉成员。避免使用”三明治赞美法”，这样可能不能准确传达自己的意图。直接了当反馈和批评，但是注意自己的表达方式，不要让工程师被你弄得很防备。
记录快乐程度。不但关注职业生涯，更是可以让你的队员有机会得以成长。每次在会议结束之前问队员”你还有什么要求吗”
其他建议和窍门：
- 不必事事躬亲，但也不能当甩手掌柜；
- 寻找接班人；
- 知道什么时候做恶人；
- 保护团队不受混乱干扰；
- 帮团队遮风挡雨；
- 告诉团队他们做得很好。
人是植物
- 人像植物一样：有些需要更多的光照，有些则需要更多的水分。对应着方向和激励。
内部激励和外部激励
- 达到内部激励目的的三样东西。
- 自主。自主权，激发主人翁精神。
- 精通。让工程师有机会学习新技能。
- 目标。让他们知道自己的努力是有价值的。
对付害群之马(会拖累团队的人)
作者是结合自己的实际，由于SVN项目是开源项目，里面涉及到很多外部人员的相处之道。
什么是”害群”
- 是指行为，而不是指人。规定好哪些是不可容忍的行为，然后予以惩戒。
保护团队
- HRT
- 第二章内容
发现威胁
- 团队的注意力和专注力最容易受到威胁。
- 不尊重别人的时间；
- 自负；
- 过分索求；
- 幼稚或是莫名其妙的交流；
- 偏执妄想；
- 完美主义。转移注意力；
- 别去搭理哪些挑衅的家伙；
- 别太感情用事；
- 抓住重点；
- 对付挑衅要不卑不亢；
- 关注长远。问自己两个关键的问题：
- 虽然短期内会损失一些注意力和专注力，长远来讲你真的相信项目会因此受益吗？
- 你相信这些冲突最终会以有益的方式解决吗？
操作组织的艺术
优点、缺点和策略
理想的情况：团队在公司里应该是怎样运作的
- 在完美经理手下干活。要求更多的责任，不单要专注手头的任务。
- 用于冒险
现实的情况：当环境成为成功路上的绊脚石
- 在糟糕的经理手下当值。特点：害怕失败，缺乏安全感，保守，自私
- 办公室高手，敬而远之。
- 糟糕的组织。不以工程师为核心，鼓吹商业
操纵你的组织
向上请求许可，向下请求谅解。
路是人走出来的。寻求改变的办法就是拉拢群众。
学习向上管理。做承诺的时候要谨慎，而干工作的时候要尽最大努力。
“进取型”（用户看得到的）和”防御性”（产品长期健康的）工作。
运气与互惠的经济学。
晋升到安全的位置。掌控自己在公司的命运。
和有能量的人交朋友。
如何通过E-mail向忙碌的管理层求助。10秒钟读完，”三个论点，一个行动”。
B计划：走为上策
- 只做正确的事，随时准备被炒
不要放弃
用户也是人
主要是用户体验方面的。营销、易用性、客服
管理大众的印象
- 软件也需要营销
- 关心用户对软件的情感诉求
- 注意第一印象
- 承诺的时候要谨言，做产品的时候要超过预期
- 尊重业界分析师
- 关注用户，其他东西会随之而来
- 目标用户
- 考虑入门的门槛
- 衡量使用数量，而不是用户数量
- 速度很重要
- 不要大而全。与其拙劣地解决所有问题女，还不如解决大多数用户都真正会遇到的问题，然后做到最好
- 隐藏复杂性
管理和用户之间的关系
- 听取用户反馈
- 不要有优越感
- 保持耐心
- 营造信任和愉悦的氛围
