自我改进

核心：

• 软件开发是集体活动
• 职业的成功取决于能否与他人很好的合作
• 三个核心原则：谦虚，尊重，信任

问题：

• 隐藏自己刚开始的工作，独自工作，缺乏安全感，担心别人评价未完成的工作
• 原因分析：
  • 没有人愿意接受批评，尤其对自己未完成的工作
  • 偶像化领导者和楷模，并试图模仿他们。
  • 不愿意分享刚开始的工作，怕别人看到自己的错误，认为作者不是天才
  • 想要隐藏想法，独自工作，然后有朝一日完美展现。
• 害处：
  • 独自工作，失败风险增加，错失成长机会。
  • 在进行一场代价高昂的赌博，无法知道努力方向是否正确
  • 失败风险更高
• 和别人分享的好处：
  • 需要确定努力的方向正确，方法正确，并且没有重复他人的工作。
  • 早期获取反馈意见越多，出现错误可能性越小。
  • 早失败，快失败，常失败。
  • 增加巴士因子（项目中多少人被巴士撞死会导致项目完全无法进行下去）
  • 使用集体智慧解决问题
  • 可以随时根据反馈以适应环境变化

团队合作所需社交技能

• HRT原则
  • 谦虚(Humility)：并非无所不知，会犯错，但是愿意自我改进
  • 尊重(Respect)：关心同事，以礼相待，欣赏能力，认可成就
  • 信任(Trust)：相信别人可以胜任工作并作出正确选择，愿意在合适的时候将权力交给他们

HRT实战

• 放下自我
  • 追求“集体”自我。不要担心个人表现是否出色, 更应该尝试培养一种团队成就和集体荣誉感。
• 批评与自我批评
  • 不要人身攻击，应该用基于尊重的建设性批评（真切关心，希望对方改进，尊重同伴，有礼貌）。
  • 自尊不应该和你的代码有任何联系。
• 快速失败和迭代
  • 如果从来不犯错，表示没有足够的创新性去承担足够的风险。失败为下一次的努力提供学习和改进的最佳机会。
  • 失败后要记录事后分析报告：
    • 概述
    • 从发现问题,调查问题,到解决问题的时间线
    • 事件发生的主要原因
    • 影响和损失估计
    • 立即解决问题的一系列措施
    • 预防事件再次发生的一系列措施
    • 吸取的经验教训
• 持续学习
  • 如果停止学习,你就会觉得无聊,或者无意间变得落伍。
  • 在有所成就后，需要保持谦虚,既愿意传授知识,也愿意学习。
  • 跨出自己的舒适区，接受更多未知的挑战。
• 学会忍耐
• 接受改变
  • 自己的观点可以受别人影响。并不是每件事情都必须坚持己见,要谨慎选择需要坚持的事情。
  • 你要先聆听别人的意见,别人才会听取你的意见。
  • 在宣布自己的立场或观点 前最好先听取别人的意见,如果你不断改变观点,别人会认为你优柔寡断。
  • 对外表现出谦虚的态度,不仅可以显示出可靠性和责任感,还说明你信任别人的观点,最后,人们也会尊重你的诚实和能力。

打造团队文化

什么是团队文化

• 团队文化是团队成员完成工作、编写代码或彼此相处的方式，是成员共享的经验、价值观和目标。
• 团队文化可以影响团队的生产力和吸引、留住优秀团队成员的能力

团队文化和人的关系

• 良好的团队文化可以让留住优秀的工程师，让他们放心的分享想法，并有参与决策过程的权利。
• 优秀的工程师希望自己不仅能为产品开发作出贡献,而且也可以参与产品的决策过程,这通常要求团队的管理在一定程度上基于队员的共识。
• 团队应该具有很强的集体自我, 而不应该完全淹没在团队成员的个人自我中。

成功团队文化的沟通模式

• 确保每个成员都认同团队的方向并准确理解当前任务，这样可以提高团队的生产力，并提升团队的幸福感。
• 沟通通用准则：人少使用同步沟通（代价大），人多使用异步沟通。
• 要确保所有信息都存在项目文档中，大家都可以访问。
• 如果不花费时间建立良好的沟通机制,会有大量精力浪费在不必要或其他成员已经解决了的事情上。

高层同步

• 在最高层次上,团队需要保持统一的共同目标,在沟通中遵循最佳实践。

任务说明说

• 在一个实干、高效的团队中,编写任务说明书是为了简明地定义工作方向,限定产品范围。编写任务说明书可能需要一些时间和精力, 但任务说明书明确了团队应该做什么,不应该做什么,可以节约大量的工作。

高效会议

• 任何需要深入讨论的事情都应该在会后进行,只要求相关人员出席。
• 保持会议简短。
• 主持会议的五条准则：
  • 只邀请必需人员参加
  • 草拟议程并在会议开始前尽早发出
  • 完成会议目标即可散会
  • 保持会议按议程进行
  • 尽量将会议安排在中断点附近(如午餐或下班时间)

分布式团队

• 团队成员分散，不在同一个地理位置办公
• 如果讨论不在有家列表中进行，就没有真的发生过
• 定期进行面对面沟通交流

设计文档

• 设计文档不仅是未来产品的概要蓝图,而且也是与大团队沟通的低成本方式, 可以传达你的设计目标及实现方法。
• 设计文档一旦定稿,就可以作为项目时间的安排和工作划分的指引。
• 随着项目的发展和变化,设计文档应当随之及时更新,而不是等到产品交付才一次性修改。

日常讨论

邮件列表

• 通过邮件列表发送会议议程、会议纪要、结论、设计文档, 以及其他任何相关的文字信息,从而很方便地保存记录。

在线聊天

• 聊天要求所有参与者都在线,以便结论达成时进行快速实时讨论。如果一些参与者不在场,或者不急于做决定,邮件更为适用。

使用问题跟踪系统

• 应该建立某种处理和仲裁缺陷的流程,鼓励人们及时报告并修复缺陷。

工程中的沟通

代码注释

• 注释可提供与原作者意图和想法相关的信息，同时需要持续维护。
• 注释应当关注代码如此实现的理由，而不是代码的功能。

代码风格统一

• 风格统一，遵守约定，更容易地使用“模式匹配”,推断各种符号的含义和属性。
• 创建通用、必需的习语和模式可以提高代码的可读性。某些风格约定有时可能值得商榷,但为保持一致起见,我们依然保持现有约定不变。

不要署名

每次提交必有审阅

• 每一行代码都要经过除修改者之外的审阅者检查
• 保持代码每次只进行小修改,而且修改可审阅——数千行的修改基本无法审阅,只能看看格式而已。

测试与发布流程

• 尽可能完善的自动化测试
• 测试应该成为编码和审阅流程中的一部分
• 发布流程应该足够灵活，可以进行经常性的版本发布

团队需要领导者

领导者的必要性

• 如果没有人领航，项目团队就是一群只会等待事情发生而无所事事的极客而已。
• 如果项目要有所进展，就需要有人领导，不管是否是官方任命的领导者。

要做领导者而非经理

• 经理：关心如果做事
• 领导者：
  • 关心做什么事（并相信团队知道如何将其实现）
  • 为团队创造条件,照看成员的安全和健康,同时确保大家的需求得到满足。
• 领导者分类：
  • 技术主管：负责产品的整体(或部分)技术方向
  • 技术主管经理：除了负责产品的整体(或部分)技术方向外,还要兼顾团队成员的职业发展及心理健康。
• 角色改变之后的区别：不能把团队的工作成果算成自己的功劳，保持团队成员心情愉快、工作高效是衡量你的工作的重要标准。

做服务型领导

• 不要急于管理，需要做的是为团队服务。
• 服务型领导者为团队搭桥铺路,在需要时给出建议,而且依旧愿意从事具体工作。
• 服务型领导者唯一需要管理的是团队的技术和人际关系的健康。

领导者需要避免的错误

雇佣软弱者

• 雇佣容易控制的人虽然可能确保你作为团队领导者和决策者的地位，但会增加大量工作。
• 应该雇佣比自己聪明，可以替代自己的人。

忽视表现不佳者

• 管理员最难得部分是管理那些无法达到预期的成员
• 如果忽视表现不佳者,新的表现优异者不会加入团队,已有的得力成员也会离开。最终剩下的整支团队都是表现不佳者,因为只有他们无法主动离开。
• 帮助不佳者改进工作或离开团队。

忽视人际问题

与所有人为友

• 不成为团队成员的伙伴(或铁腕强权)也能领导一支团队。

放宽招人标准

• 找到合适的人虽然代价不菲，但是成本低于处理一名本不该招进来的员工。

把团队当孩子管

• 如果你把他们当孩子或囚徒对待,他们会知道你不信任他们，他们会表现得像孩子或囚徒一样。

领导模式

放下自尊

• 信任团队，让成员更了解任务细节，可以增进他们对项目的成功（或失败）产生更强的责任感。
• 鼓励别人提出疑问，接受意见和批评。
• 犯错时道歉。

保持冷静，仔细思考

• 少发表一些怀疑言论,同时要让团队知道你了解工作中的复杂情况和困难障碍。
• 仔细斟酌如何应对周遭情况，保持冷静。
• 作为一名领导者,你的工作是激励大家,而激励是一项需要时刻进行的工作。你对于任何事(无论多小的事)的态度都会在无意间受到关注,从而影响整个团队。
• 当员工向你寻求建议时，你应该帮助他解决问题，尝试细化和探究问题,帮助他自己解决问题。这样可以增强员工的主人翁意识和责任感。

成为催化剂

• 促成共识
• 全力帮助团队克服障碍继续前进
• 很多时候,认识正确的人比知道正确的答案更有用。

让团队尝试更大风险的事

• 虽然尝试不可能的任务很可能会失败，但是失败获得的成果仍然可能比只尝试自己能力范围内的任务要多得多。
• 失败是快速学习大量知识的方法（不要重复同样的失败）
• 将失败视为学习的机会,而不要趁机指责或怪罪别人。
• 失败之后要进行事后分析报告，记录导致失败发生的时间，总结出防止此类事件再次发生的一系列步骤。目的是关注问题的核心，一劳永逸的解决这个问题。
• 失败时指责个人会分化团队，要让团队承担失败，并从失败中学习经验。

成为老师和导师

• 要指导他人，给他人学习的机会。
• 当导师主要有三个条件: 熟悉团队的流程和系统;能够向别人清楚地解释事情;能够判断新人需要多少帮助。

设定清晰的目标

• 给团队一个前进的方向，同时需要确保队员都明白并认可前进的方向。

• 给团队更多的自主权，只需要不时了解一下情况,确保大家仍在正确的轨道上就可以了。

• 以诚相待

  • 对于不能直言相告的事情，直接告诉对方自己知道答案但是不能说。
  • 对于自己不知道的事情，直接告诉对方自己不知道。
  • 在提供直接反馈或批评一件事，要确保消息传达到位（不要用三明治评价法，夹杂着别的内容），需要表现善意和同情，不能让对方产生反感。

• 关注幸福度

  • 在每次一对一谈话结束时问:“你需要什么?”
  • 思考如何帮助团员实现想法，关注团队成员的幸福度,不仅要关注他们的职业发展,还要提供机会,使他们的能力得到提高,工作得到认可,而且在工作中获得乐趣。

• 其他

  • 放权，但也要做具体工作。
  • 寻找接替自己的人，招聘比自己聪明的人
  • 对于一些困难情况，必须适时出手，有些事情并不会自己消失，拖越久对团队其他人的不利影响越大
  • 把混乱阻隔在团队之外。
  • 保护团队
  • 肯定团队的成就，犯错时要指出，变现优异时要让团队指导。
  • 同意尝试容易恢复的新事物

内在激励和外在激励

• 外在激励：金钱等
• 内在激励：自主性、卓越性、目标
  • 提供学习新技能，提高已有技能的机会
  • 帮助团队成员看到从事工作的意义。

应对有害之人

巩固团队

• 制定一组有效的最佳实践和流程，巩固团队文化，不允许不良行为存在。

发现威胁

• 核心：保证团队的注意力和专注力不受到影响
• 不尊重他人的时间：不断提出自己本可以轻松找到答案的问题（如读项目基础文档），打扰整个团队。
• 自大：无法接受集体决定,不能听取、尊重相左意见,或不愿作出让步的人。（出现异议时，需要决定这件事是否需要得出结论，是否值得花时间讨论，及时做出决定止损，继续前进）
• 颐指气使：总是要求别人完成某事，总是抱怨不足，但是不给出直接帮助。
• 沟通幼稚或混乱
• 疑神疑鬼：意见不合时，抛出阴谋论。（不要对无意义的指控做出回应）
• 完美主义

去除毒瘤

• 核心：关注如何消除行为，而非驱逐人。
• 引导完美主义者的能量：原有的问题一旦得到可行的解决方案,就应当将完美主义者的注意力引导到另一个需要解决的问题。
• 不要喂食能量生物：对挑衅或捣乱保持沉默，节约自己的时间和能量
• 不要过于情绪化：你的工作是创造伟大的事物,而不是安抚每位来访者或不断证明自己的存在合理。请仔细选择哪些挑战值得回应,并时刻保持冷静;谨慎判定何人值得回复,何人应当无视。
• 在愤怒中寻找事实：仔细聆听他人的抱怨。
• 以德报怨
• 放眼未来：如果处理有害行为和当前局势有冲突，则进行如下考虑：
  • 抛开团队注意力和精力的短期损失,就长远来说,你确实相信 项目将受益吗?
  • 你相信这个冲突最终会以一种有益的方式解决吗?
  • 如果如上两个有一个为否，则需要出手干预有害行为的停止。为了短期效益而损害团队文化是不值得的。

组织操控的艺术

• 核心：理解如何在良好或不佳的公司中工作

理想团队运作模式

• 有一位服务型的经理，遵循HRT原则，真心实意想要帮助团员成功。
• 团员在完成本职工作后会寻求更多职责，离开舒适区，尝试新事物
• 可以承担风险，并且不惧失败；勇于承担失败的责任，并记录下失败的过程，防止失败再一次发生。
• 信任团队成员，一起承担责任。
• 对不确定的东西，任何人都可以自由的提出疑问。
• 及时向领导者汇报工作进度，以及遇到的问题。

失败团队运作模式

• 有不称职的经理：
  • 害怕失败，不愿意冒险
  • 藏匿信息，不让组员接受信息，以确保自己可以参与所有活动，维持权利
  • 夺取团队成员功劳，不关心团员职业发展，团队的幸福度。
• 存在办公室政治家：整天作出有影响的样子,而不是实际产生影响的人。
• 管理不当的组织：
  • 工程师只是完成需求的工具，被安排不合理的工期项目等。
  • 指挥和控制结构僵化，解决问题效率低
  • 权利争斗
  • 公司或团队缺少目标，方向

尝试操控组织

• 基本理念：承认事情现状，探索公司结构，寻找可以完成工作的机制，为自己打造一个安逸的位置。
• 了解公司允许什么行为，在允许范围内，做对公司有益的事。最好提前和信任的人获取意见进行参考，同时确保自己失败后可以被原谅。
• 提供说服别人的成功率的方法是找几个支持你的人。
• 找到好的习惯去替换坏习惯，可以尝试通过试用来克服大家的惰性。
• 学会向上管理
  • 确保自己的经理和团队外的人知道你在做什么，而且做得很好。
  • 不要承诺无法完成的事情。
  • 推出产品应该放在首位
• 运气和人情经济：帮助别人完成不是自己分内的工作，增加自己的政治资本。
• 晋升到一个安全的职位：层级越高，越能掌握自己在公司的命运。
• 寻找有影响力的朋友：熟知公司人际的联系人，老员工，行政助理。
• 注意写信找高管帮忙的方式：
  • 邮件越短越容易回复
  • 优秀邮件应最多包 含三条要点说明当前的问题,以及一个——只有一个——行为召唤。
  • 要点和召唤应该简洁，且容易让对方回复（答案简洁）
  • 细节和背景信息可以考虑附在邮件的最后。

撤退

• 如果无法改变，那不要耗着，直接离职。

关注用户

核心：合作不限于团队,要创造优秀的产品,你还需要积极地与用户合作。

管理公共认知：

• 注意市场营销
• 注意用户对产品的第一印象
• 少许诺多提交

关注软件的可用性

• 对技术人员合理的界面，技术盲可能会抓狂。需要关注用户。
• 选择听众：想象可接受产品的用户的技术能力范围。可接受的用户的能力范围越广，则产品拥有的用户量也就越多。
• 考虑进入壁垒：让用户容易地进行初次尝试。使用产品的最初一分钟的体验至关重要。
• 衡量使用量而非用户数。

设计的重要性

• 核心：以用户为先进行设计，影藏复杂性，提高产品速度，不要一枚求全。
• 用户为先：应当在产品开发中付出一切努力,令用户使用产品更容易。
• 注意应用速度：不要浪费用户的时间！降低延迟是提高使用量，保持用户满意度。
• 切勿求全：少即是多。
• 影藏复杂性：优雅的设计能轻易地完成简单工作,又提供完成困难工作的可能。即使在完成复杂工作时,你的软件也应当显得无缝而容易使用。(再次强调,我们关注的是用户的感受。)对于一个复杂问题,将其分解,隐藏起来,或者用其他方法使软件看起来很简单。

管理与用户的关系

• 倾听用户，关注用户
• 主动联系用户
• 尊重用户的智商，作为计算机用户的能力并不能代表一个人的整体智慧程度。
• 保持耐心。
• 学会倾听。学会理解人们想说的是什么,而不一定要试图解释他们实际说的是什么。
• 保护同时增进用户对我们的信任。
• 编写软件是为了令用户的生活更轻松。

部分摘抄

• 工作可分为“进攻性”和“防御性”。进攻性工作通常是新用户可见的功能——容易 展示给外人并使大家兴奋的漂亮东西,或者是可以提高产品吸引力的可见改进，防御性工作针对的是产品的长期健康。团队花在防御性工作上的时间不应超过全部工作时间的三分之一到二分之一。