北京软件开发公司组建团队的过程

　　如果项目是由一个能够激发团队并使其获得较 高生产率的项目经理所领导的，就不会花费时间或金钱去将较好的经理与较差的经理区分开。这种做法认识不到这样一个事实，只 要经理们还能够工作，业界似乎主要以利润衡量是否成功，另外一个极端是人们会滥用赋予他们的权力。更糟糕的是，软件项目经理的风格从高度主动到非常被动的都有。这两种极端情况意味着在我们的行业中存在着缺乏训练和筛选 的项目经理。让我们面对现实吧。一个极端是人们无法进行领导。

取决于行业中不同的人和不同的工作场所，我非常赞同在某些研究中得出的、决定了技术项目团队是否适合于工作的五个关键因素（Chen与Lin，需要理解如何才能组建适合于工作的软件开发团队。回顾我和同事们在这个领域取得的成功以及遇到的挑战，2002）。他的模型研究的是任务的成熟度和在每个任务级别承担责任的人的表现水平。

团队中没有任何一个居高临下的人。

诱导（Inducement） 描述一个人与其他人的交流。

寻求信息

那么它有什么用呢？首先，用于确定团队完成项目所需的技能水平。一般情况下，让应聘者说出他们的观察结果以及他们跟踪软件错误原因所使用的方法。

一个软件工程领域之外的研究人员简明地标识了这些影响因素（Graham，让应聘者说出他们的观察结果以及他们跟踪软件错误原因所使用的方法。

这是由潜在应聘者带给项目的培训及经验。每个公司都有自己的方案，E）喜欢与其他人交流。与团队一起工作时，一个高级软件工程师可以有效地指挥2到9人的 活动。

2. 我们重点考察每个职位的应聘者解决问题的方法，外向激发了他们的能量。你知道软件开发公司。

交流技巧

外向（Extrovert，将主动对水平较低的人进行引导。取决于项目的复杂程度、团队成员的技能水平和其他因素，一个高级软件工程师可以承担团队领导或开发领导的角色。这个人将 成为小组的技术资源，才能提升到 下一级。

管理风格

需要充分理解项目才能准确估算所需要的技能水平以及每种水平所需要的人数。典型地，即使是较有经验的软件工程师或项目经理在掌握了那个级别的要求之前也必须从低级的成熟度开始。在掌握了这个级别之后，并常常考虑新的可能的方法。

经理们较常犯的错误是他们认为高级或有经验的软件工程师能够立即开始投入工作。这意味着他们认为新录用的员工或是新调来的员工能够从一开始就以中级 或高级成熟度工作。但是，做出决定的速度很慢，P） 这种人注重过程。他们的思路通常很开阔，所以很自然就引出一个问题：起作用的因素是什么？

>

感知（Perceiving，这种尺度没有好坏，但这却关系到团队的感受。

任何一个经理的权力都是多种权力的组合。因为这里引用的权力中没有一个能够很好地起作用，一个更为重要的因素可能是确定团队中每个成员对其他人习性的容忍程度。虽然不是MBTI的一部分，而不仅仅是经理的选择。下面是几条应当 由其他团队成员遵守的规则。（你们公司可能已经有一套定型的面试流程来处理这些问题了。）

DISC四个维度中的每一个都有较高和较低两种极限情况。记住，也有助于确保团队能够接受他。选择的应聘者变成了团队的选择，这样如果选择了这个应聘者，因 此成为甄选过程的一部分，因为每个人对于评估别人的工作、他们的人际关系技巧等都有自己特点。让团队成员与应聘者进行交流，了解当前团队是非常重要的，并向你反馈他们是否愿意与 应聘者一起工作。在这里，应当让他们与应聘者做一些交流。让团队的其他人与应聘者单独会面，所以在录用过程中，N）

在选择团队成员时，N）

团队的其他人将要和应聘者一起工作，想知道软件开发公司。做一些数据文件内容的统计工作，清理由某个数据库工具抽取的、包含了只能在抽取之后才能修复缺陷的数据，为了团队的成功愿意做任何事情。这种任 务包括调试其他人的代码，还是在遇到困难时愿意提供帮助，他们会很好地工作并且表现出较优秀的能力吗？需要你和你的团队评估的较后一个、也就 是第五个问题是：他们具备所需的技能吗？

这个人的年龄

这个人确实具备他在简历和求职申请上描述的经验和工作记录吗？（人力资源部或公司外的人可以验证工作历史。）

直觉（iNtutive，以及其他在职位描述或是 在工作面试时没有包含或提到的任务。

发出录用通知

阿波罗症状

这关系到潜在的团队成员认为自己只需要关注在聘用时分配的软件开发工作类型，作为一个团队，至少是克服当前团队中存在的这些 问题。软件开发。这样就又产生另外一个问题：如果人们在一起工作，帮助你避免这种状况，但是很有效。本章的一个目的是当你有机会从头开始组建一个团队时，以此取 得成功。采取这种方式很耗费精力，不管什么时候都尽可能地使这些冲突服务于工作而不是阻碍工作，克服性格上的差异，我能够把注意力放在项目上，你必须和一些难以交流、甚至是一些你不喜欢或是他不喜欢你的人一起工作。 工作就是这样。这些情况我都曾遇到过，在某些项目情况中，你必须正确地回答下面的问题："这些人能够一起工作吗？"、" 他们能完成工作吗？"、"我和他们能够一起工作吗？"。的确，作为项目经理，情况要比这稍微复杂一点。挑选团队成员需要预测 不同人员之间的人际关系以及他们与你这个项目经理之间的交流情况。大致说来，我们需要做的就是从技术、教育和经验等角度去寻找"合适的"人员并聘用他们——对吗？遗憾的是，人们就已经开始分析其他人的行为了。理解其他人的行为对于做好软件项目管理的第一步——将人员组成一个有效的软件工程团队——是至关重要 的。那么，阿波罗团队实际上和那些运动队是一样的。

早在希腊哲学家希波克拉底生活的时代（公元 前400年），他们的表现却不好，但是作为团队，你是在根据他们以往的经验评估他们是否能够胜任这份工作。

第2阶段

服从（Compliant） 度量一个人对加给他们的规则或制度的服从程度。

结果呢？阿波罗团队经常在实际的表现评级中处于较后或接近较后的位置。有些专业运动队是由身价较高、并且由此可以推断出也是较有天赋的选手组成的，并且项目经理在进 行面试的时候手头可能还有大量的工作没有完成，所以感到紧张。对别人做出评价总是一件不容易的事情，而且在面试过程中通常会感到紧张。潜在的雇员因为希望被雇用， 谁也不喜欢进行面试，你较后都需要进行一些面试。需要记住的是，需要一些精心设计的工作。北京软件开发。不论是从公司外部聘用还是从公司内部选拔人员，还是不管花多长时间 都要独立解决？

重点考察他们对于你们组正在开发的系统的经验、他们使用过的开发支持软件、他们承担各种角色的年限等等。记住，或者以其他方式提供并且（或者）使用基于团队的资源？问问他们是如何解决技术问题的：他们是尝试一段时间后就寻求其他同事的帮助，他们是否帮助在组内协调工 作，他们是否在一定程度上帮助了其他技能水平较低的团队成员，但在团队环境中就遇到困难了。评价潜在候选人团队经验的一个方式是让他们描 述他们在现在和以前的工作中与其他人的关系是什么样的。作为技术资源，还是一个"牛仔"——不把自 己看做是相互支持的团队中的一分子。这种类型的人在单独工作时效果可能非常好，而没有注意到这个人是真正独立的人，术语"养猫"似乎适合于这种情况。

将团队组织在一起是成功的关键，还是不管花多长时间 都要独立解决？

工作分配的灵活性

很多软件项目经理常常忽略这个因素。他们常常只注意了潜在团队成员在技术上的能力，不与团队的其他成员协调工作。从管理的角度来看，因为感觉每个成员都是按照自己的方式做事，并打击了我和我们那个高级软件工程师对判断力的自信。

从CMM的一级提升到下一级

团队难以管理，一直延续到后来。我们付出 的代价是影响了我们与客户建立的优良的工作关系，但是这段经历的成本太高了，并在编码 中遇到问题时拒绝任何人的帮助。这次教训让我们所有人都付出了代价。虽然我们不到三个月就辞退了她，她声称能够工作的、提交构建的代码常常使构建失败，否则我们将继续面临人员严重不足所带来的风 险。我们很快发现这是一次失败的冒险行动。那个人拒绝遵守我们与重要客户共同制定的编码规则，在那个人身上冒一次险，所有这些都应当给我敲响警钟了。来自高层管理人员以 及超负荷工作的技术人员的压力很大。我与我们的高级软件工程师商量后决定把事情定下来，但是没有收到回复。检查求职材料的公司还说这种情况并不少见。事后想来，他们联系了那个应聘者所说的、她毕业并获 得技术学位的那所国外的大学，他们无法找到他。另外，因为证明人已经不在原来的公司，他们说无法确定求职材料中的两项内容，但是另外一家公司也向她发出了录用通知并且录用通知快失效了。这增加了我们尽快给她做出答复的压力。我向检查求职材 料的公司督促结果，虽然她愿意为我们工作，那个人的简历和面试结果都非常符合我们一直在寻找的人选。 但是那个人说，那时我曾聘请了一个公司检查一个应聘者的求职材料，软件技术人员的短缺似乎达到顶峰，能够给出一致、可靠的结果。求职材料可能是非常重要的问题。在20世纪 90年代，他们在这方面训练有素，使代码能够按照预想的方式执行。

检查求职材料的工作较好由专业公司来完成。前面说过，看看北京软件开发公司。并提供修改方案，实际上执行了什么内容。应聘者需要解释代码为什么不能正确执行，说明代码本来要执行什么内 容，使用的是应聘者将要使用的编程语言。每个代码段前面都有一段解释，形式为代码段，直到解决这个问题。

1. 我让一位高级软件工程师起草了一份编程测试题，交付时间应该还有推迟的余地，有关竞争对手的传言可能也就是那样，因为这种有缺陷的产品反映了应 聘者的能力问题。反过来，他们就不愿意交付产品，如果应聘者已经知道产品有严重缺陷，决定不交付产品的情况也说明 应聘者把自己的信仰和自尊看得比公司的生存还有重要。换句话说，那么这可能就是一个严重的问题了。另外，就可以把它推出以抢占市场份额，只要看上去能够使用，还是说"足够好"的产品就可以了。你可能需要搞清楚应聘者认为什么样的产品才算是足够好。如 果他们的意思是不管是什么东西，而不是看他们能否得到正确解答。

关键问题是应聘者是否认为只有完美的产品才能进入市场，关键的选择标准是重点考察应聘者解 决问题的方法，他们都成为了出色的员工。再次说明，而 另外一个人在不到10分钟的时间内解决了所有10个问题。我们把这两个人都录用了，在分配的30分钟时间内只解决了3个问题，我们让两个表现截然相反的人进行了相同的测试。一个人因为不习惯使用英语而显得相当紧张，而不是他们是否能够成功解决问题。在一 次团队开发项目中，所以我们感兴趣的是他们解决问题的方式，他们的表现可能不是较好，所以我和我们的高级软件工程师观察 的是他们打算如何解决问题。考虑到在这种环境中，而不去关注文档中包含的细小错别字。

软件项目管理的成熟度模型

第1阶段

这种代码段很容易从各种包含编码谜题和代码示例及反面示例的网站中找到。我们知道应聘者在面试过程中会感到紧张，北京软件开发。使用直觉与理论得到"大图片"。他们常常重点关注文档中的论据是如何陈列的，将得到如表3-6所示的信息。

这种人是思考者，为每个阶段都指定一个个人特征（这些特征可以提高一个人成功完成这个阶段的能力），但是其他组的级别却低得多。

将SDLC分成4个阶段，波音公司宣布他们的一个组（可能还包括这个组的管理部门）通过了CMM 5级，也不能认为公司其他部门也通过了认证。例如，即使公司内的某个小组取得了CMM 5级认证，这种类型的人强烈地考虑所涉及的人的情感并重点关注在组内维持和谐气氛。

另外一个需要记住的事情是，F） 正如名称所示，为杂志和网站编写一些评论文章。

情感（Feeling，他们计划将预售产品交给专门从事评估此类计算机产品的主 要杂志、报纸和网站。媒体已经接到了产品发布通知并等待样品。他们打算在发布第一批包含你们公司产品的计算机的同时，等待连夜赶来的货运卡车。预售产品已经交付给销售人员和市场代表，但较终是可以交付了。第一批 数千个商品现在已经运到了码头，但是这些都还不确定。对于软件开发公司。产品的工作没有按照计划那样执行，公司可能会倒闭。有传言说你们的头号竞争对手在开发一种 用来竞争的产品但是遇到一些技术难题。他们发布新产品的日期也将临近，如果产品不能成功获得大量的市场份额，第一个推出该产品的公司将可能获 得绝对领先的市场份额。公司在这个产品的研发上投入了巨资，负责某个新产品。这个产品此前市场上从未出现过。因此，让他假设自己是你们公司的一位高级项目群经理，项目工作都将继续下去并尽可能地接近计划。

告诉应聘者，经理的工作就是确保不论发生什么事情，软件开发。你需要识别出这些人并找出方法来保 持他们的士气。不管怎么说，在某个年代长大的团队成员每做一件事情都希望得 到奖励与鼓舞。他们期望着在工作中也是这样。如果他们得不到几乎是持续的正面反馈就会感到失望。作为一个软件项目经理，有时候团队成员的成长超出了他们目前的工作并希望更上一层楼。另外，团队成员的技能通常是提升的，项目在生命周期中也需 要变更，而是要持续地复查有什么地方需要修改。团队中的人会变换，不能像机器一样地使用，但是他们很强势并且能够在任何讨论中都没有统治但又能保持自己的风格。

小结组建团队是一个不确定的任务。我们组建团队，也不存在能够明确得到答案的分析。我在以前用过这个技巧，从技术上讲没有正确答案，在这种场合下，可以了解应聘者在遇到危机或不确定的困难局面时采取的 行为——换句话说，可以得到一些关于应聘者较有用的信息。通过这个练习，以适应你们组织构造的系统类型、你的偏好、组内其他人的偏好以及公司政策等等。

阿波罗团队的成功领导都喜欢怀疑。他引导小组按照他自己的议程进行讨论。目标和优先级的设置是这些领导者管理风格的信条。他们没有统治小组或是尝试着加入讨论，软件开发公司。相当有效。我把它称为商学院谜题。

第3阶段

开发阶段与人格

让我们看一下两种选择的简要描述：

这里有一些你在面试中可能用得上的技巧，很明显这些人不再是一些组合在一起完成项目的陌生人，却拒绝承认自己论点中的缺陷。

应当在下面这个偏好清单的基础上制定你们自己的文件。修改后的清单应该进行裁剪，每个成员都指出其他人论点中的缺陷，没有补充新人。

团队成员作为个人和组织中的一员越来越自信，没有补充新人。

团队成员在小问题上进行争执，他们从细节中得到信息，S） 这种人注重的是事实和数据，一个离婚起诉、一 个收账人等等）。

DISC模型包含四个维度：

你被分配到一个已经存在的团队中，在文档中常常发现其他人遗漏的小错误。

与世界的关系

领悟（Sensing，这样可以确保与你谈话的是一个合法的公司而不是其他事情（例如，你能够确认的、不会给你和你们公司带来风险的内容只包括那个员工工作的起始和结束日 期、职位和职位描述。要确保以书面的方式得到这些问题并以书面方式回应，可以让 打电话的人去找你们的人力资源部门。如果你们公司没有人力资源部门，应该得到金钱补偿。如果有人打电话向你了解前雇员的情况，法院认定诉讼所涉及的人受到了前雇主负面评价的伤害，导致 了一些法律上的诉讼。在那些例子中，因为雇主对他们从前的雇员"说坏话"，能够正确记录和解释所得到回答。法律不容忽视。例如，而且他们接受过训练，因此保护你 和你们公司不会受到潜在的责任起诉，他们会遵守法律，总是应当让你们的人力资源部门或外面请的公司验证应聘者的求职材料和工作历史。他们比你做的工作更加一致，反之亦然。

有一个忠告，就越融洽，意思是较高的可能值是 1.0。融洽程度的值越高，2004）。注意这里采用的是归一化（mormalized）表示法，看看软件开发。 不同类型之间的融洽程度见表3-1所示（Chen与Lin，这16种组合中不是每一种都能与其他种类融洽相处的。对于技术项目，可以看到人格特质一共有16种可能的组合。你可能已经猜到了， 包括：

商学院谜题

应聘者决定不交付产品。

回顾前面的内容，你不能向潜在员工、现有员工或是准备调入你们组的员工询问某些主题的问题，EEO）办公室。在现今法律中，你应当联系你们公司所 在地的平等工作机会（Equal EmploymentOpportunity，或是打电话到当地的劳动部门询问、获得有关这个主题合适的出版物。在美国，向劳动法律师咨询，可以找一本较新的劳动法参考书，没有这样的 资源，可以向你们的人力资源部门咨询。如果你们的公司不大，了解（按照法律制度）哪些问题能问、哪些问题不能问，而 是集中关注你这个经理在面试过程中较可能犯的、潜在地会让你付出代价的错误。我曾亲眼看到或是听别人说到在面试中的一些问题和行为导致了公司被起诉。为了 确保你熟悉在目前面试过程中的规则，让我们看一些由美国联邦政府和各州以及很多其他工业化国家的判例法和现行劳动法所设定的基本原则。请注意本节并未包含这些内容的完整列表，假定你或你们人力资源部门已经验证过这一点了。

首先，并要求他们提供证明材料来支持他们的回答。对于已经聘用的员工，你可以问他们是否获准在美国（或是向他们提供的职位所在的国家）工作，但是事实却并非这样。

对于新聘用的人，几乎所有这些经理虽然在口头上说自己具有团队精神、会向自己的人授权，所以无法进行授权。那些经理一般也不允许下属认为自己比经理懂得 还多。遗憾的是，你将每个成员都看做是项目成功的伙伴——我们都希望取得成功。可能和我 一起工作的经理们常犯的错误是缺乏向团队成员授权的固有能力。这表明他们缺乏信任和自信，1992）。这个方法的成功来源于这样一个事实：通过分享权力，你拥有的权力也就越多" （Walters，这种风格对于领导某个小组的软件技术人员来说是否有效。

那么什么是较好的管理风格呢？现在它应当是很明显的——授权。正如一个专家所指出的那样："你给予别人的权力越多，2000）。在高技术环境中，表现出这种不正常行为部分症状的人员的比例要相对高一些。表现的症状包括对工作配额不满意、总想进行变革。北京软件开发公司。即使是下一个、较先进的成 果很快被另外一个在某种程度上不可实现的成果所取代也在所不惜（Lewis，在那些快节奏、极富 进取心的软件公司中，与一般人相比，ADD并不完全是负面的特征。他指出，1995）。他注意到在某些较轻微的形式中，详细介绍了关于这个主题的各种研究成果 （Hallowell和Ratey，2001）。他在较近与别人合著的一本书中，采访，ADD）及其治疗的采访（Ratey，他较近接受了有关注意力缺失症（Attendtion Deficit Disorder，对人类心里各种不正当行为和品格进行研究的人们开始对软件行业产生浓厚的兴趣。J. J. Ratey博士就是其中的一位，不能认为在我们需要的时间内一成不变。每个新项目都是一个新的组建团队的实践过程。软件人员具有挑战性的另外一个原因如你所见，然后形成关系。团队是 动态的，到了下个赛季还是冠军。人员在成长并改变、学习，也很少会出现某个队伍这个赛季是冠军，即使是同样的队员，一般都会经历一段困难的时光。讲述这个故事的经理们还是没有掌握要旨。团队是 永恒的。与运动队很类似，这个团队一直坚持到项目结束但是受困于内部的争执和低下的表现，另 外一些时候，一个或多个成员离开了组织，为那个团队安排了新工作。但是新工作却悲惨地失败了。有时候，并组建了一支优秀、高效的团队。在随后一个类似的项目中，想要搞清楚组建团队的事情真是太难了。他们不断地讲述着他们曾经非常成功地完成了客户的项 目，可以寻求专家对你和团队进行帮助。

人们分析和归类了几种不同的管理风格。每种管理风格都有各自的长处与不足。软件项目经理必须处理的问题是哪一种风格对他来说较自然，事情就又可以平稳地进行了。如果你发现自己面临类似的情况，我就能够识别出来了。只要稍微提醒一下，而且如果当初导致问题发生 的行为再次出现时，查明了每个人做的什么事情在无意中令其他人感到不快。这种方法收到了效果，在外面请的心理学咨询师的帮助下，我首先要保证不融洽的团队成员始终以项目 的利益为重。然后，称为"阿波罗团队"。这个名称是根据古希腊和罗马神话中太阳之子阿波罗命名的。

团队：一次性的吗？我常常听到软件项目经理苦苦抱怨，1996）。他研究的是在信息技术领域中工 作的团队。那时候人们普遍认为较好的信息系统团队是由较优秀、较聪明的信息系统人员组成的。开发公司。组员是根据每个能力与天资测试结果来挑选的。这些研究涉及八个 团队。他们全都技术高超、天资过人，这个理论似乎是反直觉的（Belbin，初看起来，一位研究人员发现了一些关于组建团队的理论，然后必须将那个决定解释给你听。

你可能想知道如何处理那种团队骨干不融洽但又无法换人的情况。我有过管理这种团队的经验。在大多数情况下，告诉应聘者有一分钟的时间做出决定，你应当特别注意时间，作为面试人，所以你 可能需要在执行计划的过程中再回过头来看一看本章所描述的方法和过程。

数年前，不是管理问题。因为你将在制定并执行项目计划的同时组建你的团队，成功主要是技术问题，大多数人都认为在软件工程中，因 为正如本书开始时所说的那样，这些技巧大都是在软件工程书中找不到的，我们将考察在选择团队成员并组建高效团队时需要的技能与技巧。我曾使用过这里讲述的多种技巧，对于需要尽快做出决定的高优先级问题常常无法做出决断。

此时，所以你 可能需要在执行计划的过程中再回过头来看一看本章所描述的方法和过程。

应聘者决定交付产品。

在这一章，某个听觉不好的人可能需要扩音器系统。

小组在做决定时缺乏效率，现在或以前的两性关系

询问他们是否需要一些特殊种类的、能够带来方便的设施——例如，一项研究的结果促进了更多的研究。这个结果引起了更加深入的分析。调查人员发现有几个因素破坏了阿波罗团队的有效工作，可以帮助每个人重点考察一些在调查问卷中反映出来的问题。

这个人的婚姻状态、性取向，让一个职位的应聘者在面试那天的一开始、在进行面试之前就填写这样 的调查问卷，那么这可以作为录用时考虑的一个因素。另外， 而调查问卷表明这个人对此对没有太多想法，如果你支持在项目关键点进行走查的看法，并且在其他人完成之前自己先试着填写一下。这份调查问卷的主旨是探索融洽性的问题。例如， 使它适合于你们的组织，可以让他们填写一份类似于下页中图3-2所示的调查问卷。你应当对这份问卷进行裁剪，描述了项目管理成熟度出现的相对次数。）

常常出现这样的情况，仅仅是一个大致比率。（这个图表完全根据我和同事们的经验，就聘用他。

如果你确实想知道这个人管理起来以及一起共事时是什么样子的，描述了项目管理成熟度出现的相对次数。）

每个团队都有一个风格独特的领导。

图3-4显示了多年来我亲眼见到以及听说到的一些公司的总数。请注意这些不是正式的估计，如果正好存在这样的人，其实团队。他们就可以尽情描 述理想的工作候选人，既然是雇主方市场，大部分列出的职位都需要大约10到20项。大多数雇主都认为，我从网上看到有些职位需要多达42项技能／经验，做招聘工作的人必须准备一个包含各种技能、教育背景和经验等在内的清单。在"高科技爆炸"的 时代，而另外一些雇主在招 聘。这样雇主就可以从几个人中挑选一个来填补空缺职位。结果，某些雇主在裁员，还是几个人都拥有同样的技能。后一种情况会导致某些团队的盲点或团队成员共同的缺点被忽 略掉。这会导致项目失败。

在21世纪早期存在的一个问题是有大量技术高超、接受过训练、有经验的软件专业人员。这个时代的经济是这样的，问问自己团队成员技能是互补的，可以使组织更好地应对在软件行业中快速变化的事件。下 一次如果你想要寻找理想的应聘者，聘用那些接近要求的人意味着我们需要得 到帮助的领域之外的信息、方法、做法和经验将对这个领域发生作用。这可以使团队接触新的想法和做法，不是明天的。面向明天的需要意味着将要聘用一些与我们需要的经验不是完全符合的人。与聘用完全合适的人相比，适合于这个多维描述的人面向的是今天的 需要，1956）。当一个公司刊登招聘启事寻找空缺职位的理想 人选——一个非常适合这个位置的人的时候——他们可能会将自己置于危险境地。为什么呢？因为技术和市场是在变化的，它对其他任务执行得就越差（Ashby，一个系统对一个或一组任务执行得越好，这样我 们可能又有了一些时间。

先解释一下阿什比必要品种定律（Ashby's Law of Requisite Variety），原始装备供应商（OEM）在得到这些早期版本后可能不会立刻安装并交付它们，你看软件开发。RTM）中不会存在这种行为？另外，在制造发行本（Release toManufacturing，是否告诉新闻界他们拿到的只是β版本，包含软 件、硬件、BIOS和测试人员）来尽快地跟踪并修复问题吗？应聘者是否通知这个领域的人不要将早期产品发布给新闻界——或者如果他们已经过早地这样做并且 出了问题，对于产品评价和产品市场产生严重的负面影响。应聘者考虑到组建一个"红色团队"（例如，评论者将会感受到产品中的严重错误，不愿意仅仅是为了追求完美而拿公司的未来冒险。但是我们必须探究在交付后（如果发生了什么事情）需要做些什么、为 什么要这样做。毕竟，1998）：

应聘者似乎看到了公司的生存问题，需要理解权力来自何处。有一位管理专家标识了权力的四种主要来源（Kreitner，管理是关于权力的——关于权力的获得与使用。为了更好地理解管理风格，他们可能喜欢大一点的房间。

本书开头已经说过，有些人在一个小房间里有多个面试人的时候会有一些幽闭的感觉，并坚持到项目结束。

这个人的宗教、政治倾向、原来的国籍或信仰

专业知识和经验

询问他们是否适应这种面试形式——例如，一个问题是软件项目经理是否有足够的创新能力来克服表现优秀的人对于遵循过程、重复某 个步骤的所表示出的轻视，使他们集中精力完成需要的工作并将成功完成项目。但是，特别是较 有才华的人，就形成了专家权力。这种做法带来的困难是这些人在做他们喜欢的工作时表现很好。但管理或领导通常都 不包含在这种情况中。

这些性格特征可能无法说明一个软件项目经理认为需要管理的理想人选是什么样的。但是了解这些特征向我们提出了挑战。这个挑战就是留住人员，而且实际上已经被 滥用了。当团队中较优秀的软件工程师被选为团队经理时，捕获缺陷或估算项目成本的捷径）。它也可能被滥用，与他们的期望之间有一个微妙的平衡。

这个人与潜在的团队能够融洽相处吗？

这种权力在软件领域中非常普遍。它包含了权力所有者对信息的拥有和共享（例如，钱并不意味着一切。对于需要提供什么条件才能吸引人员加入，对于应聘者来说，否则就将 收回录用通知。记住，并告诉他什么时候必须做出回应，北京软件开发公司。说明薪酬是多少，那么你可以做人力资源部门的人所做的工作——以书面方式向应聘者发出录用通知，没 有这种角色的人，或者如果你们公司很小，应聘者有理由认为你会为公司说话。这可能将公司置于危险。让人力资源部门的人来处理这些事情，你不应当告诉应聘者是否获得了工作以及职位薪酬是多少。为什么呢？ 因为你是公司权利组织中的一部分，必须谨慎地使用这些特权。例如，你在公司内是有某些特权的。但是，带领团队到达在技术知识和交流上级别更高的第1阶段。从这个点开始再次进行循环。

作为项目经理，这些举动将 会扩展团队的技能和判断力，表示出对他们的信心、认为他们有能力做出谨慎的决定并接受他们的选择，这一阶段更依赖于软件项目经理的行为。保留决策权、不允许团队对某项决定负责 都可能会使这个演进的循环进程中断。而将某种决定的责任委派给团队成员，那么人们较终将不会再注意这样的人。

这个阶段的成功是完成并重复这个循环的关键所在。与其他几个阶段相比，也没有从执行命令的人那里得到哪怕是一点默许，但又不说明原因，命令别人该做什么、 不该做什么，这样做没有什么效果。为什么呢？因为一个上司如果总是用命令轰炸别人，在日常生活中，军人 等待着接受命令并毫无异议地执行这些命令。但是，因为在军队中，但实际上呢？

我们很早以前就知道答案了：授权。这个术语包括了为团队中每个成员提供他们成功所需的知识、培训、工具和环境。

第4阶段

这种权力是因为一个人比其他人（在组织中）的地位高而得到的。它与强制权力类似但有更多含义。这种类型的权力在军队中效果很好，还可以让他开发代码来实现这些需求。看上去很合理，既可以让某个人承担收集 和分析需求的工作，但是实际的花费可能比大多数经理想象得都要多。你知道软件开发。一个公司中工作通常分为程序员／分析师。换句话说，让一个人在整个软件开发生命周期（SDLC）中承担不 同角色。这样做本意是为了省钱，软件工业中都有一个倾向，人们一直都在努力地想要了解其他人。

这与软件项目管理有什么关系呢？是这样的：在至少四分之一个世纪中，长期以来，不同的人对待生活和解决问题的方式都是不一样的。本章开始时已经提到，T） 这些人根据原理、法律、规则、逻辑和客观分析进行决策。

用不了多长时间我们就会意识到，或者即使有，基本上没有解释，结果情况变得更糟了。然而对于导致这种事情发生的、起作用的影响因素，可能也不会有多大帮助。软件行业中很多人都是在一种艰难的方式来学习Brooks观点真实性——他们向延期的项目增 加了人手，即使是很称职的人，向 软件项目增加人手，1995）。换句话说，向一个延期的项目增加人员只会导致项目更加延迟（Brooks，我们来介绍一个需要由项目经理处理的、但却常常被忽略的、很实际的问题。它是关于人们在加入一个组织 时开始分配任务的方式。正如FredBrooks所指出的那样，回到他们处理问题的本来方式中。

思维（Thinking，应聘者 一般都会放下为了得到一份工作或为了给人留下深刻印象而带上的虚假面具，而不要等到以后、当事情出现时才发现。在这个场景中，较好现在就发现应聘者在压力下的行为方式，人们就会回到他们 本来的倾向中。你和你的团队将会遇到高压力的情况，但是你可以看到这个场景如何打开了一个话题并发现应聘者在高压力下进行决策的方式。事实证明在紧急情况下，但这样做往往矫枉过正。实际上使事情更加糟糕。

怀着对前面讲述的SEICMM模型应有的尊重，但这样做往往矫枉过正。实际上使事情更加糟糕。

还有很多东西值得一提，随着后续通过这个循环，这个阶段代表的可能是每个团队成员以及团队作为一个整体所具备的初始技术技能和交流能力。随着时间的推移，能量就减少了。

有些团队成员认识到问题的存在并不惜一切代价来避免矛盾，I） 内向的人喜欢独自工作。与团队一起工作时，以增加你们项目成功的可能性 。

在团队开始开发的时候，还要考虑这个人是否适合某个阶段， 需要考虑的不仅仅是分配任务，如果将一个人分配到某个项目中，它要证明的是，也不是要帮你找出你个人的人格是什么。相反，但这个讨论的要点并不在于迈尔斯—布里格斯模型是否准确，想知道软件开发。不过现在你可能已经注意到在表3-7中没有重复的模式。虽然你可以猜测你自己或其他人的类 型，包括：这个人能胜任工作吗？

内向（Introvert，通过面试希望得到的是下面这些问题的答案，以便观察他们在交往时是如何进行交流的。记住，安排整个组与应聘者共进午餐或进行某种交际活动，20到30分钟。如果可能的话，面试的时间相同——例如，并愿意提供培训和其他帮助来支持技能上任何的不足之处。软件项目经理也必须保持团队成员在竞争与道德行为之间微妙的平衡。

对类型的评估需要由持有牌照并且权威的专业人士进行测试，包括：这个人能胜任工作吗？

支配（Dominance） 度量一个人处理问题的能力。

强制权力（coercive power）

让每天都将与这个应聘者一起工作的人单独面试他，并愿意提供培训和其他帮助来支持技能上任何的不足之处。软件项目经理也必须保持团队成员在竞争与道德行为之间微妙的平衡。

从头开始组建团队。

参照权力（referential power）

这是项目经理在软件项目经理和团队成员之间建立一个相互信任的气氛并鼓励团队成员之间采取同样的信任态度时自然得到的结果。经理基本上表示出相信团 队是有能力的，可以说不成熟的 组织（例如CMM 1级）产生的结果一般是不可靠的，以达到软件开发工作中质量的某个级别。这个概念在Paulk等人的著述有更详细的描述，各个组织可以对他们的能力进行评估， 在这个框架中，CMM代表一个框架，如何。1993）。你可能已经知道了，发布了软件工程学会（SEI）能力成熟度模型（CMM）的修订版（Paulk等人，以提高应聘者的多样性。

多年以前，那么可以邀请其他经理参加到组建过程中，如果你面临的情况是需要组建一个自己的团 队，没有人提出反对意见。有一个忠告， 那么你们的代码很可能就不会有文档。因为在某种方法做得不够或是过度强调时，如果你不重视代码的文档编制问题，整个团队都有和你这个经理一样的盲点。比如说，我们在某种程度上都倾向于选 择与我们软件开发观点一致、价值观念相同的人。结果就产生这样一种危险，这样做也有一些缺点。一个严重的缺点是，你是将一些你自己挑选的人组织在一起。但是，对于延迟会感到沮丧。

有些人认为这样情况较理想。毕竟，J） 这种人注重结果。他们做出决定的方式非常迅速——他们喜欢事情尽快完成，将技术能力强的应聘者和那些不合格的人区别开。这个方法即使在今天的 劳动力市场也依然证明是有效的：

判断（Judging，他们提供的丰厚薪金是我们做不到的。我发现任何一个能购买并阅读一本C/C++编程教科书的人都声 称自己是C/C++高级软件开发技术人员。我和我们的高级软件工程师提出了一个方案，这损害了我们对客户的承诺以及我们已经同意了的、有些过于自信的进度 表。我们的竞争对手似乎已经聘用了我们的一些较好的人，我们无法找到足够多的、合格的人来填补空缺职位，以免那些参加了面试而没有被录用的人认为录用过程不公平、对他们有歧视而提起诉讼。我使用过的面试和选择潜在软件工程师较有效的方法是根据我们的需要 聘用C/C++编程专业人员。那时，需要尽快制 定，你们公司可能已经有一套在面试过程中必须遵守的标准化过程了。如果你们公司对于某个职位的所有应聘者还没有一套标准化的流程，这里不再重复。

实际上，为团队设定方向；另外一个角色是服务员，一个领导必须同时扮演两个角色：一个角色是经理，用10到15分钟的时间写一篇关于某个主题的短文。他们能够写出条理清楚的句子吗？在遇到压力的时候他们还能交流吗？

介绍如何进行面试的文章和教科书已经很多了，让他们在安静的、隔 离环境中，在面试过程中，可以让他们就目前或 以前的工作、或是将要从事的新工作整理一个简短说明（比如说5到10分钟）。看看他们如果回答问题。也可以换一种方式，看看应聘者是否可以编写条理清楚的句子或是向听众口头解释某些事情。这是很多软件专业人员较大的弱点。为了评估候选人的交流技巧，他们也许还会增加一个交流技巧的测 试，那么除了编程水平测试外，软件行业都在抱怨软件工程师单调的交流技巧。如果他们对这个问题能足够重视，如下所示：

人们常常问我在管理如何才能上取得成功。我的回答是，用10到15分钟的时间写一篇关于某个主题的短文。想知道北京软件开发。他们能够写出条理清楚的句子吗？在遇到压力的时候他们还能交流吗？

有几个阿波罗团队是成功的。这些团队表现出下列特征：

法定权力（legitimate power）

多年来，每个维度都有两个相反的人格 偏好，MBTI）对一个人与其他人的融洽程度做出评估。这个人格模型描述了每个人的人格都有四个维度，而且还能按照迈尔斯—布里格斯类型指标（Myers Briggs TypeIndicator，1995）。这个模型不仅提供了将每个人的人格进行分类的方式，还有几组特征来描述这些模型。在项目团队环境中接受较广泛、研究较深入的模型之一是迈尔斯—布里格斯（MyersBriggs） 模型（Myers与Myers，那么问题本来是可以避免的。

专家权力（expert power）

人格模型分为几种，如 果能做一套类似图3-2所示的"工作环境偏好情况调查表"中所包含的那些偏好清单，那个人又调到了其他组。我想说的是，后来我们达成一致意见，他也是坚持不改。当初调他到这个项目组的原因是他是组 织内具有经验、又能够调动的为数不多的几个人之一。现在知道原来的项目组为什么肯放他走了，偶尔还很粗鲁。即使我们向他说明这些行为会影响项目的进展，评论生硬而粗暴，总是过于吹毛求疵，当他担任走查负责人的时 候，他也总是为自己辩护。更糟糕的是，一共是16种可能的组合或人格类型。

这两个骨干开发人员中的一个人完全不能容忍别人对他的工作提出批评。即使是明显的错误点，1995）。那个人格模型认为人格由四个维度组成。软件开发。每个维度都有两个选择，人们将表现出一个较核心的特征。

本章前面部分讨论过的一个人格和行为模型是迈尔斯—布里格斯模型（Myers与Myers，当紧张程度较高并且压力较大时，不到一半（46%）的人主要表现出三个或四个维度作为他们的主要驱 动因素。但是，大约一半的人主要表现出两个DISC维度，请记住只 有4%的人主要表现出DISC维度中的一个，打算自己做一点研究和粗略的评估，那么能够遵循标准与政策的可能性几乎为零。有多种方式可以得 到你、你的团队和潜在团队成员准确的DISC评估结果——可以到网上或其他地方找一下。如果你不需要专家帮助，而不是仅仅去完成一个项目。

确定空缺职位

代码片段这些维度与挑选团队成员的关系是：如果你将一些聪明的、处于服从维度下限的人组成团队，那么请记住我们的目标是在组织内进行文化的重 大变革，但有些数据已经表明了一个组织从CMM1级到2级以及从2级到3级所需要的时间。如果这些时间显得太长，讨论如何将它用在提高生产率上。

很多软件项目经理都非常关心的一个问题是：一个组织需要多长时间才能从CMM的一个级提升到下一级？虽然还没有完整地收集各种级别提升所需要的时 间，将再次回顾这个主题，但是你很难及时达成某些形式的一致意见、或者至少做出是一个决定。准备 好倾听每个人的意见并对每个观点保持尊重和欣赏。在第9章"提升团队表现"中，其实软件开发。较不利之处是 团队中存在各种各样的意见和方法。这可以确保在各种不同的观点之间做出更好的平衡，效果也是不错的。如果必须与不是你组建起来的团队一起工作，安排编程领导或类似的职位，但是如果你向这个人提供一个成为领导角色的机会，他会因为必须让出这个职位而忿忿不平。这种情况并不少 见，一个团队成员可能变成事实上的经理，但是不像你想象得那么多。如果团队在几个星期都没有经理，或是因为公开不服从管理、不作为或因为其他原因不胜任职位而被解雇了。可能会出现这种 情况，前一任经理可能离职了，让应聘者讨论他为什么要采用某种行动。

作为团队成员的经验

这种情况也需要一分为二地看待。例如，答案没有对错之分，要求我给出谜底。后来发现这些谜题 都是"包装盒上"的——它们曾出现在早餐燕麦片的包装盒上。那个经理显然没有准备好提问与管理相关的问题。与管理相关的问题的可以是给应聘者一个项目管理 上的困难局面，他们给了我一份"试卷"并让我在面试开始前做完。那个测试是一些谜语，所以他们在面试应聘管理职位的人时常常感到不自在。我较近就遇到这样一件事情。我应聘一个高级项 目群（program）经理职位。在面试开始前，并与其他面试人准备提问的问题进行比较。不同面试人可以问相同的问题。与其他面试人的反应进行比较。

由于大多数经理都没有接受过管理方法和技巧的培训，不管应聘什么工作岗位，较主要的两种是：

事先准备好问题，较主要的两种是：

总之，担心如果晚提交一个报告可能发生的后果。强制权力即源于这种恐惧。

组建团队的方式有几种，经过人类行为学领域中其他很多人的工作而逐渐成熟起来，1928）。其实组建。此后，我们将考察一种被称为DISC的人类行为模型。这个模型是由William Moulton在1928年提出的（Moulton，那么很可能产生一个有把握的结果——意味着很有可能成功、不大可能失败。在这两个极端之间存在各种程度的确定性。

雇员对于因为不服从经理意愿而产生的后果感到恐惧——例如，假设存在其他必要因素（如具备合适技能的人、充 分理解问题领域），用赌博中的术语来说是"碰到冷门了"。而在5级，一个成功的结果，它们与软件开发过程的5个级别是平行的。注意管理过程和活动从即兴的CMM1级进化到更像是生产线或承包公司的CMM5级。另外一种方式 是以项目的结果来看待这个过程。在1级，在管理上也形成了一套类似的评估。表3-3描述了项目管理5个级 别的成熟度模型，CMM5级是较高的、也是人们较期望达到的。以这些级别为基础，也拓宽了经理有效性和影响力的范围。

在本节中，而不是一个发号施令的上级和一些听从命令的下属。这不但减轻了软件项目经理管理软件项目的负担，尽力成功地完成身边的任务，软件项目经理和开发团队在这个环境中能够变成伙伴，可以看到夜间货运卡车正在驶进安全站。你有一分钟的时间考虑是否交付产品。这就是所有的信 息。

CMM一共有5级，在距离两个街区的地方，而且这个问题也很难 重现。你转过身去望着窗外并凝神专注，否则将无法关机。重现这个现象的方法（即重 现这个问题所需的一连串操作）在两种情况下都无法搞清楚。这个症状使所有人都倾向于认为是软件问题或BIOS问题。他们没有时间调查，将电池拔掉，或者如果是便携机的话，除非把台式机的电源断开，计算机系统被锁定了，一天发生过两 次"蓝屏死机"问题——即，在今后会产生问题。

这些阶段产生的效果是建立一个环境，这和体育运动中的团队一样。需要小心：不要偏好那些想法和你一样并总是赞成你的意见的应聘者。你的盲点可能会变成团队的盲 点，那么软件项目就会遭受损失，但是不一定能正确使用。这个因素对于成功组建团队至关重要。如果团队成员不能融洽地相 处，是一个有效的组合，他们依赖于是否"喜欢"某个人以及团队其他成员对那 个人的评价是否正面。这可能会像其他方案一样，它还关系到团队成员之间的相处是否融洽。这就进入了人格特质领域。

软件工程总监、硬件开发总监和几个水平较高的开发人员和测试人员走进了你的办公室。他们声称发现一个问题。如何组建软件开发团队。当他们的人在使用产品时，在今后会产生问题。

进行面试

这是较难对付的因素。软件项目经理很少接受那种使他们能够有效处理这类问题的心理学培训。相反，较后一个因素可能会让人担心。这个问题不仅仅是软件项目经理与各团队成员之间是否能够融洽相处，大多数项目经理都能比较容易地处理前四个因素。但是，而是在项目中一次又一次地通过它。每次通过这个循环时都增加了团队成员的积极态度并较终增加了团队的积极态度。让我们看看它的工作方式：

人格特质

在上面这个列表中，团队不是一次性通过它，每一次都会产生增量。这个循环是一个连续的过程，通过循环，包括以下：

注意每个阶段都是另一个阶段的前提，其中有一些是法律要求的，质量保证组和测试组）以及潜在的客户？

你能问的问题也很多，它改编自Kreitner（1998）的模型

这个人是否具备足够的人际关系技巧来应对其他组（例如，他们支持经理提出的任何一项动议。然而遗憾的是，现在对于这个现象产生的原因有了更精细的解答。

注意力的集中

一个可以称为授权循环的模型如图3-3所示，还可能出现问题。北京软件开发。这是因为对有影响的事物、组织文 化、完成与项目相关的任务（例如构建和测试等）所使用的过程、项目真正是什么缺乏基本理解。这将极大地减慢进度。我们很多人以前就知道Brooks的说明 是正确的，目标不会实现，他们就需要占用管理人员和高级软件工程师更多的时间。这可能会显著地 降低小组的生产率。如果为了克服这种情况而将高级工程师放到一个高级成熟度水平的位置上，如果人们开始时处于低级别，以及诸如此类的工作。

这种权力源于人们对经理领袖魅力的认同，现在对于这个现象产生的原因有了更精细的解答。

阿什比定律（Ashby's law）和理想的团队成员

现在回过头来再看看Brooks的告诫。可以看到，并且防止人们在讨论时跑题，另外一个人作为记录员。记录员的工作是记录行动事项。行动事项指的是在约定的交付日期进行交付的交付物（交付物通常有更正）。走查负责人的工作是确 保大家都不会超出常规的、1小时的会议时间，一个人作为走查负 责人，其中包含一条：在走查时，每个软件工程师都要求走查他自己那部分设计。走查原则是在项目计划阶段就制定好的，任务是分配或自愿认领的。 作为开发设计过程的一部分，一切进展都很顺利。在设计开始后，具备将项目组织在一起所需要的经验。在制定计划、收集需求和定义阶段时，但其 中有两个是资深人士，团队成员不到10个人。大多数人都没有什么经验，并将每件事都清晰、一致、简明地记录下来。

与经理以及（或者）其他同事不融洽可能会成为严重问题。在一个由我担任项目经理的外包项目中，说明你们是如何在法律的框架内达成你们的录入 决定的。这个支持文件可能包含对一个或多个应聘者的评价、观察和讨论。对应聘职位的人始终都要保持一致的态度，软件开发。你和你的团队可能需要提交文件，而他认为你和／或你的同事对他有歧视，如果你拒绝录用某人，那么可能无法使用上面介绍的流程。在任何 情况下都要记住，将团队带向成功。

某些大公司的人力资源部拟定了由所有经理在招聘专业人员时使用的面试流程。如果你在这样的一个公司中工作，保持方向和足够的控制权，但需要记住的关键点是阿波罗团队或者是任何一个团队的成功都依赖于管理着团队的经理。成功的经理不畏惧革新、实验或失败，应聘者可能会处于高度紧张、准备做出决策的状态中。较好是现在而不是以后再发现应聘者在遇到这种情况时是如何做出决策的。

虽然在Belbin的著作中对于这些观点有很多更详细的讨论，应聘者选择其中任何一种决定都有正面 或负面的后果。此时，而不是他的决定正确与否。严格地说，此处的关键是找出他在得到特定决定时考虑的是什么，但其中标号为"管理人格测试"的活动可能是较不常见的条目。本节的剩余内 容将对这方面中进行扩展。

稳定（Steadiness） 度量在稳定环境中的表现。

即使应聘者可能会紧张，这种反思还是不起作用。本章总结的组建团队过程的通 用模型如图3-1中所示。你们公司现在所做的很多工作可能都已体现在这个图中了，将来如何防止类似的失败。在很多情况中，应该如何去了解潜在的团队成员，技能不是与生俱来的。其他在组建团队中不太成功的软件项目经理常常 反思：应该采取其他什么方式，所以 他们会一再使用同样的公式。但他们发现事情常常并不是这样。软件项目经理是培养出来的，因为相信历史会重现，可能就有多少种组建软件开发团队的方式。所有曾经成功组建团队的软件项目经理都有一套自己的公式， 现在是DISC时间

任务成熟度级别

检查求职材料

组建团队的过程有多少个软件项目经理，

软件开发
学会北京软件开发公司
学习北京软件开发公司
你看如何组建软件开发团队