#Note# 极客与团队-软件工程师的生存秘笈
#Note# 极客与团队-软件工程师的生存秘笈
TeamGeek A Software Developer's Guide to Working Well with Others
- Andy [email protected]
- Log
- 2013/08/24-2013/10/04
本书的目标：编写软件是集体项目，人的因素对结果的影响不亚于技术因素。学习与人合作是成功路上不可或缺的重要环节。在软件工程的软技能上下点功夫，能有事半功倍的效果。
第一章 天才程序员的传说
帮我把代码藏起来
天才的传说
隐瞒是有害的
- 越早征求意见与反馈，就越能把风险降低
- 久经考验的原则：确保失败心早发生，尽快发生，经常发生
在有些时候，一开始获得太多反馈也不是好事公车因子：一个项目中，需要有多少人被公车撞倒才能令其完全瘫痪
团队才是王道
- 软件开发是集体项目
三支柱
- 谦虚
Humility - 尊重
Respect - 信任
Trust
HRT实战
放下自负
学会批评和接受批评
快速失败；学习；迭代
一份出色的事后检讨应包含以下内容- 简要
- 事件的时间线，从发现到调查，再到最终的结果
- 事件发生的主因
- 影响和损失评估
- 立即修正问题的步骤
- 防止事情再次发生的步骤
- 得到的教训
为学习预留时间
学习保持耐心
对影响保持开放的态度
第二章 培养出色的团队文化
什么是文化
- 团队文化就像是一块含有酵母的面团：
酵母（团队创始人）能将菌群培养物植入生面团（团队新人），从而变出一块好吃的面包（团队）。
为什么要关心它
- 确认新成员的文化契合度的唯一方法就是在面试的时候注意这方面的东西
文化与人
优秀团队文化中的沟通模式
高层面同步
- 任务宗旨
- 对于工程团队来讲，撰写任务宗旨就是要
准确定义产品的方向和范围 - making gwtbetter
- 对于工程团队来讲，撰写任务宗旨就是要
- 开会要有效率
有关开会的- 只邀请一定要参加的人
- 开会前要决定好议程，而且要事先通知所有人
- 达成目的后提早散会
- 注意别跑题
- 尽量将会议安排在休息时间前后（比如午饭时间，下班前等）
- 地理上分散的团队
- 设计文档
每日进行的讨论
- 邮件列表
- 在线聊天
使用bug跟踪系统
沟通与是工程中的一部分
- 代码注释
- 注释应尽量解释为什么代码要那么写，而不是去解释代码做了什么
- Google C++ Style Guide
- 在源文件里署名（也就是“作者标签栏”问题）
- 去版本控制系统里找答案
- 每个提交都必须经过审查
- 代码改动应该尽量短小以保证审查质量—若改动涉及几千行代码，那么除了挑挑格式的毛病外，基本是没办法进行审查的
- 真正的测试和发布流程
说到底真正重要的还是代码本身
第三章 大海航行靠船长
自然界没有真空地带
@Deprecated Manager
主管才是新的经理
- 我们认为应该废弃经理（manager）这个词，用主管（leader）取而代之比较好
- 经理关心的是怎么完成任务，而主管只关心完成了什么任务（并且相信团队自己能想出解决问题的办法）
- 领导的方法有很多种，有的偏技术，有的偏情感。Google 为领导团队的人准备了两种截然不同的职位（和头衔）
- TL（技术主管，tech lead）: 负责产品整体（或者部分）技术走向
- TLM（技术主管经理，tech lead mangager）: 除负责产品整体（或者部分）技术走向外，还要关心手下工程师的职业发展和愉快程度
唯一要担心的….好吧，所有的事情
彼得原理：在等级制度中，员工会趋于提升到他无法胜任的地位上去。
仆人式领导
反模式
- 反模式：雇佣听话的人
- 反模式：无视表现不佳的人
希望可不是一种策略- 帮助一个腿脚不便的人学走路，然后慢跑，最后跟上一大家的步伐。这里肯定要用上一些暂时性的微管理手段，同时还不能忘了HRT
- 反模式：无视人际关系
- 反模式：和谁都是朋友
- 反模式：降低招聘标准
- 如果因为无法信任对方，而只能不断地去干预他们的工作，那说明你在招聘的时候就已经犯错了。
- 反模式：把团队当小孩子
领袖的处事之道
- 放下自负
- 做一个禅师
- 将公司的组织结构想象成一系统的齿轮…你转到的齿轮离底端越远，就能让下面的齿轮转得越快，不管你本意是不是如此
- 冷静
- 提问
- 成为催化剂
- 团队主管要做的事情之一就是引导大家达成共识
- 出手帮助团队越过障碍继续前进是必不可少的领导技能
- 催化团队的另一种方法是给予他们安全感，这样他们就愿意接受更高的风险
- 当一个导师
- 设置明确的目标
- 坦诚
- 记录快乐程度
- 其他的建设和窍门
- 不必事事躬亲，但也不能当甩手掌柜
- 刚担任领导职务时，往往需要克制自己，把工作交给他人去做
- 如果已有领导经验，去领导新团队，最好的做法是卷起袖管，亲自动手
- 寻找接班人
- 知道什么时候做恶人
- 保护团队不受混乱干扰
- 帮团队遮风挡雨
- 告诉他们团队干得很好
人是植物
- 每个工程师都需要不同的养分才能成长
内部激励和外部激励
结语
第四章 对付害群之马
什么是害群
- 要剔走的是行为本身，而不是人。单纯第区分好人和坏人是很幼稚的想法。规定好哪些是不可容忍的行为，然后予以惩戒，才是更有建设性的务实态度
保护团队
关于linux的例子举得并不好。逻辑上有问题
发现威胁
- 不尊重别人的时间
- 自负
这个例子也不好，充满了作者个人的情绪 - 过分索求
- 幼稚或莫名其秒的要求
- 完美主义
- …指出只有理论上成立的潜在问题，而且都是一时半会不会产生什么影响的问题，不知不觉他让我们陷于瘫痪状态
对抗有害行为
- 转移完美主义者的注意力
- 别去搭理那些挑衅的家伙
- 别太感情用事
- 时刻保持冷静，知道哪些人值得回应，哪些人可以无视
- 抓住重点
- 对付挑衅要不卑不亢
- 知道什么时候应该放弃
- 关注长远
第五章 操纵组织的艺术
其它名称：办公室政治
优点、缺点和策略
理想的情况：团队在公司里应该是怎么运作的
- 在完美经理手下干活
- 刚入行的守林人的比喻
现实的情况：当环境成为成功路上的绊脚石
- 刚入行的守林人的比喻
- 在糟糕的经理下当值
- 办公室政治高手
- 糟糕的组织
操作你的组织
- 请求谅解比请求许可容易得多
- 路是人走出来的
- 在公司里，另一个寻求改变的办法是拉拢群众
- 坏习惯是停不下来的，你只有用一个好习惯去替换掉它
- 学习向上管理
- 在做承诺时要谨慎，在干工作时要尽最大的努力
- 因为如果你一直无法按期完成，或是因此放弃新功能，公司的同事对你就会变得越来越不信任，当他们需要人手完成工作的时候，会越来越忽略你的存在
- 身为工程师，应该把精力放在发布产品上，而不是其它的事情上面。发布产品比任务事情都能在公司内部提升你的信誉、声望，以及政治资本
不管技术债务如何，团队永远不应该花超过三分之一的甚至一半的时间和精力去做防御性的工作，否则等于政治自杀
- 运气和互惠的经济学
- 晋升到一个安全的位置
- 和有能量的人交朋友
- 如何通过E-mail向忙碌的管理层求助
三个论点和一个行动- 我们缺少xx，缺少xx让大家感觉郁闷，拥xx可以提高生产率
- 请给我们xx
B计划：走为上
不要放弃
第六章 用户也是人
管理大众的印象
- 注意第一印象
- 如果你拆过iPad或Nest恒温计的
包装
- 如果你拆过iPad或Nest恒温计的
- 承诺的时候要谨言，做产品的时候要超出预期
- 雷军关于口碑的说法：
我们希望做成超出大家预期的东西。因为只有超出预期才会有口碑。
- 雷军关于口碑的说法：
- 尊重业界的分析师
- 软件好不好用
- 关注用户，其他的东西会随之而来 - google
- 选择你的用户
- 衡量使用数量，而不是用户数量
- 速度很重要
- 不要大而全
- 别偷懒
- 隐藏复杂性
管理和用户之间的关系
问题在于，当用户数量上升时，他们的平均技术水平会递减，因为有越来越多的普通大众变成了你的用户。再加上不断增加的复杂度，用户失望的程度会直线上升
- 不要有优越感
- 保持耐心
- 营造信任和愉悦的氛围
- 记住你的用户
- 营销
- 易用性
- 客服