date: 2017-11-6 17:55:56
title: 「进化: 从孤胆极客到高效团队」读书笔记

图灵社区: http://www.ituring.com.cn/book/1759
百度脑图: http://naotu.baidu.com/file/8ec171f03701ba263958f6255021138c?token=856a40b1d8a70f98

三大基石(核心原则): 谦虚(Humility) 尊重(Respect) 信任(Trust)
早失败, 快失败, 常失败

天才程序员神话

天才神话:

• 关注你能控制的一个变数: 你自己
• 缺乏安全感(隐藏代码)
• 天才神话 -> 名人效应: 人有一种本能, 发现领导者和楷模, 将他们偶像化, 然后试图模仿他们

事实:

• 如果总是独自工作, 失败的风险就会增加, 你也会错失成长的机会
• 「巴士因子(bus factor)」: 项目中多少人被巴士撞死会导致项目完全无法进行下去
• 除了巴士因子, 还需要关注项目的整体进度
• 程序员在使用小型的反馈循环时工作效果最好
• 独自工作一定比多人合作更具有风险
• 不发表则消亡

团队为王:

• 软件开发是一项团队活动
• 不要低估社交游戏的力量 -> 即使项目结束, 人际关系依然存在
• 快速失败和迭代: 失败是一个选项; 从错误中学习的关键是将失败记录在案
• HRT -> 减轻痛苦, 而非伤害 -> heart, not hurt -> 你 团队 合作者 组织 用户
• 放下自我: 不够谦虚的人别摆架子; 并不是应该完全任人摆布; 和自信并不矛盾, 追求「集体」自我; 表现得服从有很多好处 vs 我要按自己的方法做
• 批评与自我批评: 建设性批评是基于尊重的; 不仅需要对自己的技术持谦虚态度, 还要相信提出批评的人是真心为你和项目好; 你的自尊不应该和你写的代码有任何联系, 你和你的产品不是一回事; 讨论仅限于代码本身, 不涉及任何人的价值或编程技术
• 留出学习时间: 跨出舒适区, 接受未知的挑战
• 学会忍耐: 结对编程
• 接受改变: 越愿意接受改变, 就越能引起改变 vs 越是脆弱的人, 越表现得坚强; 有时最好的做法就是直接承认, 我不知道; 队友是合作者而非竞争者(vs 政客)

完备的事后分析报告(事故报告):

• 概述
• 时间线: 问题的发现/调查/解决
• 事件发生的主要原因
• 影响和损失估计
• 立即解决问题的一系列措施
• 预防事件发生的一系列措施
• 吸取的经验教训

团队文化

文化:

• 维护团队文化: 团队领导者 vs 团队每个成员
• 团队契合度面试
• 让团队拥有卓越的工程师
• 基于共识的团队
• 接受批评需要一定程度的自信
• 一切为了产品: 你的产品最终与人沟通, 而不仅仅与机器沟通

方法:

• 人少时使用同步沟通(邮件), 人多时使用异步沟通(邮件, bug追踪, 文档注释)
• 最重要的是, 要保存所有的信息都存在项目文档中, 大家都可以访问
• 任务说明书: 简明定义工作方向, 限定产品范围
• 高效会议: 任何需要深入讨论的事情都应该在会后进行, 只要求相关人员出席; 有人来负责主持会议, 保持会议简短
• 面对面沟通(分布式团队): 不要低估信息量; 重要性
• 设计文档
• 邮件列表: 约定邮件谈论规则, 保持文明, 防止「聒噪」的少数人「扰乱秩序」
• 在线聊天: 群聊与一对一即时消息
• bug追踪系统
• 工程中的沟通: 代码注释应该关注代码如此实现的理由, 而不是代码的功能; 强调一致性; 不要署名; 每次提交必有审阅; 测试与发布流程

主持会议的五条简单准则:

• 只邀请必需人员参加
• 草拟议程并在会议开始前尽早发出
• 完成会议目标即可散会
• 保持会议按议程进行
• 尽量将会议安排在中断点附近(午餐/下班时间)

群龙不可无首

经理 -> 领导者
经理: 「有人向他汇报工作」, 而不是「必须发号施令」
唯一需要担心的是, 所有事
服务型领导

反模式:

• 雇佣软弱者: 你应该努力雇佣比自己聪明, 可以替代自己的人
• 忽视表现不佳者
• 忽视人际问题
• 与所有人为友
• 放宽招聘标准
• 把团队当孩子管: 要让团队指导你不信任他们, 最好办法就是像对待孩子一样对待他们

领导模式:

• 放下自尊: 应该努力培养强大的团队集体自尊和认同感; 信任团队; 需要对自己的角色有基本的安全感, not all things; 犯错时道歉
• 禅意大师: 作为工程师, 你可能惯于持怀疑态度, 还有些愤世嫉俗, 但是这种心态不适合领导团队; 你可以把公司架构看做一组齿轮; 领导者总是身在舞台之上; 提出问题
• 成为催化剂: 加速化学反应但是不损耗自身; 很多时候认识正确的人比知道正确的答案更有用; 失败是一个选项, 在风险上 个人 vs 公司
• 成为老师和导师: 熟悉团队流程和系统; 能够向别人清楚解释事情; 能够判断新人需要多少帮助
• 设定清晰目标
• 以诚相待: 我不会对你说假话, 但如果事情不能透露, 或者我也不知情, 我会如实地告诉你; 如果希望对方能听取批评, 善意和同情是关键; 每次做出一个决定, 就像一列火车穿过城镇
• 关注幸福度: 一对一对话结束时「你需要什么」; 关注团队在办公室以外的幸福度也很有用; 关注职业发展
• 放权, 但是也要做具体工作; 寻找接替自己的人; 知道何时出手; 给团队一方净土; 保护团队; 肯定团队的成就; 同意尝试容易恢复的事情

the lead:

• 不想担任管理者, 但不知怎的就担任了领导者的角色 -- 管理炎
• 冒充者现象: 装着装着就成真了
• 无聊到兴奋 -> 需要激励; 散漫到自主 -> 需要指引
• 内在激励: 自主性 卓越性(提供学习新技能/提高已有技能的机会) 目标

应对有害之人

「如何从有害之人手中拯救项目」
「驱除恶人」的经营同盟会 -> 创造一种拒绝容忍特定负面行为的团队文化
将人视为纯善或者纯恶是幼稚的行为, 发现和谴责不可容忍的行为则更为有效和实际
团队文化 -> 自我选择性

最好的防御手段是制定一组有效的最佳实践和流程, 巩固团队文化:

• 发布任务说明书, 明确目标和非目标
• 为邮件讨论建立适当的礼节规范. 保存归档, 请新成员阅读归档邮件, 防止少数人干扰讨论
• 记录所有历史: 代码 设计决策 重要bug修复 以往错误
• 有效合作: 保持代码少改动, 可审阅, 增大「巴士因子」
• 明确 bug 修复/测试/软件发布的政策和流程
• 降低新成员的磨合障碍
• 依赖基于共识的决策方法, 但也要制定备用流程

发现威胁:

• 不尊重他人时间
• 自大: 无法接受集体决定, 不能听取/尊重相左意见, 或不愿做出让步的人
• 颐指气使: 整天抱怨不足之处, 又不愿给出任何直接帮助
• 沟通幼稚或混乱
• 疑神疑鬼
• 完美主义: 可能使团队丧失行动能力

祛除毒素:

• 引导完美主义者的能量
• 对挑衅不予理会通常需要极大的意志力, 坚持住
• 不要过于情绪化: 你的工作是创造伟大的事物
• 在愤怒中寻找事实
• 以德报怨: 有时候表现得格外友善可以把人吓走
• 适时放手: 知道如何识别败局
• 放眼未来: 就长远来说, 你确实相信项目将受益么? 冲突最终会以一种有益的方式解决吗? 为了短期效益而损害团队文化是不值得的

组织操控的艺术

大多数人所在的公司都存在各种问题, 需要应用某些操控技能才能有效的完成工作. -> 政治 / 社会工程 / 组织操控
经理为你服务, 还是你为经理服务?
你必须了解的是, 这些规则与计算机系统的规则没有什么不同. 有些规则可以改变, 其他的规则可以打破. 明白了吗? 那就来战吧.

理想情况:

• 两层: 经理和经理以外的部分
• 完成本职工作后, 寻求更多职责
• 承担风险而且不惧失败
• 表现得像成年人一样: 别人怎么待你, 其实取决于你自己
• 对不确定的东西提出疑问
• 经理不是透视眼: 及时汇报工作进度

通常情况:

• 不称职经理: 害怕失败; 缺乏安全感而坚持插手; 知识就是力量而不愿意分享; 藏匿信息
• 办公室政治家: 整天做出有影响的样子, 而不是实际产生影响
• 管理不当组织: 工程师是完成商业目标的手段; 指挥和控制结构僵化有如割据; 充满了极力维护组织层级的人; 缺少一些重要的东西, 比如焦点/愿景/方向

操控组织:

• 了解公司允许什么行为, 相信的自己的直觉固然不错, 但从你信任的人那里获得一些意见也非常重要的
• 另辟蹊径: 在公司内做出改变 -> 让底层接受; 说客 -> 找几个支持你的人; 想法 -> 不在意功劳归谁, 可以流传很广; 停止坏习惯 -> 替换为好习惯
• 学会向上管理: 需要确保自己的经历和团队外的人不仅知道你在做什么, 而且知道你做的很好; 尽可能少承诺, 多提交; 推出产品放在首位
• 将工作分为「进攻性」和「防御性」: 进攻性 -> 产品改进, 用户可见; 防御性 -> 产品长期健康; 法律的十分之九是认知(财富); 防御性工作不要超过三分之一/二分之一
• 运气和人情经济: 运气好的人「善于创造和捕捉偶然机会」
• 政治银行账户: 人情经济
• 晋升到一个安全职位: 能让你升职的事情 vs 对公司重要的事情
• 寻找有影响力的人: 联系人 老员工
• 写信寻求高管帮助: 三个要点和一个行为召唤; 不那么生动, 但是 10s 就可以看完
• 备用计划 - 撤退: 做正确的事, 等着被炒; 如果的确无能为力, 那就不要耗着, 走为上策

用户也是人

用户是软件成功的命脉, 一份耕耘一分收获

产品开发成功的要素:

• 一小群聪明富有创造力的人开始
• 注入 HRT 团队文化
• 以服务的方式领导他们, 帮助他们打成合作, 作出明智的决策
• 内在激励
• 保护他们免受负面影响
• 循环: 用户使用 -> 反馈 -> 改进

用户参与:

• 注意到产品: 存在 使用前看法
• 用户体验:是否达到预期 可用度 是否帮助了用户
• 与忠实用户高效互动

积极和用户合作:

• 市场营销: 不能忽视; 积极合作是可能的; 程序员总是逻辑感过强, 但大多数人的行为决策收到逻辑和情感的双重影响, 必须考虑用户对产品的感性认知
• 注意第一印象, 产品的最初一分钟的体验
• 少许诺多提交
• 与工业分析师谦恭合作: 用非暴力不合作的态度对抗一个系统, 绝对没必要
• 可用性: 关注用户, 其他都将水到渠成; 选择听众; 考虑进入壁垒; 衡量使用量, 而非用户数
• 设计很重要: 用户为先, 不可「产品懒惰」(office的全工具条); 速度不容忽视, 延迟也是「进入壁垒」, 响应快速会对用户产生很深的潜意识影响; 速度是一个功能; 切勿求全, 少即是多; 隐藏复杂性, 但封闭产品来束缚用户不可取, 是因为愿意, 而不是无法离开
• 管理与用户的关系: 客户服务, 用户希望建立联系, 有人倾听; 时间推移, 用户增多, 平均技术水平降低, 而软件复杂度上升; 尊重用户智商; 保持耐心, 最关键的倾听技巧在于学会理解人们想要说的是什么, 而不一定要试图解释他们实际说的是什么; 创造信任和愉快, 不存在所谓的暂时失去诚信, 信任是最宝贵的资源, 必须从别对自己太严肃开始

记住用户:

• 市场营销
• 产品设计
• 客户服务

附录

工程易做, 人际关系难处.
众人的审视使缺陷无所遁形 -> 众人的审视使项目保持相关性, 并按计划进行
取得原谅比获取许可更容易
发现一万种走不通的路, 并不意味着我失败了. 我不会气馁, 因为每次失败的尝试都是前进的一步. -- 爱迪生
他常常游走在天才和疯子的边界上. 问题是, 如今天才是件商品, 举止怪异已经行不通了. -- Greg Hudson
不要讲愚蠢归为恶意 -- Robert J. Hanlon
TED: 内向者的力量
如果讨论不在邮件项目组中进行, 那就真的没有发生过 -- subversion 项目组
愿望不是策略 -- Google 服务运维团队
不要喂食能量生物 -- Usenet
任何层级组织中, 每个人都将晋升到他不能胜任的阶层 -- 彼得原理

创客 maker
人件 peopleware
maker's schedule, manager's schedule
科学管理 scientific management
泰勒主义 Taylorism
技术主管 tech lead, TL
技术主管经理 tech lead manager, TLM