软件开发团队领导的十大误区

　　本文是RoyOsherove在SkillsMatter的一次发言，他介绍了团队领导经常会犯的10个错误，并提出了一些解决方案。
　　Roy首先提出几个团队领袖可能遇到的一些问题：
　　我如何说服我的团队做某件事情？
　　我该拿团队里的那个专门搞事的家伙怎么办？
　　我该如何做一个团队领袖呢？
　　我们为什么无法远离无谓的争吵呢？
　　我会不会失去朋友呢？
　　他说这些问题其实缠绕他多年，接下来他也逐一做出解答。他正在写一本叫《开发团队领袖手记》的书，里面也涵盖这些方面的内容。
　　下面就来说说这10个错误：
　　1没有认识到团队的成熟度
　　这点是首要注意的地方，因为后面谈到的问题都是提及团队的成熟度。Roy说，可以从3个层面来评价一个灵活团队的成熟度。
　　混乱
　　学习
　　自我引导
　　混乱
　　一个混乱的团队就是哪都觉得很忙。可能他们总是在争吵，或一直都被要求在非常有限的时间做太多的事情。但其实结果都一样：混乱。没有人有任何时间变得有条理，没有人有任何时间学习新的知识，因为他们一直都在忙这忙那。如果你问我的话，这个团队明显成熟度不高。因为所有人，要么耗尽精力，要么感到沮丧因为缺乏机会学习，而最终好的人都会离开。但是，Roy说这种混乱其实非常常见，而我也很赞同。如果你是在这么一个混乱的团队里当领袖，秘诀就是要正确的行动起来，你必须自信和强势。
　　当船快要沉的时候，你需要的是一个发号施令的领袖，而不是开会。
　　一个混乱的团队里的领袖，必须坚定立场，而且可能必须要和领导层说清楚，整个团队并不能把他们要求的所有的事情都完成。这是一个艰难的角色。他必须坚定的做出一些艰难的决定。
　　管理要做得对、做得好是一件很艰难的工作。
　　但为什么作为一个团队领袖，你必须自己做出这些艰难的决定，而不是和团队商讨呢？答案很简单，因为没有足够的时间。通过你自己做出这些执行上的决定，你让你的团队得到一些喘息的余地，可能也就是这些余地让他们把手上的事做完。当然，可能有些你做的决定是错的。这没关系，人生就是这样。但这是为了更重要的正确的事情，也就是让你的团队有成长到另一个层次的空间，一个不断学习的团队。
　　学习
　　这个层面的成熟度是团队自我管理的升华，但是团队成员还是有需要得到指导的。一个团队领袖必须持续不断的为他的团队成员带来一些挑战和质疑，甚至可能是功课。目标就是让团队里的成员每周都有进步，开始学会解决自己遇到的问题。
　　所以，你要怎么做？
　　作为一个学习成长的团队里的领袖，你要让团队里的成员学会解决自己遇到的问题，然而成长为自我引导的团队。如果某一个人带善一个问题来找你，你应该鼓励他们自己想办法解决，并问你会怎么来处理这个问题？来强迫他们思考。
　　自我引导
　　成熟的第三个层次就是自我引导型的团队。这是我们所有人都想去到的地方。在这样的团队里面，领袖更像是一个导师。他不需要像在一个混乱的团队里那样为团队做各种执行方面的决定或告诉人们该做什么。但即使是在一个自我引导的团队里，团队领袖还是需要最少50的时间在团队上面。
　　所以，第一个错误就是不能正确认识到你的团队是在什么成熟度，也因此不能够正确的领导你的团队。如果你当他们是自我引导型的团队在运作，但其实他们事实上还是在混乱的状态，那么不久你就会在一条河上像没有桨似的乱窜。
　　2害怕授权
　　如果你常常习惯自己一手包办，可能要你下放责任给其它人是比较不容易接受的，尤其是你觉得其它人并不能把事情做好的时候。
　　如果每个人都对目前手上做的事情都感到很舒服，没什么挑战的时候，就是你做的不对的时候了。
　　当你要授权的时候，你必须做到责权对等。这些外加的责任，会把他们拉出那个安全区，这是一件很好的事情。适时挑战一下你的团队和拉他们出安全区才可以让他们成长。
　　（注：关于授权或放权，请推荐看DreckSivers的《管理者的困境：放权或者崩溃》）
　　3害怕参与
　　这一般来说是沟通不够有效，但Roy谈得更深入。
　　4安抚
　　公共要素（BusFactor）这是什么？公共要素指的是开发过程中的一些共同因素。这其实说的就是某些个体掌握太多信息。我看到太多地方有这种情况，无论是好的还是坏的项目。所以我觉得这很正常。但Roy提到的是你不应该因为他们掌握了大量重要的项目信息就只安抚这些个体。你对待一个公共要素为1（也就是说他一个人如果被公车撞了的话，项目就倒了）的人应该和别的任何一个人一样。我非常喜欢在人身上定义一个公共要素的主意，因为它让我想起了六度分离理论值。
　　5疏远
　　这个应该是说由于太多的会议或邮件等烦杂事情要处理，导致基本上和整个团队实际的工作脱节了，最终疏远了。这个和六度分离理论没有关系。
　　6太理想化
　　不确定我是否同意这个术语，但Roy的意思是认为所有人都能清楚明白你说的意思，但实际上你并没有把自己的观点阐明。我想这点的关键是说当你和一群人相处，尤其是对一个灵活的团队来说，假定他们拥有和你同样的知识水平和理解力是不正确的。你应该用最合适的方式去沟通，而不能做太多的假设。
　　7责备
　　如果你认为某个人是垃圾，那你就会有意无意的以这个为借口，不让他参与到团队的事务上来。这世界上总有这样的垃圾人物，但你所要做的是了解他们的短处，并把他们提升到整个团队的水平，而不是疏远他们，因为这样就意味着一直背负这些沉重的包袱。
　　8忽略影响行为因素的力量
　　你必须认识到那些会作用到个人身上的行为因素的力量和知道它们是如何影响个人的。主要有这么三种行为因素：
　　个人
　　群体
　　外界环境
　　所有这些因素都会影响到一个团队是否能够成功。所以你必须找到有没有什么因素正在影响团队的敏捷度。其中一个外界环境的因素可能是硬件设备不足够支撑你所需。比如说你没有预算添置一台持续集成的服务器，那你几乎永远无法变得敏捷起来。
　　9害怕太独断
　　很明显这在英国和挪威是很普遍的，但在丹麦不适用。我敢打赌你不知道。但这据称是真的。独断，就是坚定自己的立场并拒绝任何你感觉不能接受的事情。如果你是在一个处于混乱状态下的一个团队里面，那你必须非常独断。在一个处于混乱状态下的一个团队里面，惧怕独断是致命的。
　　10不重视承诺
　　这里说的是模糊其词。Roy说你应该任何时候都对项目期限负责。当你对团队谈论的时候，确保他们也告诉你每个任务的具体完成时间。很明显，让他们作出承诺，他们会更有激情的完成任务。Roy的建议是当你开会结束的时候，并问每一个人他们下一步要做的事情是什么，确保他们的回复是什么时候前做完什么事情。但是，任何人都只应该承诺他控制范围内可以完成的事情。承诺一些要别人替你完成的事情是没有意义的。还有，一但你发现你无法按时交货时，让整个团队的人都知道，他们可能有办法帮忙并让你及时完成任务。
　　问题和解答
　　下面这些问题和解答其实持续很长时间才得出。我用bullet表单总结了一下，因为bullet的样式非常好。
　　你需要认识到你什么时候需要转换领导形式你必须停止用一个在混乱模式的团队下的领袖角色来领导一个成长型的团队。
　　没有一个所谓的既混乱又成长型的团队。这两者是不可共存的，但是一个团队会从一种形式，转换为另一种形式。
　　跨不同地域的团队不能像在同一地方的团队表现好。如果你是这样的事实情况下，你要做的是改变现实。
　　敏捷团队应该是两个Pizza的团队。也就是说，只够两个Pizza可以喂饱的团队。
　　好的团队是成长起来的，不是雇佣来的。
　　Scrum有时并不适用于一些混乱模式下的团队。
　　团队领袖和经理其实并没有不同，如果他们是同一个人。其实他们也可以是同一个人。
　　如果你的团队处在混乱模式，你从项目经理应该保护他们。
　　作者在最后推荐了4本书，3本有中文版：
　　《ManagingTeamsCongruently（QualitySoftware）》
　　《BehindClosedDoors：SecretsofGreatManagement（PragmaticProgrammers）》《门后的秘密：卓越管理的故事》
　　《Influencer：ThePowertoChangeAnything》《影响力2》
　　《Scrum敏捷软件开发》
　　译文：36kr