《软件人才管理的艺术》笔记

这是一本很有趣的书！虽然我无法认同作者的很多观点，但是毫无异议的是：他的观点很有启发性。作者的视角和论点覆盖了大部分技术管理者面临的问题，让你从“人”的角度考虑如何进行技术人员的管理。（原书的英文名就是 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: 检查组织中是否存在耗费大量人工、没有直接的产出但又不得不做的事情，把它们自动化。

----------------------------------------读书笔记------------------------------------------

第十八章：状态报告2.0
当公司发展到一定规模后，公司内将形成很多小团体，早期的高效沟通将仅存在这些小团体内部。不同的团队之间相互不了解，也缺乏慾望和动机去了解对方。
使用开放给所有人的 Wiki 或类似系统来发布消息和状态报告。
同时依然要準备面向高层的传统报告。
TODO: 寻找合适的摘要工具，自动生成原始的状态报告。
第十九章：涓滴理论
这是每个人都知道但每个人都忽略的道理，感谢作者的再次提醒。
对付不可能的任务，第一步就是开始做。
一旦开始做某件事，很快迭代就会变得容易。
当自己厌烦的时候，停下来做些其它事情。
要事前预测做一件事的时间，几乎是不可能的。在实际动手之前，人们的估计往往不靠谱。
TODO: 看看有哪些一直拖着没做的事情，开个头
TODO: 重啟 EBS
第二十章：扫视与亮点
在简歷裡强调你的（深度）工作经歷和描述，提及你的业餘活动。
使用关键字以符合搜索引擎的需要。
设计自己的格式，追求差异化。
说人话。
第二十一章：电话面试
要能和面试官进行沟通。
问深思熟虑的问题。
第二十二章：九十天
放鬆！在开始的试用期裡放鬆和倾听，不要為自己不知道的事情发愁。只有当你不再过度谨慎时，团队才会接纳并信任你。
了解你的同事，他们工作的安排是怎麼样的，业餘呢？
和同事共进午餐。
问问题。
加入同事的社交圈。
了解在这个团队中如何影响别人，如何进行争论。
找到你的圈子。
我的问题是过分放鬆，找到工作不代表能通过试用期，要适度的警觉。研究周围的人。
CHECKLIST: 试用期
弄到组织结构图
每个部门和你的关係是
紧密吗？
谁是主导？
每个部门和你对接的是谁
你的同事（领导、下属、平级）属於什麼样的人
有机的/机械的
内向型/外向型/整体型
完美主义者/渐进主义者
费兹/自由电子/其它
他们对你有什麼诉求
和你的同事安排社交日程
午餐
週末聚会
他们的兴趣列表
找到你的支持者
管理层的
技术方面的
文化导师
战略/战术助手
趣味相投者
第二十叁章：领头人
招聘很难，要找关键人员来协助你判断：技术/（团队、公司）文化/（战略/战术）愿景。
召开面试反馈会，了解大家对应聘者的反应和意见。
第二十四章：NADD & 第二十五章：洞穴裡的书呆子
这两章仅供非书呆子阅读，有了叁十年的穴居经验，我可不需要作者来告诉我啥叫书呆子。
第二十六章：会议生物
要确保在会议召开前识别出拍板人，确保他出席，并确保他知道自己就是拍板人。真正的拍板人有时会隐藏在会议人员中，由假冒的拍板人表演。
观察是否有人不能积极参加讨论。可能是会议确实与他无关。无论如何，避免这样的情况，因為这是负產出。
如果发现有人无助於会议进程却始终参加，搞清楚他的目的。
确保发言者的信噪比足够高，如果有人习惯於喋喋不休，用简单的、封闭式的问题提问。不要和他争执，情绪会使这类人更加失控。
翻译家：尽量保证有人能了解与会人员使用的全部“方言”
合成大师：尽量保证有人能深刻理解会议的核心内容。当这个人就是拍板人时，他可能会过度掌控会议。
有人习惯於用与会人员都无法理解的语句发言，要确保翻译家/合成大师的在场。如果他就是拍板人，务必要谨慎理解他的意思。
TODO: 找出你团队中的翻译家和合成大师，没有的话要培养。自己也要能够翻译和合成。
第二十七章：渐进主义者与完美主义者
渐进主义和完美主义的对决是正确对正确的战斗，因而也格外荒谬。
渐进主义者能够不断移动并取得进展，但忽略整体目标，缺乏远见。（知道怎麼做，不晓得做啥）
完美主义者具备战略眼光，但不知道从何入手，通常也缺乏沟通和交际能力。（晓得做啥，不知道怎麼做）
了解周围的人属於哪个类型，制订相应的沟通方法。
TODO: 对於完美主义者（我），每次在思考前定下期限，不要陷在无止境的高空飞行上。
第二十八章：有机主义者和机械主义者
机械管理者以结构化的方式收集信心，他们不擅长人际关係，缺乏灵感，但能建立健康可靠的环境。要把信息井井有条的匯报给他。有机管理者习惯一对一的谈话，并不断转换问题，他们可能会丢失细节，容易陷入混乱，要利用他们的直觉和热情。
尝试成為一个有机的机械主义者：学习社交和沟通，学会观察人。
TODO: 寻找一个有机主义者，模仿他，让他指导你。
第二十九章：内向型、外向型和整体型
内向型管理者关注自己的团队和產品，除非依赖到其他团队，一般不会涉及跨职能部门。（通常是初级管理者）
整体型管理者关注整个组织，主要工作是弄清组织其它部分在发生什麼事情，涉及大量的信息採集。整体管理者下一般有至少一级的管理者负责具体的產品。他们让公司真正运转。
外向型管理者关注外部世界，关心公司的公眾形象，关心和客户、金融界乃至全世界的关係。
每个管理者都有两个头衔：组织赋予他们的和自己认為的。
要经常注意自己和自己的下属及领导实际头衔和内心头衔的状况和差距，要及时纠正不切实际的认识或是消极的作风。要把眼光从内部逐渐向外延伸。
CHECKLIST: 关注点
列举自己的岗位属於哪个级别
级别
组织期望你关注的东西
你是否準备好进阶了
反思自己觉得正在做的事情是哪个级别的
你正在关注哪些东西
会影响你的业绩吗
能推动你的进步吗
第叁十章：自由电子
自由电子有两个版本：初级版和资深版，区别在於是否懂得政治和交际。
保证给自由电子充实的工作：多数技术人“想”呆在技术尖端；自由电子则是“必须”。
自由电子倾向於过度发挥，因此要正确使用他们。
自由电子执着於自己的看法，不屑於和你解释太多。这时：不行动就是最好的行动。
赶快高声呼叫：我要变成自由电子……我要引发核爆炸！
第叁十一章：组织结构调整的应对法则
组织调整不是裁员，裁员可能是组成部分，但只是附带效果。
调整可以让组织富於可塑性，管理者倾向於认為：我们应该顺便解决某问题，反正总会混乱的。
通常你的领导也不确定将要发生什麼。
调整需要的时间远远超过你的想像。
多数人喜欢机构调整（但不愿承认）。
第叁十二章：海外外包风险度 & 第叁十叁章：乔
在流程和產品之间，优先选择產品。伟大的產品足以掩盖流程的愚蠢。
你无法外包创造性、热情和思想
好吧，我曾经参加过一次涉及外包的工作。我们的开发者位於斯里兰卡和香港，远程的交流令人困惑和痛苦，最后马马虎虎解决问题的是一打飞机票。到目前為止，我还很难想像创造性的工作如何能够进行外包。
第叁十四章：秘密头衔
微观管理通常导致下属的不信任。
不要用微观管理的方式试图去影响新人，让他们自由成长。
被微观管理的时候，弄清他们的“实际需求”（渴望回归技术细节？怀念编程年代？觉得大家认為他不懂產品？），解决这些需求。
词汇表：
Contractor: 合同工，就是貌似永远不走的临时工
Individual Contributor: 人力资源术语，指没有（真正的）直接上级的单个员工。通常是纯专业人员。
MRD - Marketing Requirements Document: 杜撰的、用於假设客户需求的文档
NIH - Not Invented Here: 外来代码必须进行审核或重写，往往造成巨大浪费
Short Timer: 已经辞职，但还在工作的员工。其效率会每天不断下降。
Technical Support: 那个当你的电脑宕机时指派来被你骂的人