学术界有着许多关于个性、如何对个人进行分类以及如何管理个性的理论。在这些理论中，迈尔斯和布里格斯的工作值得花一些时间来理解，他们俩在1942～1962年间建立了个性测试的理论基础，并提出了对个性进行分类的体系。迈尔斯-布里格斯类型指标（Myers-Briggs Type Indicator，MBTI）个性清单的作用是，使C. G. Jung描述的心理类型理论易于理解，在生活中更实用。他们的工作在1984年出版的《请理解我》（Please Understand Me）一书中得到了推广，该书以一种易于理解的形式介绍了迈尔斯-布里格斯方法。
Jung最初描述的类型是外向（extroversion，E）/内向（introversion，I）、感觉（sensation，S）/直觉（intuition，N）、思考（thinking，T）/感觉（feeling，F）和感知（perceiving，P）/判断（judging，J）。值得注意的是，研究表明相当一部分程序员属于INTJ（内向/直觉/思维/判断）类型，Mickey和Ron也都具有这一个性特点。
然而，用这种公式化的方法来应对多样化的技术个性特点是充满危险的，我们也没有发现它在团队管理方面特别有用。我们建议你避开公式化的个性分类，而把精力放在已知个性特点的管理方面。
根据自身的经验，我们给出了一些你在管理程序员时可能会碰到的个性特点类型。这个清单并不详尽，但我们基本上解释了你可能会管理到的不同个性类型，并给出了一些辨别方面的建议。
1 左脑型的人与右脑型的人右脑理论与左脑理论源于Roger W. Sperry的工作，他的研究表明，大脑的左半球和右半球具有针对不同任务的专门功能。左脑通常专用于分析任务和语言表达任务。左脑的表达能力比右脑强得多，而右脑主要用于空间感知任务、音乐等。
如果你是一名程序员或者技术人员，你很可能属于“左脑型”，这意味着语言、逻辑和分析使用得更多，也更客观。其实称为“左脑为主型”更恰当，因为我们只有一个大脑，两个半球始终是同时工作的。因此，你既可以是“左脑型”的人，又可以具有非语言交流、直觉、想象力较多且更主观等强烈的“右脑型”倾向——这些倾向通常更多地与音乐家、作家、艺术家等创新型人才相关联。
对于一名优秀的程序员来说，强大的左脑分析能力是必不可少的。不过，与右脑相关的活动往往也同样重要，这是因为程序设计是一门很有创意的艺术。事实上，我们（和其他人一样）发现，一些最顶尖的程序员同时也是音乐家。Mickey在大学一年级刚接触程序设计时就是一名专职音乐家。“我刚开始做程序设计时，就对媒体很有兴趣，那时我已经是一名音乐家了。音乐理论都是基于数学的，长时间的练习需要专注和纪律。我发现演奏和/或作曲时的创造性部分与设计并实现程序时的创造性部分非常相似。令人惊讶的是，甚至程序调试也在某些方面类似于歌曲的演奏学习——你需要一遍又一遍地演奏歌曲中的某一部分直至完全正确，这就如同反复运行程序直到能够正确运行一样。我甚至发现自己在做程序设计的时候完全没有时间概念，这与我练吉他的情形非常相似。从那时起，尽管我还在继续演奏音乐、作曲和作词，但程序设计已变成了我的主要创新活动。”
在我们认识的众多程序员中，这样的故事并不是唯一的。事实上，音乐已经成了对有希望的候选人进行第一次面试时的常见问题。如果候选人是音乐家，那么讨论他们喜欢什么样的音乐、演奏什么样的音乐、音乐理论以及音乐在他们生活中的地位，不但可以展现深刻的见解，而且有助于使他们在面试的开始阶段保持放松。成为音乐家不是成为优秀程序员的必要条件，但我们也从来不将其视为成为优秀程序员的障碍！
2 夜晚型的人与白天型的人多数企业中的多数雇员属于白天型的人，与他们不同，多数程序员属于夜晚型的人。他们往往在正常上班时间过了好久之后才到单位，并且工作到下班以后很久，当关键性的项目或者自己感兴趣的项目进展到中途时常常能工作到深夜。一般说来，如果你关注的是结果，而这些起床很晚的人能给出符合或者超出你预期的结果，那就不是什么问题。然而，沟通经常是个问题；也就是说，他们需要出席会议并交流信息。
在《编程之道》（The Tao of Programming）中，Geoffrey James提到：
经理走到程序员们跟前说：“关于工作时间：你们必须上午9点到，下午5点走。”听到这里，所有的程序员都很生气，有几个当场就提出辞职。
于是经理说到：“好吧，只要你们能按计划完成项目，可以自己安排工作时间。”程序员们这才感到满意，从此每天中午来上班，一直干到第二天凌晨。 为了避免这样的问题，我们强烈建议你别要求夜晚型的人早上9点就到。我们的建议是，你设定一些希望所有人都遵守的“核心时间”，以确保整个团队之中能有最低限度的合理沟通**。商定核心时间可以帮每个人节省大量的时间，且易于避免苦闷。注意，隔一段时间就要重申一下核心时间，因为程序员会感觉到日程的变化，他们对核心时间的遵守会渐渐不那么严格。
还有一个问题需要解决，那就是公司其他部门对你的团队的看法。在我们俩工作过的每个企业，我们都听到过“你的手下直到中午才来上班”这样的批评。针对这样的话，你需要主动突出强调你的团队投入了多少时间，他们写完并提交代码的时间有多晚。确保把那些最有名的夜猫子挑出来，让大家都看到他们按自己的工作习惯所做出的业绩。这一切都要主动去做，不要等到出现批评之后才着手。
3 “牧童”与“农民”大多数程序员倾向于当“牧童”而不是当“农民”。也就是说，当问题出现时，他们的第一反应是“跳上马离开”去独自解决问题。他们常常跳过规划，最终得到一次性的解决方案。实际上，可以在标准、实践和团队之间取得更好的平衡。
我们希望软件开发更像种地。农民会有条不紊地了解地形、研究土地的化学组成、种植、浇水、除草，最后收获。可靠、可扩展、可维护的软件就是这样有条不紊地开发出来的。
因此，识别出牧童，并确保他们受到限制而不能快速冲出去是很关键的。这样开发出来的解决方案最终才能用于解决其他问题。
很多程序员都有牧童倾向，因此更高的要求是营造以下的软件开发文化：禁止牧童行为，所有的主要项目都遵循系统的软件开发生命周期。
不过，有时候，你还真的想要一个“牧童”而不是想要一个“农民”，这些时候需要做的通常是小型的、一个程序员就能完成的概念验证项目或者原型项目。我们发现，如果身边有一个能解决这种问题的“枪手”，对他对你都很有利。把你的需求和程序员的基本个性匹配起来，双方都会更开心，结果也会更好。
许多“牧童”都是优秀的程序员，但你必须小心地对他们进行管理，以获得想要的结果。他们有着当主角和引起纷争的倾向，所以务必对他们保持密切关注，一旦出现问题要马上采取措施。
只能当“牧童”的程序员通常都不会在企业待太久。要么是你对他们总是自顾自地向前冲感到厌烦而辞退他们，要么是他们对长期受限制感到厌烦而主动辞职。
4 英雄英雄指的是承担需要超人的努力才能完成的任务，并最终取得成功的人。在付出超人的努力方面，英雄与牧童是相似的。但英雄能够在团队工作和开发过程中获得成果。英雄是培养出来的，通常会在企业中崛起为超级明星。
管理英雄的挑战是：如果你总是期望他们付出超人的努力，很容易就毁了他们。偶尔期望一下是可以的，总是这样期望就不行了。认真关注他们的福利，把他们选择性地用于重要的举措或者关键的项目。
Mickey和Ron在从事程序设计工作的时候，常常承担难度较大的项目，并（在熬了若干通宵或者进行马拉松式的工作之后）出乎意料地完成任务。这对我们工作过的公司是很有益处的：为Kenway和E&S实现了关键产品的发布；完成了里程碑式的苹果电脑产品演示，这对于苹果当时最新的计算机生产线是很关键的；为我们的公司储备了专利技术；为了客户和公司的利益，不断挑战我们自身的极限和已知的技术极限。在我们成为经理之后，这样的经历对于判定选择性的超人努力与毁灭性的用人方式之间的界限是非常有用的。
5 内向的人你的一些职员非常沉默、非常内敛，几乎感觉不到他们的存在。他们可以把工作完成得很出色，但是对团队动力或在会议上几乎没什么贡献。他们在一对一的时候能进行交流，但退回到人群里以后就几乎消失了。
在会议上让他们发言时，当他们分享自己的意见或见解时，要给予正面的支持，这样可以逐步帮助他们建立自信——自己对团队是有贡献的。找机会跟他们交谈，当面认可他们的贡献。与他们的交流要一个一个地进行。通过一些小事情与他们建立特殊的联系，比如分享经验或者一本书。总之，想方设法建立更紧密的联系。
Mickey想起了Brøderbund公司的一名内向的技术作家。Mickey与这名作家是通过角色扮演游戏建立联系的。Mickey的鼓励促使他进入了游戏设计领域，最终成为了Brøderbund的游戏设计经理，后来又在其他一些公司担任小有名气的出版作家和游戏设计师。
多年来，这一联系以及其他一些类似的联系对我们俩来说也是一种回报，因为我们亲眼看到了谦虚的人经过我们的鼓励之后有所成长，并展现了自己的才华。
6 愤世嫉俗的人尽量避免雇用心存极大愤懑的人。他们会通过挑拨离间和散布不满情绪来毒害整个开发团队，并对组织造成严重的破坏。如果没有他们，那些情绪可能永远不会出现。
愤世嫉俗的问题在于它是植根于现实的，但在组织内部的影响极大、极深。例如，“管理层不在乎程序员”可能是真的。但即便实际情况并非如此，愤世嫉俗的人们也会抓住每个机会来强调这句话的真实性。他们会把每一次非故意的怠慢（如办公室冰箱中饮料的变化）说成是“管理层用来惩罚程序设计人员的密谋”。用最客气的话说，这样的言论是公然藐视真理和道德的。你甚至发现自己根本无法度假，如果不希望回来时发现自己的团队处于混乱、脱轨甚至“造反”状态的话。
7 奇葩有些人只不过是奇葩（jerk）。他们粗鲁、刻薄、中毒不浅。当然，他们或许也有些可取之处。他们可能是很有才华、很有技术天赋的优秀程序员。但才华并不能匹配你雇用他们所需要付出的代价。离他们很近正是问题所在。
遵循“不招收奇葩”的法则。根据我们的经验判断，如果你不这样做一定会后悔的。最好将该法则扩展到愤世嫉俗之人和傻瓜。你的职员会对此很赞赏，你的工作也会轻松很多。
我们列出了多种个性类型供大家了解，但强烈建议大家不要简单地按这些类型对人进行分类。把每个人都作为不同的个体看待，你这位程序设计经理会更成功。
本文节选自《告别失控：软件开发团队管理必读》
内容简介
这是一本系统阐述面对混乱而容易失控的技术开发团队时，如何管理、建设和强化团队，成功交付开发成果的大作。两位作者Mickey W. Mantle和Ron Lichty以合起来近70年的开发管理经验为基础，通过深刻的观察和分析，找到了软件开发管理的核心问题——人的管理，并围绕如何真正理解程序员、找到合适的程序员、与程序员沟通这几个核心话题，一步步展开，最终扩展到如何以人为本地进行团队建设、管理和项目管理。
本书适合初级开发管理人员，可以说是一本从初级管理人员成长为高级管理人员的必备之书。同时，也适合有志于走向管理岗位的程序员、产品或其他技术公司员工。
,
