《软件人才管理的艺术》读书笔记（上）

这是一本很有趣的书！虽然我无法认同作者的很多观点，但是毫无异议的是：他的观点很有启发性。作者的视角和论点覆盖了大部分技术管理者面临的问题，让你从“人”的角度考虑如何进行技术人员的管理。（原书的英文名就是 Managing Humans）

这同样是一本很轻松的书，大可以“随便翻翻”的方式阅读。但是由于原书是由博客文章整理而成，所以整体编排和结构还是有些混乱。前边的文章用到很多在后半本书才出现的名词定义，以至于翻阅时有些小小的不便。另一个后果是同一个思想会出现在不同的章节，很多时候，作者会重复的说着同一个道理。

至于翻译，风格蛮自然的，大部分都能符合我的要求（这个不容易）。但也有极少数地方实在不知所云的。

第一章：别当鸟人

管理者要和下属建立联系……要看到他们的微妙差异。与你工作的每个人都有不同的诉求，满足他们的诉求才是激发生产力的有效方式。

你的团队负责代码、测试和文档之类的鸟事，你的工作焦点则在你的团队身上。

组织是由人构成的，总在不断变化，而且难以置信的混乱。因此，彼此的评价会在很短时间内进行，哪怕是走廊里的匆匆谈话，也会改变别人对你的评价。

人复杂、不稳定且情绪化，特定的激励技巧在两个月后就会失效。

作为技术人，通常我们被教育要写富有逻辑性的、稳定的、正交的代码。其后果是很多呆伯特想当然的认为人也应当是并且就是固定的东西。但事实是：不但女人很善变，只要是人都很善变！因此作为管理者必须时时刻刻打开他的任务管理器，检查每个周围的人处于什么状态，他们需要些什么？至于绩效考核表……和以前一样，我依然认为那属于史前文明的技巧。

TODO：把工作涉及的人列举出来，按照相关度安排周期性的沟通，了解他们的需求和状态。

第二章：管理者不是坏人

不同的岗位间其实有各自的语言，因此理解他人的工作非常的困难。这也是为什么大家往往认为彼此“无所事事”的原因。

用简单的语言向你的领导讲解你的工作，让他（在别的地方）有（关于你的）话可说。

“我无懈可击”是种可怕的信号，要么是你的缺点已经大到你不想提及，要么你根本不知道自己的缺点。

管理者的工作，就是充分利用下属已有的技能，并提高他们的技能。要构建一支能强化优势，更能弥补彼此不足的团队。

当你向老板汇报时，你面对的不是个人（不管他是你的哥们还是死敌），而是组织。

要把话说得有艺术性，但是，不要过多运用“管理语言”（官腔）。

要周期性（固定或是习惯性而且频繁的）进行面对面的沟通，沟通的时候要积极搜索信息。

作出决定后要跟进。管理者的工作要能支撑他们的目标。

了解各自在政治食物链中的位置。

管理者的工作包括正方双向的从一个层翻译到另外一个层，他需要知道：1. 他的领导有什么需求，他的员工有什么需求；2. 二者需求存在差异时要怎么引导。

角色、位置、需要！

TODO：列举你自己和周围人的优点、缺点，进行排序并提出后续手段（巩固、改进）

第三章：周一情绪爆发

最糟糕的情绪失控是完全无理智的，没有解决的办法——因为找不到具体要解决的问题，仅仅是需要发泄而已。面对这类失控：要平静。

无论如何，一个人失控是有原因的。找到这个原因，用问题将失控这扭转回理智状态。

失控者爆发前一定长时间考虑过相关的问题，即便失控，他们的看法仍然可能比你更有深度。

爆发意味着这个员工依然在寻找积极的解决方法，但也意味着：1. 你有问题要去解决；2. 因为某些原因，人们认为引起你注意的最佳方式是情绪爆发！

嗯，在中国，我们的文化可能会导致员工选择沉默而不是爆发，这意味着需要更加细致的观察。关键在于，了解你下属的需要！

第四章：议程侦测

也许是书中最有启发的部分。

通报会就是讲话人说，听众听。不要像那些二百五一样，希望仅仅提些随机的问题来改变会议的决定，即便你是出于高尚的原因，那也将是浪费（大家的）时间。

会议的对弈者想要得到某种结果；道具卒则仅仅为了会议的运作而存在，对会议的结果不感兴趣也没有实际影响。对于对弈者而言，赞成方是既得利益者，不需要被迫协商妥协，甚至不需参加会议；反对方则是那些当前利益受损者，通常会表现出某种程度的怒气。

为了使会议有所收获，必须使赞成方加入到会议中。

赞成方并不需要会议，他们总想尽快结束会议。因此，有时他们会伪装成反对方。

必须有一个计划、一个解决会议议题的保证给到反对方才能结束会议，否则将是更多接连不断的愚蠢的会议。

要弄清会议的主题。

很多会议只是充满二百五的通报会，或者是只有反对者和道具卒的诉苦会。而剩下的少部分还有很多因为没有厘清会议主题而失败。在读这本书之前，我们通常认为开好一个会最重要的是流程，往往会忽略会议角色的问题。

CHECKLIST: 通报会

• 记录通报者
• 记录听众
• 记录通报内容
• 列举议题
  • 列举议题对自己的影响
  • 列举自己的应对措施
  • 列举议题对其它组织的影响

CHECKLIST: 冲突调解会

• 列举议题
  • 内容
  • 重要程度
  • 你的观点
  • 当前的状况
  • 可选的方案
• 识别议题对应的赞成方
  • 在组织中的地位和影响
  • 他们对议题的看法
  • 有没有伪装成反对方的赞成方，为什么他们要伪装
• 确保（有权拍板的）赞成方出席
• 识别议题对应的反对方
• 识别“道具卒”
• 列出反对方的诉求和理由，与现状进行对比
• 会议是否针对诉求提出了方案（或否决）
  • 观点
  • 实施步骤
  • 实施人
  • 预计的效果
  • 审核者
• 罗列方案对赞成方和反对方的影响
• 方案是否以明确的方式告知了反对方并达成（至少是暂时的）一致
• 谁、如何跟踪、通报这些方案的实际影响
• 谁、如何最终确定并宣布调解会的方案成功或失败

第五章：命令剖析

下达命令往往使人觉得：“闭嘴，去执行，我可不管你在想什么。”，这会减低下属对管理者的信任。

当大家不是为了事实而争论，而是做意气之争时，要使用命令。如果争论收效甚微，就应该做出决断。

作出决定前，让团队进行充分考虑。缓慢的决定更可能是高质量的决定。同时，协作式管理风格使决定看起来管理者不是作出决断，更像是转达团队共同研究的结果。

命令下达后，会有获益方、利益受损者和“沉默的大多数”三种人群。前两者需要进行再次传达来强化你的命令，向他们进一步单独陈述你的理由，并给他们单独表示自己意见的机会，让他们发泄出来。

如果你和受损方进行再次传达时他们仅仅是不断点头，那说明他们还没有死心，正在考虑如何削弱你的命令。

在向你的下属传达外部指令时，要向他们解释裁定理由。

在 IT 部门中，往往每个员工都具有独当一面的实力，作为领导不可能在任何方面都比下属高明。因此，他们作出的决断往往面临这传统产业中所没有的挑战……不过我认为在流水线上“闭嘴，去执行”不会有什么问题，在军队里，则更应该“不解释”。

第六章：信息饥饿

下属找他们的管理者谈问题前会很犹豫，作为管理者，要找出那个“久久凝视/徘徊”的人。

人们如果缺少信息就会自己制造，大家会根据背景知识来制造“事实”，因此：1. 大家会制造、传播谣言；2. 信息真空带会被传言所填补。

人们在缺少信息时，可能会编造一个很荒唐的结局，不是为了告诉自己或别人这个结局将会发生，而仅仅是为了获取信息拥有者的注意。

普遍的问题是：1. 忘了转达某些信息；2. 错误的认为某人需要/不需要某条信息；3. 以含糊的方式传递信息。

主动沉默：为了知道团队的真实想法，试试闭上你的嘴，听听他们在你没有提出意见前会说些什么。

仔细思考你的下属是否处于需要信息的状态。

第七章：细致、策略和沉默

管理的组成部分之一是在复杂的政治丛林中寻找出路；管理的内容之一是让下属舒服的屈身于不舒服的方向中。

细致：在管理中到达战术层面的细节，不要停留在高空。要谦虚、谨慎的考虑，避免闪电决策。

策略：为了达到正确的目的，可以使用迂回的手段来完成。但要小心失去支持者的完全信任。

沉默：让别人说，在沉默中思考他的需求，弄清他们的观点。

分清职场和战场，对权力的迷恋将导致溃败。

第八章：管理语言

过度使用管理语言意味着“你不知道你在说什么”，将直接导致你失去他人的信任。

管理语言有其合理性，对于“讲同样语言”的人而言意味着更高的带宽。

对下属使用太多管理语言，他们的第一反应将是：领导在讲话。后果则是你的意思并没有清楚直白的传递下去。

TODO: 检查自己的用词，去掉不必要的术语和管理词汇。

第九章：专业性

唯一不变的是变化，唯一要保持的姿态是灵活。

可以不写代码，但不可以不会写代码。

要能够真正懂得你负责的产品的架构。

大家都记得那个卖汽水的吗？管理技术团队，没有技术你就一无所有。

第十章：避免出现费兹

让你的下属保持竞争优势。但不要让业务依赖于他们的知识黑匣子。

不断记录下属的表现，综合的判断他们在技能的高低和意愿的强弱。技能和意愿往往以正反馈的方式互相影响。

在传达复杂而可能导致反弹的消息时，分两步传达：1. 宣布面临事实，但不宣布这些事实对下属个人的影响；2. 宣布对个人的影响（奖金、晋升等），讨论如何解决问题。

不要让你自己变成费兹，否则你的领导会一点点的看着你堕落并一点点把你剥离出去。

如果你是空降的新任领导，很可能会遭遇有个性的费兹，争取他们或者辞退他们。要小心被他们要挟，记住他们可能确实会在你上任后突然辞职留下一个无法解决的烂摊子。因此，作为空降兵，要迅速识别出哪里有他们的黑匣子、谁能破解它。

CHECKLIST: 黑匣子识别

• 列举下属的工作范围
• 列举每项工作的技能需求和需要的上手时间
• 列举每项工作的后备人员
• 指定针对不同工作的培训流程

第十一章：辞职注意事项

在任何时候都不要承诺你办不到的事。除非你想沦为那种三流的销售或是有志于在政界一展身手。

重视你的人际网络，至少找出三个你希望保持联系的人，并让他们知道这一点。

识别出你希望未来在别的场合合作的同事名单，和他们保持联系。

为你的下属做好安排（比如推荐或考核）。

不要出于内疚而在离职后做义工。

你的离开将对团队造成伤害，对此你无能为力。因此不要过度宣扬。

TODO: 重组你的联系人列表，安排周期性的联络日程

第十二章：说“不”

当明知领导发布错误的指令而没有说“不”时，你其实就是同谋。

无人质疑将导致管理者失控。当团队不再质疑权威后，管理者会产生自己永远是对的这样的错觉。

针对目标思考，而不是想着如何取悦领导。

第十三章：1.0

Fucked Company: 专门记录互联网泡沫中倒闭公司的网站（可以订阅 email，或想办法在 Facebook 和 twitter 上跟踪）

要抓紧时间！没有产品就没有公司。在越低的层次失败代价越高：如果创意/构想失败，那么什么都完了。

创业团队几乎都会失败，所以要快速实现，不能纠结在太遥远的目标上。

同样，不要当太空架构师，你无法预见未来，所以也不应该过于纠结于满足未来的一切需求。在需要速度的场合，先上车，后买票。

第十四章：花时间思考

要能够对问题进行本能的反应，否则你不能成为成功的管理者；但更要依赖理性的思考，否则你无法进行合理的创造。

尝试每周安排一个头脑风暴和对应的原型开发会议。前者利用发散思维找出新的想法。后者利用结构化思维对想法进行验证和实验。

识别并排除蓄意阻挠者。有些人会因为思维定势或对新事物的恐惧习惯性的唱反调，纠正他们。

至少在会议上紧盯一个有难度的问题并作出决策。

悲剧可能会出现，它和真理的发现相仿，但动静更大。它有很大的破坏性，但也是敏捷过程的显著标志。

控制会议产生的代办事项列表规模。

CHECKLIST: 每周会议

• 是否每个人都积极参与了头脑风暴，鼓励他们
• 头脑风暴的产物
  • 想法的描述
  • 重要性
  • 谁来验证原型
• 原型开发
  • 可行性
  • 如果可行，那么预计的成本是多少

第十五章：浸泡式思考

主动收集信息，了解它们，并尝试描述它们；找到描述不清的部分，进行迭代，直到能足够清晰的向他人进行解释；停下信息收集，进行长时间的思考（包括被动的无意识思考）。

TODO: 尝试用日志的形式对必须掌握的知识进行书面描述。

第十六章：Malcolm 事件

蝴蝶效应使得很多小事会对事情的发展造成不可思议的影响。

要避免 Malcolm 事件，要注意可用性、达成共识并精确的进行描述。

失败的动静会很大，而成功往往悄无声息。而管理，就是对不可见事物的关注和应对。

CHECKLIST: 避免 Malcolm 事件

• 是否有（不同的）人反复在提同样的问题？通常这预示着危险，你需要精确的描述他们，并告诉所有人。
• 定期检查下属的工作，确保他们做的就是你说的。
• 定期和别的组织沟通，确保对于同一件事大家的理解是一样的。
• 记录每个确实发生的 Malcolm 事件，把它列入检查清单。

第十七章：背景抓取

不同的组织会依赖于不同的工具。要针对你的环境用合理的工具把低价值的行政工作自动化，比如注解和状态报告。

TODO: 检查组织中是否存在耗费大量人工、没有直接的产出但又不得不做的事情，把它们自动化。