构建之法 第三版 17 章 部分草稿

构建之法 17 章　　人，绩效和职业道德

(<构建之法> 第三版草稿)

2016/12/23

 

17.1 领导力

在软件开发过程中，有很多平等合作，但是也有上下之分的领导/被领导关系，即使都是平级的员工之间，也有老师傅/新人，某领域的专家/新手之间的指导关系。

 

所谓“领导”也有很多种：

　　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）以及这些主意的负责人，把这些好主意都放在＂好主意停车场＂上面，以后时机成熟再启动这些想法.

 

 

 

 [XZ1]这里加一个尾注：作者作为被测对象，曾经参与过几十人的调查，其中有一个十几人的科研团队，虽然每个人的性格，毕业学校不同，研究方向也不一致，但是统计结果显示这个团队绝大部分研究员的主导特点就是“冷静分析的蓝色”。而同一个测试中的其他团队的则没有这样的特点。

 [XZ2]加一个尾注：请读者自行替换为你所知道的最新技术

 [XZ3]请加尾注：这一节讨论的几种思维方法就是在《Six Thinking Hats》（中译本《六顶思维帽》）中提到的几顶帽子，不巧的是，和创意对应的是绿色的帽子，不符合中国国情。