合肥新格建站网,赤峰做网站建设的企业,网站制作容易吗,圣诞节html网页代码构建之法 17 章 人#xff0c;绩效和职业道德 (构建之法 第三版草稿) 2016/12/23 17.1 领导力 在软件开发过程中#xff0c;有很多平等合作#xff0c;但是也有上下之分的领导/被领导关系#xff0c;即使都是平级的员工之间#xff0c;也有老师傅/新人#xf… 构建之法 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)以及这些主意的负责人把这些好主意都放在好主意停车场上面以后时机成熟再启动这些想法. [XZ1]这里加一个尾注作者作为被测对象曾经参与过几十人的调查其中有一个十几人的科研团队虽然每个人的性格毕业学校不同研究方向也不一致但是统计结果显示这个团队绝大部分研究员的主导特点就是“冷静分析的蓝色”。而同一个测试中的其他团队的则没有这样的特点。 [XZ2]加一个尾注请读者自行替换为你所知道的最新技术 [XZ3]请加尾注这一节讨论的几种思维方法就是在《Six Thinking Hats》(中译本《六顶思维帽》)中提到的几顶帽子不巧的是和创意对应的是绿色的帽子不符合中国国情。
