《告别失控:软件开发团队管理必读》一一2.7 个性特点

2.7 个性特点

程序员除了具有不同的类型之外,还普遍存在着个性特点、特质和习惯,这些因素各自都面临着一些挑战。

学术界有着许多关于个性、如何对个人进行分类以及如何管理个性的理论。在这些理论中,迈尔斯和布里格斯的工作值得花一些时间来理解,他们俩在1942~1962年间建立了个性测试的理论基础,并提出了对个性进行分类的体系。迈尔斯-布里格斯类型指标(Myers-Briggs Type Indicator,MBTI)个性清单的作用是,使C. G. Jung描述的心理类型理论易于理解,在生活中更实用。[5]他们的工作在1984年出版的《请理解我》(Please Understand Me)[6]一书中得到了推广,该书以一种易于理解的形式介绍了迈尔斯-布里格斯方法。

Jung最初描述的类型是外向(extroversion,E)/内向(introversion,I)、感觉(sensation,S)/直觉(intuition,N)、思考(thinking,T)/感觉(feeling,F)和感知(perceiving,P)/判断(judging,J)。值得注意的是,研究[7]表明相当一部分程序员属于INTJ(内向/直觉/思维/判断)类型,Mickey和Ron也都具有这一个性特点。

这本书中有许多值得学习的地方,尤其是在人际关系方面。然而,用这种公式化的方法来应对多样化的技术个性特点是充满危险的,我们也没有发现它在团队管理方面特别有用。我们建议你避开公式化的个性分类,而把精力放在已知个性特点的管理方面。

根据自身的经验,我们给出了一些你在管理程序员时可能会碰到的个性特点类型。这个清单并不详尽,但我们基本上解释了你可能会管理到的不同个性类型,并给出了一些辨别方面的建议。

2.7.1 左脑型的人与右脑型的人

右脑理论与左脑理论源于Roger W. Sperry的工作[8],他的研究表明,大脑的左半球和右半球具有针对不同任务的专门功能。左脑通常专用于分析任务和语言表达任务。左脑的表达能力比右脑强得多,而右脑主要用于空间感知任务、音乐等。

如果你是一名程序员或者技术人员,你很可能属于“左脑型”,这意味着语言、逻辑和分析使用得更多,也更客观。其实称为“左脑为主型”更恰当,因为我们只有一个大脑,两个半球始终是同时工作的。因此,你既可以是“左脑型”的人,又可以具有非语言交流、直觉、想象力较多且更主观等强烈的“右脑型”倾向——这些倾向通常更多地与音乐家、作家、艺术家等创新型人才相关联。

对于一名优秀的程序员来说,强大的左脑分析能力是必不可少的。不过,与右脑相关的活动往往也同样重要,这是因为程序设计是一门很有创意的艺术(如第1章讨论的那样,更像是写小说)。事实上,我们(和其他人一样)发现,一些最顶尖的程序员同时也是音乐家。Mickey在大学一年级刚接触程序设计时就是一名专职音乐家。“我刚开始做程序设计时,就对媒体很有兴趣,那时我已经是一名音乐家了。音乐理论都是基于数学的,长时间的练习需要专注和纪律。我发现演奏和/或作曲时的创造性部分与设计并实现程序时的创造性部分非常相似。令人惊讶的是,甚至程序调试也在某些方面类似于歌曲的演奏学习——你需要一遍又一遍地演奏歌曲中的某一部分直至完全正确,这就如同反复运行程序直到能够正确运行一样。我甚至发现自己在做程序设计的时候完全没有时间概念,这与我练吉他的情形非常相似。从那时起,尽管我还在继续演奏音乐、作曲和作词,但程序设计已变成了我的主要创新活动。”

在我们认识的众多程序员中,这样的故事并不是唯一的。事实上,音乐已经成了对有希望的候选人进行第一次面试时的常见问题。如果候选人是音乐家,那么讨论他们喜欢什么样的音乐、演奏什么样的音乐、音乐理论以及音乐在他们生活中的地位,不但可以展现深刻的见解,而且有助于使他们在面试的开始阶段保持放松。成为音乐家不是成为优秀程序员的必要条件,但我们也从来不将其视为成为优秀程序员的障碍!

2.7.2 夜晚型的人与白天型的人

多数企业中的多数雇员属于白天型的人,与他们不同,多数程序员属于夜晚型的人。他们往往在正常上班时间过了好久之后才到单位,并且工作到下班以后很久,当关键性的项目或者自己感兴趣的项目进展到中途时常常能工作到深夜。一般说来,如果你关注的是结果,而这些起床很晚的人能给出符合或者超出你预期的结果,那就不是什么问题。然而,沟通经常是个问题;也就是说,他们需要出席会议并交流信息。

在《编程之道》(The Tao of Programming)[9]中,Geoffrey James提到:

经理走到程序员们跟前说:“关于工作时间:你们必须上午9点到,下午5点走。”听到这里,所有的程序员都很生气,有几个当场就提出辞职。

于是经理说到:“好吧,只要你们能按计划完成项目,可以自己安排工作时间。”程序员们这才感到满意,从此每天中午来上班,一直干到第二天凌晨。
为了避免这样的问题,我们强烈建议你别要求夜晚型的人早上9点就到。我们的建议是,你设定一些希望所有人都遵守的“核心时间”,以确保整个团队之中能有最低限度的合理沟通**。商定核心时间可以帮每个人节省大量的时间,且易于避免苦闷。注意,隔一段时间就要重申一下核心时间,因为程序员会感觉到日程的变化,他们对核心时间的遵守会渐渐不那么严格。

还有一个问题需要解决,那就是公司其他部门对你的团队的看法。在我们俩工作过的每个企业,我们都听到过“你的手下直到中午才来上班”这样的批评。针对这样的话,你需要主动突出强调你的团队投入了多少时间,他们写完并提交代码的时间有多晚。确保把那些最有名的夜猫子挑出来,让大家都看到他们按自己的工作习惯所做出的业绩。这一切都要主动去做,不要等到出现批评之后才着手。

2.7.3 “牧童”与“农民”

大多数程序员倾向于当“牧童”而不是当“农民”。也就是说,当问题出现时,他们的第一反应是“跳上马离开”去独自解决问题。他们常常跳过规划,最终得到一次性的解决方案。实际上,可以在标准、实践和团队之间取得更好的平衡。

我们希望软件开发更像种地。农民会有条不紊地了解地形、研究土地的化学组成、种植、浇水、除草,最后收获。可靠、可扩展、可维护的软件就是这样有条不紊地开发出来的。

因此,识别出牧童,并确保他们受到限制而不能快速冲出去是很关键的。这样开发出来的解决方案最终才能用于解决其他问题。

很多程序员都有牧童倾向,因此更高的要求是营造以下的软件开发文化:禁止牧童行为,所有的主要项目都遵循系统的软件开发生命周期。

不过,有时候,你还真的想要一个“牧童”而不是想要一个“农民”,这些时候需要做的通常是小型的、一个程序员就能完成的概念验证项目或者原型项目。我们发现,如果身边有一个能解决这种问题的“枪手”,对他对你都很有利。把你的需求和程序员的基本个性匹配起来,双方都会更开心,结果也会更好。

许多“牧童”都是优秀的程序员,但你必须小心地对他们进行管理,以获得想要的结果。他们有着当主角和引起纷争的倾向,所以务必对他们保持密切关注,一旦出现问题要马上采取措施。

只能当“牧童”的程序员通常都不会在企业待太久。要么是你对他们总是自顾自地向前冲感到厌烦而辞退他们,要么是他们对长期受限制感到厌烦而主动辞职。

2.7.4 英雄

英雄指的是承担需要超人的努力才能完成的任务,并最终取得成功的人。在付出超人的努力方面,英雄与牧童是相似的。但英雄能够在团队工作和开发过程中获得成果。英雄是培养出来的,通常会在企业中崛起为超级明星。

管理英雄的挑战是:如果你总是期望他们付出超人的努力,很容易就毁了他们。偶尔期望一下是可以的,总是这样期望就不行了。认真关注他们的福利,把他们选择性地用于重要的举措或者关键的项目。

Mickey和Ron在从事程序设计工作的时候,常常承担难度较大的项目,并(在熬了若干通宵或者进行马拉松式的工作之后)出乎意料地完成任务。这对我们工作过的公司是很有益处的:为Kenway和E&S实现了关键产品的发布;完成了里程碑式的苹果电脑产品演示,这对于苹果当时最新的计算机生产线是很关键的;为我们的公司储备了专利技术;为了客户和公司的利益,不断挑战我们自身的极限和已知的技术极限。在我们成为经理之后,这样的经历对于判定选择性的超人努力与毁灭性的用人方式之间的界限是非常有用的。

2.7.5 内向的人

你的一些职员非常沉默、非常内敛,几乎感觉不到他们的存在。他们可以把工作完成得很出色,但是对团队动力或在会议上几乎没什么贡献。他们在一对一的时候能进行交流,但退回到人群里以后就几乎消失了。

在会议上让他们发言时,当他们分享自己的意见或见解时,要给予正面的支持,这样可以逐步帮助他们建立自信——自己对团队是有贡献的。找机会跟他们交谈,当面认可他们的贡献。与他们的交流要一个一个地进行。通过一些小事情与他们建立特殊的联系,比如分享经验或者一本书。总之,想方设法建立更紧密的联系。

Mickey想起了Brøderbund公司的一名内向的技术作家。Mickey与这名作家是通过角色扮演游戏建立联系的。Mickey的鼓励促使他进入了游戏设计领域,最终成为了Brøderbund的游戏设计经理,后来又在其他一些公司担任小有名气的出版作家和游戏设计师。

多年来,这一联系以及其他一些类似的联系对我们俩来说也是一种回报,因为我们亲眼看到了谦虚的人经过我们的鼓励之后有所成长,并展现了自己的才华。

2.7.6 愤世嫉俗的人

尽量避免雇用心存极大愤懑的人。他们会通过挑拨离间和散布不满情绪来毒害整个开发团队,并对组织造成严重的破坏。如果没有他们,那些情绪可能永远不会出现。

愤世嫉俗的问题在于它是植根于现实的,但在组织内部的影响极大、极深。例如,“管理层不在乎程序员”可能是真的。但即便实际情况并非如此,愤世嫉俗的人们也会抓住每个机会来强调这句话的真实性。他们会把每一次非故意的怠慢(如办公室冰箱中饮料的变化)说成是“管理层用来惩罚程序设计人员的密谋”。用最客气的话说,这样的言论是公然藐视真理和道德的。你甚至发现自己根本无法度假,如果不希望回来时发现自己的团队处于混乱、脱轨甚至“造反”状态的话。

2.7.7 奇葩

有些人只不过是奇葩(jerk)。他们粗鲁、刻薄、中毒不浅。当然,他们或许也有些可取之处。他们可能是很有才华、很有技术天赋的优秀程序员。但才华并不能匹配你雇用他们所需要付出的代价。离他们很近正是问题所在。

遵循“不招收奇葩”的法则。根据我们的经验判断,如果你不这样做一定会后悔的。最好将该法则扩展到愤世嫉俗之人和傻瓜。你的职员会对此很赞赏,你的工作也会轻松很多。

第5章和第7章还会详细谈论愤世嫉俗的人、笨蛋和奇葩。

时间: 2024-10-30 13:28:12

《告别失控:软件开发团队管理必读》一一2.7 个性特点的相关文章

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

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

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

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

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

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

《告别失控:软件开发团队管理必读》一一1.2 成功的程序设计经理为什么难当

1.2 成功的程序设计经理为什么难当 大多数杰出的程序员并不热衷于当其他程序员的经理.他们知道团队需要软件经理,但乐得让别人来做实际的管理工作.他们通常不喜欢管理人员或项目. 管理程序员是很难的!"管理程序员很像是在放牧一群猫"--这句话常被引述,它揭示了高效.成功的程序设计经理难当的本质原因.猫的自由主义.个人主义色彩浓厚,而且狡猾.贪玩.好奇.独立.程序员也一样. 根据我们的经验,非常能干的软件经理是很稀少的.而只有这类很少见的软件经理才能成功地管理无拘无束的程序员并且乐在其中.

《告别失控:软件开发团队管理必读》一一2.5 工作地点与关系

2.5 工作地点与关系 近年来,软件开发管理的复杂度比以前大了很多.也许你很幸运,仍然保持在简单的环境中,但这样的日子很快就不会再有了.即使现在不受影响,早晚都会受到影响的:否则,你的企业将不再具备竞争力. 以前,听到的问题都是:"去哪里找一个程序员来做项目?"后来逐渐开始思考是招聘现场全职雇员还是招聘合同工的问题.现在,在哪里完成工作.怎样完成工作往往涉及大量的决策,需要仔细考虑. 通常,这些决策不由你来做出,它们可能是由你的领导或者项目情况而定的.无论如何,要想取得成功,必须解决好

《告别失控:软件开发团队管理必读》一一2.2 程序员的类型

2.2 程序员的类型 为了选择合适的职员,我们还需要理解另一种看待程序员的方法.在上一节讨论的几种类型中,我们侧重考虑了程序员所从事的工作的类型(即客户端.服务器.数据库.Web).实际上,从技术知识.实践经验和程序员的专长角度去考虑也是很重要的,按这样的思路可以把程序员分类为: 系统工程师/架构师:系统程序员:应用程序员:非真正意义上的程序员. 2.2.1 系统工程师/架构师 在所有开发类职员中,系统工程师/架构师是最有技术和经验的.要想理解所有相关的系统组件(操作系统.通信系统.数据库.在线

《告别失控:软件开发团队管理必读》一一2.9 工具

2.9 工具 我们为团队管理提供了许多辅助工具.电子表格和Word文档提供了完整的示例,稍作修改即可用于你自己的组织.全书最后的"工具"部分给出了工具网站的链接,在那里可以下载下列工具: 程序员级别样例:各程序员级别的职位描述样例:独立合同工协议样例:角色和排名系统.

《告别失控:软件开发团队管理必读》一一2.1 程序设计工种

2.1 程序设计工种 了解程序员的第一种方法是分析他们的程序设计工作可以归为哪些类型.程序设计工作通常有下面4种类型: 客户端程序员: 服务器程序员: 数据库程序员: Web开发人员及其他脚本编写者. 当然,可能有许多特殊的程序设计工作难以确切地归结为上述某种类型.但总的来说,这4种类型已经覆盖了世界上的绝大多数程序员,其中每一种程序员擅长的问题解决方法.使用的工具以及侧重的产品方向都各不相同.一些极有天分的程序员能够胜任所有工作,但大多数程序员认为自己虽然能完成所有的程序设计任务,但其实最多只

《告别失控:软件开发团队管理必读》一一2.6 代系特点

2.6 代系特点 在工程师和程序员中,代系差异是一直存在的,而今这些差异已经对职场产生显著的影响.当前,团队的成功必须依赖三代程序员的通力协作,而这三代人的价值观.想法和驱动力都不同. 为了把工作做好,我们不仅需要了解自己的工作风格,还要掌握手下员工的工作风格.一种常见的办法是从代系的角度来看待他们,但问题在于人们对代系的划分还未达成广泛的共识.传统上是按出生时间来区分的: 婴儿潮一代(1946-1964年出生):X一代(1965-1979年出生):千禧一代(1980-2000年出生),有时也称