软件编写是一项集体活动，我们认为人的因素和技术因素一样，对项目结果有很大的影响。
大部分人可能花费了数十年的时间学习编程技术，却从未真正关注过人的因素。
1. 天才程序员神话
天才神话
天才神话，各种大神云集，Linus、比尔盖茨等等，创造了一个个神话诸如：。。。。变成了被常人仰视，被供奉的存在，Linux 的成功是源于linus写了第一个内核，创建了 git 的协作方式，更多的工作是由团队完成。尤其在现今的开发环境中，不排除有部分独立开发者进行着个人项目开发，也有相当的拥趸。
名人效应: 人有一种本能, 发现领导者和楷模, 将他们偶像化, 然后试图模仿他们
个人开发
那我们来看一下 个人开发 中可能存在问题：
如果别人看到我未完成的工作，我会非常没有安全感，觉得他们会肆意批评我，并认为我是个白痴。
- 失败风险 / 错失机会：我们希望在事情做到完美的情况下，再把一切公之于众，可能重复造轮子，也可能错过了绝佳的合作者，
- 巴士因子：项目中多少人被巴士撞死会导致项目完全无法进行下去。
- 不发表则消亡 / 分享想法
团队为王
- 软件开发是一项团队活动。
三大基石
- 谦虚（Humility）———— 你并非宇宙中心，并非无所不知，也会犯错，但愿意自我改进。
- 尊重（Respect） ———— 你要真诚关心同事，以礼相待，欣赏其能力，认可其成就。
- 信任（Trust） ———— 你要相信别人可以胜任工作并作出正确选择，愿意在合适的时候将权力交给他们。
HRT 遵循的建议：
- 放下自我：不摆架子，保持态度谦虚，注意态度谦虚 !== 不自信。追求团队成就和集体荣誉感；
- 批评和自我批评：人身攻击毫无价值，这种行为既卑劣又没法回应。建设性批评通常是有益的，能够指导我们改进。建设性批评是基于尊重的，出于对接受方的关心，期许对其有帮助。接受方要能接受批评，并相信提出者的初中是真心为你和项目好。另一个角度讲：你的自尊不应该和你写的代码（或创建的任何创新项目）有任何联系。 对代码、项目的批评指正 !== 对你的否定；
- 快速失败 和 迭代：“失败是一个选项。”从来不犯错误，说明你没有足够的创新性去承担足够的风险。失败会为下一次的努力提供了学习和改进的最佳机会。事后分析报告：解释学到了什么，计划作出什么改变，后来者更容易了解当时发生了什么并避免重复历史。不要擦除你的足迹，照亮来路，以便后来者追随！
- 留出学习的时间：即使你是团队里技术最强的人，不断的接触新事物、保持谦虚，保持分享和学习；跨出舒适区, 接受未知的挑战
- 学会忍耐：团队中可能存在与你工作方法、认知不相符的成员，要包容、学会利用不同的角度；
- 接受改变：不要固执，不要固步自封，接受“我不知道，你有好的想法吗？”实际上，这也是HRT原则的表现：对外表现出谦虚的态度，不仅可以显示出可靠性和责任感，还说明你信任别人的观点，最后，人们也会尊重你的诚实和能力。
下一步：如何在团队中打造 HRT 氛围？
2. 打造团队文化
什么是团队文化？
团队文化就像一块好吃的酸面团面包：剂子（创始人）向面团（新成员）注入菌群（文化），随着酵母和细菌（团队成员）的成长，就可以做出好吃的面包（团队）。如果创始文化足够强大，就可以同化新成员可能带来的不和谐因素。2如果创始文化过弱，那么团队很容易受到新成员带来的未知文化的干扰。未知文化带来的影响难以预测，因此团队文化的培养还是从已知创始文化开始为宜。
团队文化不仅仅是团队成员完成工作、编写代码或彼此相处的方式，而且是成员共享的经验、价值观和目标。也会随着团队成长不断变化和发展。
团队文化的重要性:
- 一个优秀的工程师不仅能为产品开发作出贡献，而且也可以参与产品的决策过程，团队成员能达成共识。
- “共识”是指每个人对产品的成功都有强烈的主人翁意识和责任感，领导者能够听取团队成员的意见（重视HRT中的尊重原则）。在这样的团队中，人们有时进行很多讨论和思考，有时又需要加快进度。当需要加快进度时，可能会将大量日常琐碎的决策托付给一位或多位领导者。
成功团队文化的沟通模式
重视几种沟通渠道，如邮件列表、设计文档、聊天室、任务说明书、产品手册，等等。
人少时使用同步沟通（如会议和电话会议），人多时使用异步沟通（如邮件、问题跟踪系统、文档注释）。中断成本
包括：
- 高层同步：在最高层次上，团队需要保持统一的共同目标，在沟通中遵循最佳实践。
- 高效会议
- 设计文档：设计文档不仅是未来产品的概要蓝图，而且也是与大团队沟通的低成本方式，可以传达你的设计目标及实现方法
- 面对面 && 异步聊天工具
- 问题跟踪系统
工程中的沟通:
- 注释
- 署名：最多可以指定修改此文件的首选审阅人
- 代码提交要有审阅
- 测试与发布流程
团队文化和沟通习惯反映了我们喜欢的工作方式，可能带有一些主观喜好，时间上一个好的团队文化下，成员会将更多的时间花在编写和提交产品上
3. 团队leader
要关心的事，是所有事，通常技术转型管理会有一个很大的空虚状态：原有的工作量化是代码提交、需求完成，转型管理后，会有一天下来碌碌无为的感觉。作者举了一个栗子：这就好像你多年来一直按每天摘的苹果计算工作量，工作变成摘香蕉之后，你收工时对自己说“我今天一个苹果也没摘”，却对身边的一大堆香蕉视而不见。对管理工作进行量化比计算组装好的工具要困难得多。你不能把团队的工作成果算成自己的功劳，但保持团队成员心情愉快、工作高效是衡量你的工作的重要标准。请不要犯摘香蕉时数苹果的错误。
服务型领导:
- 领导者能做的最重要的事是为团队服务，就像管家照料家人的健康和福利一样。作为一位服务型领导者，你应当努力营造一种HRT氛围。唯一需要管理的是团队的技术和人际关系的健康。
反模式：成为成功领导者不应陷入的一些模式
- 雇佣软弱者。管理者缺乏安全感，确保无人质疑其权威和地位，雇佣不如自己、易控制的人。会导致自己在团队中的角色责任越来越重，增加工作量，失去自己的管理，团队寸步难行。
- 忽视表现不佳者。管理人最难的部分则是管理那些无法达到预期的成员，暗自希望表现不佳的成员会突然有所长进，或者自行离开。而这两种情况都极少发生。要尽快处理表现不佳者，设定具体时间计划，列出希望在此期间实现的具体目标，使失败容易衡量。这期间如果无法跟上进度，管理者和表现不佳者都能认清现实、发现问题，或者奋发图强、或者离开。
- 与所有人为友。友谊 !== 温和的领导方式，保持一视同仁，不能因为友谊产生区别对待，或者因为友谊而导致部分同学曲意逢迎
- 放宽招人标准。没有构建优秀团队的原材料，只能注定失败。
- 把团队当孩子管。你怎么对待人们，人们就会怎么做。因此，如果你把他们当孩子或囚徒对待，他们也会表现得像孩子或囚徒一样。给予信任，回报信任。
领导模式：
- 放下自尊。信任团队，尊重团队成员的能力和成就，对新成员也是如此。任何人不可能所有事情都做对、都了解，也不能解决所有问题，接受批评，真心承认错误。道歉不会表现为脆弱，而会赢得尊重。道歉表明你头脑冷静，能够审时度势。 对照 HRT 原则：态度谦虚；
- 成为‘禅意大师’，少发表怀疑言论，保持冷静。整个团队都会有意无意地把目光投向自己的 leader，你的状态、情绪会影响团队表现。另外一个难点是：提出问题，抛掉工程师习惯的解决问题模式，改为提出问题，通过问问题的方式引导问题解决，问的问题要在垫子上。
- 成为催化剂。促成共识、驱动团队/事情朝着正确的方向，略加推动以加速过程的完成。
- 失败是一个选项。失败也没关系，大部分人不善于评估风险，竭尽全力规避风险，导致人们保守形式，难以追逐大的成功。caseStudy 的目的也是为了总结经验、发现漏洞，从失败中学习。失败时冷静分析，不做指责。
- 成为老师和导师
- 设定清晰的目标
- 以诚相待
- 关注幸福度
- 其他提示和技巧: 放权，但也要做具体工作；寻找接替自己的人；知道何时出手；给团队一方净土；保护团队；同意有价值的冒险
人和植物一样，每个人对关照、水分、养料的需求不同，管理者提供的应该是激励与指引，使团队保持快乐、高效。
无聊到兴奋 -> 需要激励; 散漫到自主 -> 需要指引 激励有两种：源自外部因素（如金钱）的外在激励和源自内心的内在激励 有三样东西可以提升人们的内在激励：自主性、卓越性和目标。
4. 应对‘有害之人’
我们了解构建稳固且沟通良好的团队文化的重要性，介绍了良好的团队文化应该包括什么：基于共识的开发、高质量代码、代码审阅，以及鼓励大家进行新尝试并从快速失败中学习的环境等。
这里的“有害之人”这个词指代行为不佳的人。但在实际工作中，最好避免在日常谈话中用这个词！
发现威胁
保护团队不受有害之人的侵扰，要做的第一件事是了解构成威胁的因素是什么，什么时候应提高警惕。最可能受到影响的是团队的注意力和专注力。
注意力和专注力是最为稀缺的资源。
- 不尊重他人的时间
- 自大
- 颐指气使
- 沟通幼稚或混乱
- 疑神疑鬼
- 完美主义
去除毒素
很多时候我们不自知，对自己产生的负面影响没有感知，适当的引导能够帮助我们改变自己行为，去掉负面影响。这里关注的是如何消除行为，当然多次努力行为仍无改观，赶人走也就成了最后防御。
- 引导完美主义者的能量
- 对故意捣乱或者带偏问题的人不作回应，保持克制，对方无趣便会放弃坚持。
- 不要过于情绪化
- 在愤怒中寻找事实，从中积极寻找事实
- 以德报怨，表现的乐观友善会让很多找茬的人失去兴趣；
- 适时放手，引导和尝试要有限度，不管你如何努力，最后还是需要选择放下，继续前行
放眼未来
如果见到你觉得可能有害的行为，你需要向自己提出两个关键问题。
- 抛开团队注意力和精力的短期损失，就长远来说，你确实相信项目将受益吗？
- 你相信这个冲突最终会以一种有益的方式解决吗？
以上两个问题中的任何一个答案为否，那么你需要出手干预，尽快停止这种行为。基于HRT的强大团队文化是不可替代的，但技术能力绝对是可以替代的，不做无限度的包容。为了短期效益而损害团队文化是不值得的
5. 组织操控
组织操控：理解如何在良好或不佳的公司中工作。大多数人所在的公司都存在各种问题，需要应用某些操控技能才能有效地完成工作。有些人将此称为政治，也有人称之为社会工程。
理想状态
如果你有一位服务型的经理，遵循HRT原则，真心实意想帮助你成功，那么你可以做到几件简单的事情，使他的工作更容易，从而也使自己工作更高效，在团队中更有价值。也许更重要的是，做到这些可以使你的工作成绩更优异，职业更成功。
- 承担风险 并且 不惧失败。
- 表现得像个成年人。别人采取什么行动，如何对待你，其实取决于你自己
- 对不确定提出疑问
- 及时向领导回报进度，而不是等着他来问你。
通常情况
- 不称职的经理：害怕失败; 缺乏安全感而坚持插手; 知识就是力量而不愿意分享; 藏匿信息
- 办公室政治家：他整天作出有影响的样子，而不是实际产生影响。
- 管理不当的组织：随着发展，公司会设置机构和流程，以管理利润、降低风险、提高可预测性，并适应组织自身的庞大规模。久而久之，这些机构会发展到阻碍公司成功的地步。更甚者指挥和控制结构僵化. 缺少一些重要的东西, 比如焦点/愿景/方向
如何解决这种困局？只有跳槽吗？？如果跳槽后的公司也存在这些问题呢？？？
操控组织
你应当承认事情的现状，专注于探索公司结构，寻找一些策略用于有效完成工作。
- 知道什么情况是不能被容忍的，从你信任的人那里获得一些意见也非常重要的；
- 另辟蹊径：在公司内做出改变 -> 让底层接受; 说客 -> 找几个支持你的人; 想法 -> 不在意功劳归谁, 可以流传很广; 停止坏习惯 -> 替换为好习惯
- 向上管理：你需要确保自己的经理和团队外的人不仅知道你在做什么，而且知道你做得很好。尽可能少承诺, 多提交; 推出产品放在首位
- 将工作分为「进攻性」和「防御性」: 进攻性 -> 产品改进, 用户可见; 防御性 -> 产品长期健康（代码重构、功能重写、格式修改、数据迁移，或者改进的紧急情况监控）；防御性活动能提高产品的可维护性、稳定性和可靠性。但是无法得到任何政治功劳，不可见，遵循一个简单准则：不管欠了多少技术债，团队花在防御性工作上的时间不应超过全部工作时间的三分之一到二分之一。超出这个范围都是自寻死路。
- 运气和人情经济: 运气好的人‘善于创造和捕捉偶然机会’
- 政治银行账户: 人情经济
- 晋升到一个安全职位: 能让你升职的事情 vs 对公司重要的事情
- 寻找有影响力的朋友：联系人、老员工
- 写信寻求高管帮助：“三条要点和一个行为召唤”：优秀邮件应最多包含三条要点说明当前的问题，以及一个——只有一个——行为召唤，简洁，十秒内 看完得到要点，“当有机会纠正错误时，身居高位的人通常会很乐意去做”
- 备用计划：撤退。做正确的事，等着被炒；如果你的确无能为力，那就不要再耗着了，走为上策。
PS：不是说如果现在的工作干得不开心就应该更新简历立马走人。相反，你的首要目标应当是作出所需的改变，使自己开心，完成工作目标，不去努力了解如何操控所在的组织结构，就无法掌握自己的职场命运。
6. 用户也是人
合作不限于团队，要创造优秀的产品，你还需要积极地与用户合作，一个没人使用的漂亮软件没有意义。
- 管理公众认知：收集用户反馈，客服、实施、市场，考虑用户对产品的感性认知。
- 第一印象：新用户 30s 内的体验
- 少许诺多提交：给预期功能一个保守的时间估计。抢先发布了，客户会惊喜，google 任何产品不许预先公布功能。房子团队内部拼命加班赶工在对外宣称的不切实际的时间点交付产品。软件应该真正完成并可用时发布。
- 用户可用性：除非你开发的是软件工具，否则工程师不会是软件的用户。谷歌有一句名言：“关注用户，其他便都将水到渠成。”
- 考虑进入的壁垒：初次使用成本，尽可能降低。
- 设计：以用户为先，速度不容忽视（“速度是一个功能。”），切勿求全，隐藏复杂性
- 管理与用户的关系：客户服务, 用户希望建立联系, 有人倾听; 时间推移, 用户增多, 平均技术水平降低, 而软件复杂度上升; 尊重用户智商; 保持耐心, 最关键的倾听技巧在于学会理解人们想要说的是什么, 而不一定要试图解释他们实际说的是什么; 创造信任和愉快, 不存在所谓的暂时失去诚信, 信任是最宝贵的资源, 必须从别对自己太严肃开始
这一章总结为三个要点：
- 市场营销：了解人们对软件的看法；这决定了他们会不会愿意尝试。
- 产品设计：如果软件做不到容易尝试、速度快、友好，而且用户面广，用户就会流失。
- 客户服务 主动与用户建立长期的良好关系能影响软件的演化和用户保持率。