成为团队领导者（二）

4在领导的同时进行训练

在领导TSP团队的时候，主要挑战是激励人员完成优质的工作。因为你和团队成员的许多交互都与你完成工作和更好地完成工作的方式有关，因此你常常会觉得自己像是培训师而不是管理者。这就引出了下面的问题，你如何在领导人员的同时来培训他们。显见的答案是同时完成两份工作。然而，这是不可能的，原因有两个。第一，针对团队领导者和培训师必须要做的工作，你没有那么多时间。第二，作为团队领导者，团队成员必须把你当成是团队领导，而不是培训师。

团队成员可以把团队领导者看成是培训师，把培训师看成是导师和知己。即使你想要这么做，你也不会完全接受培训师的模式，至少一开始做不到。但是，如果你开始像个培训师那样思考和做事的话，那就要表达出对成员们的兴趣十分关心的样子，询问他们的个人目标，那样手下也会慢慢觉得你就是培训师。那么你要如何做到这一点，同时还有时间领导项目呢？回答这个问题要涉及领导任务、培训任务以及整个培训态度。

4.1领导任务

尽管有许多因素对程序员的行为都会有所贡献，你，即团队领导，对人员的要求以及指导和奖励他们的方式，会比单位里其他人对其行为的影响更甚。作为领导者，你必须满足团队的承诺，组建起团队的能力，有消息及时通知管理层。你必须设定团队的步调，建立并维护高标准，支持和保护团队。要做到这些事情，就必须委托大部分传统意义上的管理层职责。

角色管理人员可以帮助你准备每周团队和管理层会议，评审团队成员的数据，处理团队的控制和支持任务。如果单位里面有支持小组，他们也能帮助你。质保小组可以提醒你质量控制问题或者计划上的疏漏，过程小组可以分析团队的数据，提供过程改进指导。要成为培训师和领导者，就必须花时间和自己的人员待在一起。这意味着要借助任何个体或小组的力量来帮助你运营项目。

4.2培训任务

培训的主要任务是聚拢人才。培训师不能笼统地看待团队成员；他必须以个体来对待他们。这需要每周在每名开发人员身上都投入时间。对于一支具有相当规模的团队，这需要大量的时间投入。

在我的第一个项目中，我有八名开发人员，要设计一套复杂的密码通信系统。因为我刚到单位里来，以前没有做过这样的系统，有许多内容需要学习。我通过提出问题开始。我每天都会和每一名开发人员交谈，弄清楚他的工作和方法。那样如果有人有技术问题的话，我立刻就会明白，是因为被他人的工作阻碍了呢，还是有个人问题了。几周以后，我了解到开发人员的强项、弱点和兴趣。现在，我理解了如何完成自己的工作，我也掌握了每名成员需要帮助或支持的地方。

如果你每天都投入时间和每名开发人员在一起，你就会了解谁会有问题，而且还会理解哪名成员分配不当或者可以迎接更大的挑战。只要团队规模不太大，这些日常的讨论就不会花费太多时间。但是，它们会赋予你成为高效培训师的第一手知识。

要帮助手下改进，那就要利用好每名开发人员的技能。要关注开发人员当前的任务，认识到改进是渐进的。期望增量式改进，奖励每一次成绩。要把注意力放在激励上面；它是你所拥有的最有效的改进工具。不要只把注意力放在新加入的或者需要帮助的开发人员身上。你还要和专家以及那些以未知的规律做事的开发者交谈。询问这些开发人员他们的工作和方式。当他们出现问题的时候，要问清楚替代方案，以及他们需要指导的地方。你从这些人身上可以学到很多内容，通过询问问题，你也可以刺激和激励他们。通过回答问题，他们学到的内容要比你从问问题的过程中学到得多。只要你愿意问问题，乐意学习，那样即使在培训最优秀的开发者的时候，都不会有困难。

4.3培训态度

对于培训态度而言，决定性测验是你处理升职的方式。假定首席设计师告诉你，他愿意担任团队领导者。那么，如果你听说团队领导者要开辟另一个部门，假定你认为他是优秀的候选人，那么你会推荐你的首席设计师吗？如果没有，那么你的行为就是团队领导者的行为，而不是培训师的行为。既然你不想失去这名开发人员，如果你提升他的话，很快大家都会知道你提升了自己最优秀的手下。那样你就可以毫不费力地得到更多更优秀的人才。

成为高效培训师的关键点在于要同对待任务一样地对待手下。虽然看似不太现实，但它实际上是可以赢取开发人员忠诚信任的唯一方式。他们都是聪明人，很快就能弄明白你的兴趣和优先考虑的事项。如果你的首要优先事务是任务，他们会清楚，不能信任由你来照顾到他们的兴趣。但是，如果你真正关心他们的发展，他们就不太可能会担心自己的事

业，会更好地将精力投入到工作当中。这正是产生优质工作的源泉所在。

5前路挑战

现代技术发展趋势需要领导和培训师角色的融合。其原因与工作中的趋势以及这些趋势如何影响工程任务的本质相关。工程中的挑战，反过来也会影响工程力量和领导角色的本质。最后，这些变化倡导以人为本的领导风格，或者更具体地说，领导者行事要更像是培训师。

5.1集成化工程

计算机革命开始的时候系统开发涉及了许多技术和业务规范。项目需要逻辑电路设计师、硬件封装设计师、指令集架构师、规划详细系统逻辑的逻辑设计师。程序员开发系统程序，维护人员进行诊断，制造人员定义加工、组装和测试过程。项目还会涉及装配、应用和市场人员，以及人员、物料、式样、广告和金融组织等因素。系统设计包含了许多活动，尽管这些活动全都相关，它们也可以看成是大量接口和相互依赖性受限的独立小组。

现如今，个体纪律性的进步已经到达极限，开发人员必须越过纪律性而看得更远，进一步寻求机会。可以把系统管理看成是一种多维问题，其中每种新技术都会增加一个新的维度。在一两个维度上看似不能解决的问题在三维、四维上经常会是小事一桩。例如，早期集成电路都是两维布图结构。通过剪切导线长度来提升性能的做法经常是不现实的。但是，出现多层芯片以后，许多诸如此类的两维问题在三维环境下都变得容易解决了。

类似地，从设计进度中排除一个月基本上是不可能的。但是，如果把设计和制造看成是一项集成活动，通过早期加工、阶段性设计发布、制造设计，往往可以节省几个月的时间。通过交叠任意规范集，可以执行许多类似的节约操作。如果机构看不出节约的潜在趋势，那只能表明他们没有形成多维的思考习惯。

随着竞争的进一步加强，熟练开发人才的广泛供应，提升绩效、降低成本、缩短工期的压力持续增加。很难发现有哪部分开发可以被当成是孤岛一座。现代化工程的集成程度几乎在各个方面都越来越高。当我们寻求成本、进度、绩效或质量提升时，集成化往往就是答案所在。在未来，我们可以料想到对于集成化的迫切需求。

5.2集成化领导

如果你和大多数团队领导者一样，把自己的大部分精力投入到了某项事业中。虽然以前你可以从某一维看待这个世界，但现在你必须站在更广阔的环境中看待它。你必须关注完整的产品生命周期。例如，需求和设计工作可以交织在一起吗？系统、硬件、软件、测试、发行、制造或服务小组情况怎样？任意相关分支集合可以更好地关联起来以提升整体绩效吗？

要想集成多种专业，就必须消除小组之间的接口。但是，没有了接口，管理者之间的交流就会变慢，带宽会变窄。没有什么时间可以借助中间人来传达信息，要传达的信息太多了。因为不能再依赖管理者在开发人员中间中继指令，专家们必须直接交流，他们必须要被赋予权力，可以在解决问题的时候排除管理层的干预。领导集成化项目团队的挑战是

多方面的，它们需要一种以劳动力为中心的领导观点。这些挑战包括：

•在多维环境中领导。

•发展多维开发人员。

•委托和包含。

•加强劳动力。

5.3在多维环境中领导

在多维环境中领导团队的时候，很可能要管理几种不同的分支，几乎可以肯定你要处理更多的分支。在同一支团队、相关团队或独立小组中，要操作这些分支，就必须协调好所有的工作。如果有的团队成员来自于其他分支，他们很可能要接受你与其专职上司的矩阵式管理。在矩阵结构中，开发人员一般要由可以理解分支细节、可以保证专家们经过了适当培训与评估的技术经理来管理。随后这些开发人员会分配到由团队领导者指导和管理开发工作的项目团队中去。随着使用越来越复杂、集成度越来越高的技术，这类矩阵结构将会变得更加普遍，在许多分支当中你需要依赖专职经理来提供指导。

5.4发展多维开发人员

在领导集成化项目的过程中，努力像集成技术的计划一样详细地整合团队。要让所有的开发人员都忠诚，都做出贡献，那就要关注于目标，要调动整个团队参与工作计划和团队运营。让每个人都制订个人计划，参与团队会议，参与决策会议。除非开发人员表现得都像是一支集成化和相互依赖的团队，否则他们就不可能会创造出一种集成化和相互依赖的产品。

5.5委托和包含

如果你所领导的工作用到的不止是自己的专长，那你就必须要像执行人员一样行事。现在你所管理的工作是你所没有完全理解的。在这种情况下有些人会感到不舒服，要努力变成这些新领导的掌握者。随着技术的进步，交叉学科集成程度的提升，这种方法是不切合实际的。更重要的是，这种方法会错失良机。开发人员都应该运用自己的专长。你要把精力放在工作的质量和纪律性、项目目标、项目的许多专业和技术之间的接口上。这些接口很重要，因为其他没有什么人可以管理它们。只有团队领导者和程序经理才可以负责技术之间的接口。

5.6加强劳动力

与以前相比，现代开发劳动力必须要更加灵活、异构和互相依赖。有才能的开发人员需求巨大，在可预见的未来，这种需求可能会持续下去。要管理劳动力资产，就必须获得有才能的人员，加强和合理应用他们的能力，要设法留住他们。但是，人员越有能力，他们对竞争者的吸引力就越大，要留住他们就越困难。在许多开发单位里，人员调整都是大问题，必须得到足够的关注。研究表明，开发者离开单位并不是因为他们想走，而是因为他们被错误对待，才开始谋求其他职位（Shellenbarger 2000；McLean 1996）。

经验表明，如果雇主提供给开发人员竞争性薪水和津贴，尊重他们，大力控制其工作方式，他们就会忠诚。对待人员的方式在很大程度上决定了人员的忠诚度，雇员忠诚在很大程度上决定了人员调整。作为团队领导者，对手下来说，你就是单位，你对待他们的态度会被他们当成是单位对待他们的态度。这也正是培训和领导必须融合的原因。领导关注

于项目目标，而培训关注于人员。要高效地完成工作，就必须成为高效的领导者，但也必须要以培训师的角度来思考和行事。

6小结

本文讨论了团队领导者的角色以及高效领导的关键性元素。领导力被定义为领导的行为。领导意味着超前、领先和引导。领导者不要要求或强迫其人员来追随；他们会使得手下乐于追随。领导力还涉及纪律以及领导者使得人员追随自己的能力，即使当团队成员以异于往常的方式行事的时候也是如此。团队领导者必须赋予他想要团队成员效仿的行为以具体形式。TSP启动过程可以帮助发展这类领导者。

当你领导由你来管理的团队时，在要求人员按照你的思维行事的时候，很少会遇到问题。但是，在要求人员采取主动，按照自己认为正确的方式做事的时候经常会遇到问题。这需要变革型管理。TSP启动过程可以建立起变革型领导的条件，对于人员并不全部为你工作的团队，它甚至也会有效。到了启动结束的时候，开发人员将会开始变成一支充满活力而内聚的团队。你的挑战是维持和建立这种活力与热情。

要想成为变革型领导者，必须满足五项条件：成员归属感、承诺于公共团队目标、过程和计划的所有权、制订计划的技能以及遵循计划的纪律性、致力卓越。TSP启动过程为建立这些条件提供了一个基础，但你必须继续那个过程。本文提供了指导，并对如何做到这一点提出了建议。

你对团队的职责是设定步调，建立并维护高标准，维护过程纪律性，并且支持团队。活力和激情是可以感染别人的，纪律性极难维护。要做到高效，就必须相信团队，并且要驱动成员们完成优质工作。最佳领导者能够挖掘成员们的能力，甚于成员们的想像。关键在于要相信团队，要激励成员们努力，直到最终成功为止。

你还必须了解如何表现得像是一名培训师。持续完成严格的智力工作是很困难的，没有动力的人员是做不到的。如果行事像培训师一样，并以个体来对待每名成员，就可以提供此类培训指导，对优质工作提供支持。

本文结束时讨论了专业工作的变化本质，以及对于团队领导者的要求。现如今，提升绩效、降低成本、缩短工期的压力持续增加。集成化是对这些压力的自然解答，可以料想到未来对于集成化的迫切需求。但集成化工程需要集成式领导以及持续增加的多种劳动力。

集成式领导策略关注于工作的质量和纪律性、项目的目标、专家与技术之间的接口。最后，它还关注加强劳动力。为了做到这一点，必须吸引有能力的人员，培养他们的技能，让他们控制自己的工作。对于团队来说，你就是单位，你的行为将会直接影响到他们对单位和团队的忠诚度。要使团队完成最优秀的工作，必须成为高效的领导者，同时还要以培训师的思路来思考和行事。

TSP是由“软件质量之父”Watts S. Humphrey提出的一种采用广泛的团队过程。在本书中，作者以深厚的专业功底，准确地向团队领导人员展示了如何领导接受过个体软件过程（PSP）培训的软件工程师团队。书中探索了高效领导和团队协作的各个方面，包括构建合适的团队、TSP启动过程、制造高质量产品的过程、项目评审、有效使用领导者和团队的职能等，书中还讲述了项目负责人的职责范围、领导能力的基本要素以及可能会面对的许多问题。

详细请看《PHPer》11期增刊http://www.phpchina.com