构建之法 17 章 人，绩效和职业道德
(<构建之法> 第三版草稿)
2016/12/23
17.1 领导力
在软件开发过程中，有很多平等合作，但是也有上下之分的领导/被领导关系，即使都是平级的员工之间，也有老师傅/新人，某领域的专家/新手之间的指导关系。
在口语中，很多人认为领导就是管人的，名称大概是经理。很多技术人员在展望将来的职业发展的时候，说“我以后想做管人的”。其实，领导（leader）和经理（manager） 是有区别的，计算机行业的先驱 Grace Hopper 说过：
You manage things, you lead people. We went overboard on management and forgot about leadership.
你管理事务，你带领团队。我们过分重视了“管理“ 而忘记了”领导“。
请读者看你所在机构的那些 "管人的领导"， 他们擅长的是把人当作东西来管理，还是领导大家达成团队的目标？
所谓“领导”也有很多种：
Thought leadership：思想的上领先
Technical leadership：技术上的领先和指导
Organizational leadership：在机构里是领导关系，又如学校里的老师
Project Leadership: 在一个项目中是领导
一个人可以是自己的领导： 一个有雄心壮志，有紧迫感，有纪律的“我”，领导一个灰心丧气，有拖延症，得过且过的“我”。每年，每学期，每天的开始，一个人似乎展现很多对自己的“领导” 特性，但是随着时光流逝，领导力在慢慢丧失，直到下一次觉醒。
在软件团队的语境中，领导力有几个要素：
- 设定目标
- 知人善任
- 带领团队解决问题
- 绩效管理
设定目标这个要素在其他章节有不少描述。 简要地说，好的目标有下面的特点SMART：
Specific：具体的，无二义性的，能描述 “成功” 是什么样的。
Motivating: 目标能激发团队成员对目标的兴趣么？实现目标对团队成员来说意味着什么？他们会为之自豪么？
Achievable: 能做到么？是挟泰山以超北海？还是把墙角一堆砖头搬走？
Relevant: 和大团队的方向、目标吻合
Trackable: 能衡量进度的，和有些资料提到的 Measurable 相似。
下面的章节分别讲述其他的要素
17.2 领导力– 知人善任
我们在前面谈了很多个人技能的成长，两人如何合作，各个角色如何协作，等。团队中还有领导／被领导的关系，处于领导地位的人，如何吸引合适的人才加入团队，如何让成员成长？领导者的最基本能力，就是要能知人。
世界上能够加入你的团队的人成千上万，你怎么找到最合适的人呢？我们先把人分类，希望能分而知之，用之。分类的方法也有很多种，例如有从人的生日和星座，血型来分类；也有的根据人的性格，认识世界的方法，做决定的方法来分类，例如MBTI。根据作者本人的观察，MBTI的一个子类型 INTJ (心理偏于内向 - Introvert，认识世界的方法偏于直觉 - INtuition，做决定的方式偏于理性 - Thinking，处事态度偏于有序 - Judging) 在软件工程师中所占的比例远远大于在普通人群中所占的比率。 另外还有其他理论用各种颜色来表示不同类型的偏好组合（例如：温暖型的黄色，冷静分析的蓝色，大地一样包容的绿色和火热的红色），一个具体的人会有主导地位的特征和次要地位的特征[XZ1] 。
流行的众多分类方法有不同程度的科学性。对于职业人士来说，这些分类少了一样维度的信息：这个人的技能如何？
例如，你看上了一个人， 他的MBTI是你最喜欢的，他的主流颜色也是你最中意的，那他能帮你重新设计你的网页么？ 那要看他有没有相关的技能。 你喜欢一个医生团队，他们细致，对用户负责，富有合作精神，坚持学习，但是他们能马上开发一个手机App 么？
一个新人加入一个团队，团队领导看重了什么呢？首先是知识。
知识是有用的，它能帮助我们了解事物，但是要解决实际问题，我们需要技能。一个人对某个领域可能能有知识，但是未必有技能。一个大学生，从来没有骑过摩托车，看了《禅和摩托车维修》这本书，对于禅和摩托车维修都获得了一定的知识，但是要到一个摩托车修理厂工作，她的知识是远远不够的，她也没有任何相关的技能。小说《天龙八部》里的人物王语嫣对于武功的知识了解非常多，但是实战的武功技能也几乎没有。有知识但无技能的人，是否一定是“行走的书橱”，没有大用？那也未必，20世纪的传奇游泳教练谢尔蒙查威尔（Sherm Chavoor） 培养出了一批世界级的优秀游泳选手，他的运动员一共获得了31枚奥运奖牌。他的 “竞技游泳知识”应该是非常多，但是大家几乎没有看到他下水游泳，有传说他不会游泳。这么说，他的 “竞技游泳技能” 是很低的，但是这没有妨碍他领导他的游泳队取得世界级的成功。
领导看重新人的另一点，是专业技能和职业技能。每一个进入职场的人士都有一些专业技能，即和所处专业密切密切相关的技能，大家在学校里面各种专业学到的（医疗，法律，数据库技术，软件开发等）。职业技能指的是职业人士需要的软技能，如交流能力，自我管理能力，快速学习能力，处理复杂问题的能力，平衡工作生活的能力，等。一个项目需要的是“可用的专业技能”，一个有丰富懂金融业经历的人士，在上一个银行相关的数据库项目中发挥了她的专业技能，但是在下一个社交网络App项目中，她在项目中的“可用技能”并不多。但是她的职业技能还是可以继续发挥作用。
领导看重的还有一点，是投入程度。招来一个新人，但是她不喜欢目前的项目，兴趣不高，也不想学习，也不打算在团队呆很久，怎么办？无论她能力如何，这样的人加入团队有好处么？
总结一下，领导需要了解一个人的：
- 知识，专业技能，职业技能，这三者合起来可以称为“能力”（Competence）
- 投入程度，热情，对团队目标的承诺，这可以称为“动力”（Motivation），动力低的人，不管能力高低，他们对团队的贡献是非常有限的。
我们可以根据这二者的高和低，把团队成员分为四个象限：
一个班级的同学开始学习软件工程这门课, 几个大学毕业生加入公司的软件团队, 她们会怎么发展呢？团队新来了四位新成员，小飞，果冻，荔荔，和九条，他们都是从移山软件学院毕业的，雄心勃勃地要在移山公司大干一场，改变世界。他们都从（低能力，高动力）的象限出发了。我们可以看到几种轨迹：
- 果冻在学校只写了几百行代码就毕业了，他兴致勃勃地参加了第一个项目，由于能力太差，加上项目工期比较赶，他一直没有得到什么独立工作的锻炼机会。于是他又参加了第二个项目，做了一段时间项目取消了，他负责的模块也没有发布。他在找第下一个项目，但是各个项目的领导都表示没有什么合适的地方。领导建议他从测试入手，他不太乐意，他不理解测试工作的意义，也不想理解。果冻觉得这个公司不适合他，抱怨了几次公司的方向不对，流程不符合软件工程的原理之后，他走了。
- 九条和果冻类似，但是他经常加班学习，终于在项目中掌握了一定的行业知识和软件开发技能，成为这个项目的技术能手。但是他渐渐不太看好这类项目，想去做更加主流的项目，但是他不知道怎么才能离开这个旧项目，领导觉得他就应该好好呆在这个项目中，继续工作。后来九条找了一个机会跳槽到别的公司了。
- 荔荔刚开始工作碰到许多难题，每天都要问人，每天回到宿舍都很晚，刚来团队时候的心气渐渐没了。经过几个月的努力，她才站住脚，能独立完成份内的工作，后来她接手了两个离职同事的领域，慢慢琢磨出门道，逐渐从对整个系统都有了解，都能完成任务，一年后，她就开始带新来的员工了。新员工向她请教的时候都是羡慕崇拜的样子，像螺旋发展的轨迹，她经历了四，三，二，一象限，又到了一个新层次的第四象限（低能力，高动力）象限，她感觉能力不足，觉得自己不懂的太多了，每天忙着给自己充电。但是更自信，动力更足了。
下面的三个轨迹勾勒了三个人的不同发展路径：
当然还有其它的轨迹，例如小飞，他在学校就做了很多项目，也在公司实习过，所以上手很快，搞定了第一个项目，他又参加了新的项目并且也得心应手。
处于不同象限的人，心理不一样，贡献不一样，对领导的期望也不一样，领导不能千篇一律地跟他们说“请加油吧”，或者“和大家打成一片”就能解决问题的。领导自己还有自己的工作，也不可能花很多时间陪伴所有人，要选择合适的时机，对不同人施以不同的引导。
第四象限：积极的初学者
- 能力：对于这个任务不太了解；没有经验；“我都不知道我不知道啥”
- 动力：很想学习，充满好奇心，热情，对于自己的可转化技能充满信心，觉得学习新技能也不是太难，处于一种无知的乐观( Uninformed Optimism) 状态
领导应该做的：
- 能力方面的帮助：肯定他们带来的可转化技能。 要替他们设置SMART 目标、优先级和检查点，循序渐进的学习计划；要定义她们在团队中的角色和范围，限制自主性发挥；提供资料让他们学习，例如：展现实际的例子和模板、已有的解决方案；提供练习机会，或者一对一的指导（mentor）；
- 动力方面的帮助：帮他们在心理上为即将到来的困难做准备。
- 检查和反馈：经常检查，给予大量的反馈。
第三象限：迷惑的学习者
- 能力：有一定的知识和技能，但是没有达到胜任这一地步，不知道如何前进；表现和进步并不是一贯优秀
- 动力：有受挫感，有放弃的念头；任务太多处理不过来，没有动力；害怕犯错误，迷惑、担心。可以说处于知情的悲观(Informed Pessimism) 状态.
领导应该做的：
- 能力方面的帮助：更加明确的目标/角色的定义；需要提供机会能学习和提高技能，理解工作中的“为什么”。
- 动力方面的帮助：倾听他们的忧虑，分析他们的处境（处于这个位置，并不是你的错）和前因后果。
- 检查和反馈：用当初的SMART 目标衡量员工已经取得的进步；认可员工的工作，保证不放弃员工，鼓励他们不要放弃自己。
第二象限：不爽的贡献者
- 能力：有经验，通过实际成果证明了能力，给项目做出了实际的贡献。
- 动力：有时犹豫不决，并不是非常自信，有时觉得工作无聊或者对工作无任何感情。在这个时候，如果没有适当的指导，会出现价值危机 （Crisis of Meaning）: 我在这个团队的价值是什么? 我为何这么辛苦地干活?
领导应该做的:
- 能力方面的帮助：让他们在拿手的领域发挥更多作用，让他在拿手的领域做得更完善，并增加交流的机会（代码复审，设计复审）。
- 动力方面的帮助：倾听员工的看法和担忧，需要认可成绩；同时要让目标更有挑战性一些；鼓励她在拿手的领域自主发挥。
- 检查和反馈：员工自己可以定义SMART 目标，和领导商定检查的节奏。
第一象限：自立，取得成就的人
- 能力：一段时间以来不断取得成绩，公认是某领域的专家
- 动力：自立自主，有充分的理由展现自信，同时能激励其他同事。达到了知情的乐观（Informed Optimism）状态。
领导应该做的：
- 能力方面的帮助：要求他们在相关领域做更多的学习和创新。
- 动力方面的帮助：认可并重视他们的贡献，放手让他们发挥。
- 需要：信任和自主权；需要得到成长的机会、需要展现自己创造性的机会，能指导别人的机会；需要更多的资源，来发挥更大作用
- 检查和反馈：阶段性的检查，看重结果，。
不光是初学者会经历这些阶段，一个团队开展一个新项目，一个有经验的领导空降到一个机构，也会经历这些阶段，结果未必都是圆满的。
17.3 领导力 - 高效的团队讨论
移山公司的几个项目都在紧张进行中，在做了几个“事后诸葛亮会议“之后，大家发现每个人都对会议的效率不满。于是作为改进措施之一，大家看了一些”高效会议“的培训资料，然后按照资料建议的办法去开会，结果发现这些资料的建议往往是相互矛盾的，开会效率不高的问题仍然没解决，一些人还生了一肚子气。于是大家来找阿超讨论。
大家的抱怨主要在下面几个方面：
目的：开会的目的并不明确，既然是每周一次，大家按习惯每次都来，但是也没有解决什么问题。主持会议的人有时陷入对细节的争执，时间到了也没有结果，就不了了之。
要带着感情去讨论问题么？有专家建议开会应该尽量不带感情，但是别的资料又要求大家带着感情去体会用户的痛点，还要带着浪漫的幻想去做头脑风暴。
在分析问题的时候要提不同意见么？有时候你要集中注意力找到方案的漏洞，有时候却又要互相鼓励，鼓励多了被说成不痛不痒没有帮助；提意见多了又会被人说喜欢挑刺，伤感情。
直觉和详细分析的矛盾？对于一些问题，有些同事似乎早就有了结论，他们不想浪费时间讨论；同时有另外一些成员希望仔细分析。于是大家纠结于什么时候要认真分析，不断深入找到问题关键，不担心浪费时间；什么时候要快刀斩乱麻，这个快的决定往往是带感情色彩的。
阿超说:
这些培训资料上的建议都是有好处的，就像软件工程的各种模式一样，我们要找到它们的适用范围，根据它们的特点，把这些好的方法有条理地用在会议和讨论中。
一个幼稚的假设就是大家非常职业化的来开会，然后得到职业化的结果，离开会议，像这个草图一样：
实际发生的往往是下面这样：
貌似开完了会，大部分人都不满意，会议的组织者应该要负最大责任。大家时间是有限的，要在会议结束前达到目标，就要定义好目标具体是什么。组织者应该做到：
- 明确会议目的，要解决的问题是什么
- 推动会议进程，促使与会者在每一个阶段做合适的事情
- 总结会议，记录要点
会议的参加者想到哪里就说到哪里，各人的情绪也自由地发挥，虽然热闹，却是一种无序的交流，效率不高，我们应该把这些无序的活动逐步约束为有序的活动，然后让大家通过一系列的思维活动来分析问题，在一个时间段内只做一类思维活动, 决定行动。思维活动有这几种类型：
- 理清事实
事实就是客观存在的现象，可以验证并通过一些定量的指标来衡量的。事实不是可能性，例如，“我们的下一个版本很可能会吸引很多新用户”。 事实不是一个信仰，例如，“我坚信PHP 是最好的开发语言”。
在会议中，大家先把所有的事实列出来，并且把不是事实的部分撇除，例如，在会议一开始，大牛就急切地说：
我刚听说我司高级副总裁大智同志下周三要看我们的新项目，大家赶紧把原定本周做完的任务都放一下，我们奋战七天，给领导看一个新的演示！
且慢！这里的事实是什么？
1. 大智同志下周三来看新项目，这是事实么？
2. 大智同志对这个项目的期望是什么？
3. 这个项目和领导视察的关系是什么？
- 表达直觉和感情
正如本书提到【指明引用的地方】，不同的人有各自的表达方式，在太多 “我们需要事实和数据” 和 “理性分析” 的约束下, 很多人在会议上没能直接地表达情绪，这不利于充分让大家投入并分享。在会议期间，最好是在事实厘清之后，可以有几分钟让大家充分表达情绪，并且不用说明自己情绪的理由。
例如，会议的议题是：“是否把我们系统的前端实现技术全部切换到最新的vue.js[XZ2] ”
可以花几分钟时间，让所有人都自由表达情绪, 这对于会议后续进展有良好的润滑作用。这个思维活动的价值在于, 让所有人都看到其余人的情感和直觉, 这对整个团队构建互信, 包容的文化是很有帮助的。而且，由于大家都在这个时段表明态度，没有人会有“不够理性”的负担。
- 从乐观的角度分析问题
既然我们有了事实，大家也表达了情感，那我们就根据具体情况一步一步地讨论解决办法。在这个阶段，大家对别人的想法都应该给鼓励，乐观的反馈，并且逐步构造出一个解决方案。
一个要求是，对于别人的想法，我们尽可能地用 “对，而且．．．的句式来回应。例如：
小李说：我建议我们重写这个用社交网站登录的模块，因为新的需求和旧的需求差别很大，很难在老模块中
小飞说：“对，而且写了新的模块之后，可以大大提高登录的速度”
果冻说：“对，而且我们可以改进相关的模块，例如通过社交网络账号分享也可以简化很多”
… …
- 从悲观的角度分析问题
通过互相鼓励我们获得了很多好想法，这些想法都没有破绽么？未必，我们看到的天鹅都是白的，万一有一个黑天鹅怎么办？是否要提醒一下风险？在这个阶段，与会者的心态应该是越小心越好。常用的句式是“好，但是…”
“这个功能可以一键分析用户的很多内容，好，但是这里有用户隐私泄露的风险么？”
“重写这个模块可以抛掉以前的包袱，好，但是这是程序员果冻第一次用这个全新的技术，他的工程时间估计准确么？”
“这个功能依赖于兄弟团队正在做的功能，但是他们在我们功能上线之前不能交付怎么办，我们有预案么？”
- 从创意角度去分析问题
另一个角度看问题，有没有在目前套路之外的思路？
很多人认为“创意”是一种天生的才能，或者需要大智慧才可创意，其实不然。创意是一种可以后天获得并不断提高的技能。在大部分项目中，我们要做的不是“挟泰山以超北海”那样的天外飞仙式项目，而是有基础，有需求，可以逐步实现的项目。每个项目成员通过经验的累积，技术的提高，都可以有“资质”做创意。在会议上，我们可以要求每个与会者都带上一定“创意大师”的帽子[XZ3] ，大家不妨都来发挥一下创造力。从乐观角度分析问题的时候需要创意，从悲观角度分析问题的时候更需要创意，所以这个“创意角度”是附属于以上两个思维阶段的。
这样会议就变成：
总结：
平时开会讨论特别杂乱的原因是，在每个具体时段，每个人在扮演的角色不同，别人也没能理解不同人的角色和出发点。
改进的方法是：大家同时从一个角度出发分享，进行类似的思维活动，然后转到下一个角度。
设置一个“好主意停车场”，把大家临时想到的，和目前讨论主题不直接相关的，放到这个停车场中。对于提出倡议的人，要求倡议要说明谁会来做这件事情，没有执行者，那么这个倡议也就是一个空谈。
会议的结果是什么呢：
- 一些共识(consensus)，这些共识在项目当前里程碑结束之前就不必再讨论．也不允许会后再悄悄改变.
- 一些行动（action items）以及行动的负责人
- 一些好主意（side ideas）以及这些主意的负责人，把这些好主意都放在＂好主意停车场＂上面，以后时机成熟再启动这些想法.