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，或许是一个很好的起点。