MBTI在软件开发团队中的应用

人绝不是一种资源。一方面我们不可能因人设岗,另一方面也不能忽略人性的差异。面对问题时,不要总是单纯地从人的态度或品德上查找问题,而是要反思人事安排和流程建设上的不足。奢望一个人改掉他的缺点,还不足充分发挥他的优点。


前言

MBTI将人区分为16类人格特质,我无法断言是否真得能表达出人的真实一面,毕竟只是统计性的结果。我的思考并不在于它归类的结果,而在于它的归类方法。

 

在团队合作中,各种各样的情绪、喜好、偏见一直在影响着我们对于人和事的判断。我们强调第一印象的重要性,正是因为一旦被贴上标签,就很难再被甩掉。

 

在软件开发团队中不同的人在不同的活动中会有不同的表现,这一切都是非常自然的。举个例子,一个人在维护团队做得很棒的工程师,被转到项目团队后绩效一落千丈,公司和个人都在承受巨大的损失。也有人解Bug总是引入新问题,显得代码质量低下,但却能在技术研究上有所突破。

 

人绝不是一种资源。一方面我们不可能因人设岗,另一方面也不能忽略人性的差异。从人性本善的角度出发,如何理性地观察和对待我们周围的人,以求扬长避短?MBTI在这方面可以提供很好的借鉴。MBTI强调奢望一个人改掉他的缺点,还不足充分发挥他的优点。虽然我们从小的教育和环境的塑造让我们趋于选择被普遍认可的行事方式,这需要我们要有更多的耐心理性的对待其中的不确定性,甚至可能矛盾的表现。

 

MBTI介绍

1942年,瑞士精神分析学家荣格(弗洛伊德的学生),第一次提出人格分类的概念。他认为感知和判断是大脑的两大基本功能。不同的人,感知倾向不同——有些人更侧重直觉,有些更侧重实感。同样,不同的人判断倾向也不同——有些更倾向理性分析得出结论,有些更侧重情感考量,更为感性。同时,这两大基本功能又受到精力来源不同(内向或外向)的影响。近代美国心理学家KatherineCook Briggs 提出大脑的两大基本功能还受到生活方式倾向的影响:计划型和散漫型。

 *来自www.apesk.com

根据李涛老师的<<项目管理>>中提供的MBTI的人格维度:


                                         MBTI模型的人格维度


人与世界是如何相互影响的


外倾(Extrovert)


内倾(Introvert)


我们关注的信息类型


感觉(Sensing)


直觉(iNtuition)


我们是如何做决定的


思考(Thinking)


情感(Feeling)


我们倾向的生活方式


判断(Judgement)


认知(Perception)

我根据自己的学习和理解,总结了各个维度的要点和偏好如下:

 

它们间组合后的特征可以查看一些专业全面的介绍。李涛老师在<<项目管理>>中特别研究了对于工作影响较大的两个维度(SN&JP)做了剖析。我在这里则选择了除外顷或内倾外的三个维度来分析。如前面所说,我不准备谈也没有能力谈出人格组合的特性,而是关注在三个维度中不同倾向在软件团队工作中的影响。单独看一个维度上的倾向来了解自己和别人是困难的,因为它们总是在相互作用下会产生不同的结果和表现。

 

通过上面列表对四个维度的介绍,可以归纳出不同维度中不同倾向的以下表现:


感觉(Sensing)


关注自己可感知可观察的细节、喜欢使用和琢磨已知的技能。偏向线性思维,有时很较真,总是被一些不重要的细节牵着走。


直觉(iNtuition)


关注事物的整体和发展变化趋势,重视想象力和独创力,喜欢学习新技能,但容易厌倦。思维活跃,太跳跃有时会让表现出的效率偏低。


思考(Thinking)


重视事物之间的逻辑关系,喜欢通过客观分析作决定评价。理智、公正。圆通比坦率更重要。在客观分析后做出决定。有时会表现出古板,缺少冲劲。


情感(Feeling)


注重自己及对别人的情感影响,将价值观作为判定标准,圆通和坦率同样重要。表达意见时会有保留,并且有时会表现出情绪化,有时则显得有些谨小慎微。


判断(Judgement)


喜欢做计划和决定,愿意进行管理和控制,希望生活井然有序。重视结果(完成任务),按部就班、有条理、尊重时间期限、喜欢做决定。


认知(Perception)


灵活、试图去理解、适应环境、倾向于留有余地,喜欢宽松自由的生活方式。重视过程、随信息的变化不断调整目标,喜欢有多种选择,爱做有突破性的事。 有时会表现出执行不到位,不合规矩。

*部分参考了www.apesk.com提供的报告。

 

有趣的是,同一个维度的倾向只是表达出行为特征,基于此仍然会有不同的结果。比如F,同时在关注情感影响,有些人可能会十分情绪化,积极表达自己的看法,有些则趋于保留自己的看法而迁就别人的感受。但可以确定的是F一定是感情丰富且细腻的人。

 

软件开发团队的构成

关于团队构成,已经有很多见解,比较著名的是外科手术团队。有些说团队纯粹由同质化且同水准的人来构成的想法,早已被否定了(参考.  本来有另一个更接近软件行业也更权威的文章,可惜忘记了)。从人事管理的角度上也是有梯队建设、文化建设来确保团队的健康发展。其实无论哪种团队形式,都要追求互补和共赢。即使对于软件开发团队(没有包含美工等),也不是纯粹以技术来组织团队。就好比再好的钻石也要加个箍才能戴在手上。

 

类似从因岗设人的角度出发,我们在谈论团队构成时,一定要知道团队要做什么,涉及到多少工作期望。我用工作期望或者绩效表现,而不是工作项目,是因为不同的人做不同的事得到结果可能会不一样。如果你清楚了工作上的期望,就会容易找到那个会做对的人,或者找到帮助他去做对的方法或流程。比如关注开发流程是一个期望,有些公司对工程师在流程上要求很严,有些公司则因为处在初创阶段,并不太在意是否遵从开发流程(可能根本还没有流程定义)。

 

以下是我概括的软件开发团队中会涉及的工作期望(不是工作项目):


关注和遵循开发流程


注重和改进工作方法


高质量的代码


高质量的设计


新项目或新技术研究开发


代码维护


注重且增进团队和谐的人际关系


组织与协调


分享与讨论


自我驱动


结果导向


兴趣/成就导向


新人培训

 

 

 运用MBTI组织软件开发团队 

分析过MBTI的各个维度上的思维差异,再结合在团队工作中的表现所需要的特质,就可以大致帮我们找到合适的人或者为人找到合适的岗。以下分析只代表有明显倾向的情况之下,对于一些已经受过训练且有流程保障的情况下,并不一定适用。比如对S和N,就可以用查核表(Check List)或者思维导图的形式加以平衡。这个不在本文的研究范围内。

 

比如,如果对开发流程要求很高,比如在一些外包项目和一些特定行业软件项目中,有严格的流程来保证软件质量。显然S和J就是比较适合了。因为S注重细节,J讲究秩序。如果换作P,一定做不了多久,他无法忍受一板一眼的做事方式和反复的Review流程。要么尝试改变流程,要么就是离开。同样是S,又会因为在面对问题时不断被一些细节干扰,会过于执着于自己的经验和判断,不一定会带来好的设计,在面对新的问题时就会引入一些风险。

 

N和P则因为思维的活跃,可能会考虑到不同的解决方案,常常会在设计或者疑难问题上有所突破,但这不表示他一定会写出高质量的代码。特别是写一些很平常的代码时反而表现不如S和T。

 

再以新人培训为例,不要以为只要有经验现在也有时间有精力的工程师都可以带新人。这本身是一个系统工程,除了公司在培训制度上的建设外,不同的Mentor也会带来不同的效果。技术上的高手如何用对方能理解的方式把问题讲清楚?如何为新人勾勒出Big Picture?如何有效的鼓励和刺激新人的成长?有些新人喜欢高手带自己,不论对方的态度和要求如何,他都能从成长获得快乐。也有新人更希望对方能说清楚,自己可以逐步成长。这就是MBTI可以发挥的地方。

 

再举一个组合的例子。如果S与T相结合,表示在观察着重于一切实际存在的东西,在决策时又会经过理性的判断。十足的严谨作风,如果是维护质量要求高(如对负作用[side effect]的零容忍)的商业项目自然十分合适。

 

最后是我结合以往的经验,为各个不同的表现(对应于期望)做个适配,权做个初始值,日后逐步完善。

         

人格或许是稳定的,但表现却可能不同。经过人为的训练或者有对应的流程建设,是完全可以让人的优势充分发挥出来的。前提是我们应当了解到人的差异。面对问题时,不要总是单纯地从人的态度或品德上查找问题,而是要反思人事安排和流程建设上的不足。借助MBTI,或许是一个很好的起点。

时间: 2024-09-25 15:56:02

MBTI在软件开发团队中的应用的相关文章

如何对待开发团队中那个拖后腿的人?

每个开发团队中总有一个人是最差的,老跟不上整体水平.据我观察,队友们对待这个差生的态度是团队健康状况的重要标志.(注:原文用"贝尔曲线(bell curve)",也就是"正态分布"来衡量团队的整体水平分布,这里意译成"整体水平".) 我运气一直不错,在过去的几十年里,干过各种的行业和职业,在不少团队中待过,都是气氛融洽和技能娴熟的开发团队.并不是说每个项目都是成功的,(外部因素无法控制),但是经验永远有深刻的价值. 在成功的开发团队里,最显著的特

如何对待测试开发团队中那个拖后腿的人?

每个开发团队中总有一个人是最差的,老跟不上整体水平.据我观察,队友们对待这个差生的态度是团队健康状况的重要标志.(注:原文用"贝尔曲线(bell curve)",也就是"正态分布"来衡量团队的整体水平分布,这里意译成"整体水平".) 我运气一直不错,在过去的几十年里,干过各种的行业和职业,在不少团队中待过,都是气氛融洽和技能娴熟的开发团队.并不是说每个项目都是成功的,(外部因素无法控制),但是经验永远有深刻的价值. 在成功的开发团队里,最显著的特

Google 极客谈软件开发团队的不良行为

开发团队是一个整体,稳定的.沟通无碍的团队文化非常重要.好的文化氛围应该包括基于共识决策的开发模式.高质量的代码.代码审查,以及能让人放心尝试新事物或者快速失败的环境.Brian和Ben是Google的两位开发主管,他们在"极客与团队"中列举了软件开发团队的典型不良行为,提醒开发者时刻保持警惕,并提出了一些实际的解决办法. Brian和Ben指出,团队的注意力和专注力是最容易受到威胁的.团队规模越大,编写软件和解决有趣问题的能力就越强-不过这种能力毕竟是有极限 的.要是你不去主动保护它

《告别失控:软件开发团队管理必读》导读

前言 告别失控:软件开发团队管理必读 软件开发常常被认为是难以管理的.进度安排和费用预算完全不靠谱的软件项目比比皆是.规范化的软件开发实践对这一状况有所改善,但也未能真正解决问题.我们软件开发行业已经积累了超过60年的技术经验,并已经投入了大量的时间,以及美元/日元/卢比/欧元来尝试把管理规范化,但为什么软件开发至今仍然如此难以管理呢? 本书用一个简单的观察结果来回答这个长期存在的问题:管理者首先必须学会管理程序员和软件团队的技巧.也就是说,必须学会了解员工-如何聘用他们,激励他们,进而领导他们

建立软件开发团队时要避免的7个问题

建立和维护一个高性能的软件开发团队是一个持续努力的过程.挑战范围包括从竞争激烈的市场中吸引优秀人才到提供有趣和富有挑战性的工作,以及组建团队结构和促进人员成长. 我们很幸运地工作在一些致力于提升交付质量和频率的软件开发团队,并且我们发现了一些非常的常见阻碍团队快速地推出优质软件的结构和做法: 1:"DevOps"孤岛 特别是随着一个团队的成长,或者可能是为了填补当前团队技能集中存在的差距,我们会被诱惑着在团队中或团队周围建立单独的功能以执行特定的工作岗位. 我们看到的最常见的表现是操作

《告别失控:软件开发团队管理必读》一一1.1 程序员都做什么

1.1 程序员都做什么 首先,程序员的工作很有趣!Fred Brooks在软件工程的经典名著之一<人月神话>[6]中很好地总结了程序设计充满乐趣的原因. "第一,是纯粹的创造的愉悦--""第二,是做出对其他人有用的东西而带来的快乐--""第三,是设计组装谜题一样环环相扣的复杂部件,并观看着它们巧妙地运转而产生的吸引力--""第四,是持续学习的乐趣,这来源于任务的无重复特性--""第五,工作的对象是可以自由

软件开发实践中的入队列和出队列操作的C代码示例

概述 最近有在校的学生朋友在问我,数据结构中的队列在实际的软件开发项目中有什么样的用处. 大家都知道,队列的特点是先入先出,即数据是按照入队列的顺序出队列的.在实际的软件开发项目中,当一个中间模块需要接收和发送大量的消息时,队列就可以大展身手了.我们可以将接收到的数据存储在一个全局队列中,然后在另外的程序流程中将数据从同一个全局队列中取出来,经过一定的处理之后将消息发送到另外的模块.这样做可以降低程序的性能瓶颈. 本文用实际的C代码示例了简单的数据入队列和出队列的方法,大家可据此了解队列的实际用

《告别失控:软件开发团队管理必读》一一第2章 理解程序员

第2章 理解程序员 告别失控:软件开发团队管理必读从许多方面看,程序员之间的差异都非常大,只有很了解程序设计的人才能完全理解这一点.大多数公司的高层管理者对所有的程序员一视同仁,这是一个可怕的错误.微软公司的Bill Gates和Adobe Systems公司的John Warnock都没有犯这样的错误,因为他们俩本质上也都是程序员. 这种差异为什么很重要?也许不应该很重要,但事实上,这种差异真的很重要.历经多年的程序员管理工作之后,我们仍然惊叹于程序员之间的巨大差异,需要有区别地进行问题处理和

在软件开发流程中运用单元测试和功能测试

由于受到极限编程的影响,在最近的几年时间里单元测试逐渐成为我软件开发过程中一个不可或缺的重要组成部分.极限编程要求我们对我们所完成的每一项功能都要进行单元测试并且要很好的管理这些测试,我们不应该在所有的单元测试通过之前去集成任何新的功能.这种做法的好处就是可以让开发人员对自己所写的代码充满信心(而不是盲目的毫无根据的自负). 最开始我认为既然已经有了单元测试了,就没有必要再去花时间在功能测试上了,可我现在知道这是一个错误的想法:单元测试和功能测试是有很大的不同的.我花了很长的时间才了解到单元测试