作者：Mike Cohn
译者：李洁（Jerry Li）
原文链接：
https://www.mountaingoatsoftware.com/blog/can-a-team-vote-someone-off-the-team
我们说敏捷团队是自组织的。但自组织到什么程度？团队成员们是否该拥有投票把某人从团队中除名的权力呢？
自从1997年首播以来，电视节目《幸存者》就常常被提到，询问团队是否有权投票将某人淘汰出岛。
回顾敏捷的起源
Scrum是首个应用于软件开发的敏捷方法。1990年，我首次从彼得·德格拉斯（Peter DeGrace）和莱斯利·斯塔尔（Leslie Stahl）的《Wicked Problems, Righteous Solutions》一书中了解到Scrum。他们的书中描述了许多应对软件开发挑战的方法。他们对Scrum的描述是基于首篇关于Scrum的论文——《新新产品开发游戏》（The New, New Product Development Game），该论文发表于1986年1-2月的《哈佛商业评论》（Harvard Business Review）。
我经常重读这本书和这篇论文，以搞清楚Scrum的初始理念。
每个信息来源都清楚地表明，组建团队是管理层的职责。竹内弘高（Hirotaka Takeuchi）和野中郁次郎（Ikujiro Nonaka）在其《哈佛商业评论》的论文中写着，“尽管项目团队主要依靠自我管理，但他们并非不受控制。”然后，他们概述七种形式的“微观控制”（subtle control），这些控制施加于团队，而有利于产品。
他们建议管理层要保留的一项微观控制形式是，控制团队组成。他们援引了一位本田公司高管的话——“经过长时间的考虑，我们精心挑选了项目成员。我们分析不同性格的人，以弄清楚他们是否能和睦相处。得益于我们共同的价值观，大多数人确实都相处得很好。”
哈克曼的四级团队授权
竹内弘高和野中郁次郎关于Scrum的最初论文发表于35年前。他们关于微观控制的看法是否依然合适呢？
为了回答这个问题，我认为看看哈佛大学教授理查德·哈克曼（Richard Hackman）定义的团队可能拥有的四级授权体系是有用的。他将团队分为以下几类：
经理领导（Manager-Led ）团队
一个经理领导的团队，只有执行任务的权力。基本上，这类团队被告知“这样做”，并且他们照此执行。
自管理团队（Self-Managing）/自组织团队（Self-Organizing）
哈克曼使用了“自管理团队”这个术语，但它其实类似于敏捷领域中更常用的“自组织团队”。这类团队具有管理其工作过程的权力。实际上，团队外某个人会给团队一个目标，而他们则自行决定如何实现目标。
自设计团队（Self-Designing）
一个自设计团队拥有自组织团队的所有权限，并且还有权决定团队由哪些人组成。
自治团队（Self-Governing）
除了拥有已列出的这几类团队权力外，自治团队还有权决定其目标。也就是说，一个自治团队可以决定他们要开发什么。对于自治团队选择什么作为目标，通常会存在某些期望，必须符合公司的使命或愿景。例如，甲骨文公司内的一个自治团队，就不会有改行种植有机鳄梨的决策权。
微观控制是否依然适合？
如果采用哈克曼的团队授权等级体系，很明显，只有自设计团队才有决定团队成员的权力。在今天的世界里，我发现这样的团队仍然很少见。或许存在，但并不流行。
未来自设计团队会普及开来吗？我认为我们正在往这个方向发展，但要进入一个普及自设计团队的世界，仍然会有挑战。如今许多管理者的职业生涯已经与自组织团队的发展重叠了。要进一步转变思维将会很难。正如自组织团队花费了几十年的时间才普及开来那样，自设计团队要流行起来可能也需要花费同样长的时间。
并且，对于自设计团队是否值得追求，仍存有疑问。丹尼尔·平克（Daniel Pink）在他的《时机管理》（When）一书中说，一个高绩效的团队“要在团队之上或团队之外有一个老板或者其他什么人来决定速度，维持标准，并让所有人集中精神。”
一些建议
我喜欢自设计团队的理念。这很容易理解，要决定谁应该待在团队，有谁能比现有的团队成员做得更好？
但这不太可能适用于所有团队。有些团队可能会选择同质化而不是多样化。这样的团队可能会只雇佣思想相近或技术背景相似的开发人员。更不用说会去考虑种族、性别和文化的多样性了。
另一些团队可能只会视图雇佣那些技能不如他们的新团队成员。现有的团队成员以为，这样做能使他们在老板眼里显得更优秀。
诸如此类不替整个组织最优化着想的问题，会在团队中出现。这种情况发生于组织目标与个人薪酬不一致的情况。
这类问题是可以解决的。但是，管理层能期望团队成员会选择一个对项目更好的人，而不是一个更乐意一起工作的人吗？
一步步实现自设计团队
采取渐进方式来实现自设计团队，是非常有可能的。例如，可以先授予团队申请预算聘请承包商的权力，而不是雇佣和解雇员工的权力。
这是我倾向的方式，不要赋予团队完全的雇用和解雇权限。他们可以在分配的预算内聘请承包商，但是他们不能雇用或解雇员工。
我发现这是一个很好的平衡，也是向更完整自设计团队迈进的一步。它也更符合人力资源或人事部门的政策或偏好。在当今这个充满诉讼的世界，值得对招聘和解雇进行额外的监督。
你有四个星期的时间：更进一步
几年前，我尝试着向自设计团队迈进了另一小步，获得了不错的效果。这个主意产生于因绩效不佳而必须解雇我们一个团队中某位程序员。在我让他离开团队后，另一名程序员不加思索地告诉我，“我非常高兴您能把他揪出来。我还以为我们会永远被他困住。”
这句话告诉我，当经理意识到必须让某位员工离开团队时，团队已经痛苦地意识到了这一点几周甚至几个月了。我对团队关注得还不够紧密，没能象那些每天与他一起工作的人一样快速认识到让这位程序员离开团队的必要性。
后来我还意识到，我没有立刻行动，是因为解雇人并不愉快。虽然多年来我已经做得够多并能坦然面对，但这事仍然无趣并且我希望永不发生。所以，我拖延了几个星期才把情况提请我们的人力资源主管关注。她让我安排这位程序员参加一个为期一个月的绩效改进项目，以给他一个改进机会。
难怪另一名团队成员会说：“我以为我们会永远被他困住。”
这让我明白了，当经理意识到绩效问题时，团队可能已经知晓几周或几个月了。
因此，我们制定了一个政策，一个团队可以投票把某人从团队中除名。这必须得到其他队员的一致同意。当有人被团队投票除名时，我（作为软件开发副总裁）会会见此人并解释情况。
然后，我会给他四周时间（在组织里进行两次为期两周的冲刺时间）去寻找一个新的团队。基本上，这个人会走到其他团队说，“你们需要我的帮助吗？我是免费资源？有人需要帮助吗？”
有些团队可能会用一个有助于当前冲刺的、限定时间的任务来试试此人。另一些团队则可能会愉快地接受此人或者带着他试跑一个冲刺。
如果到四周结束时，这个人还没有找到一个新团队，愿意接受其作为新成员，这就告诉了我很多关于这个人的信息。很明显，这个人没有被其他团队认可价值。在某些情况下，这个人在技术上很优秀，但也会带来其它的负担，比如过于消极，团队也不会留下他。
四周之后，如果有人还没有找到新的团队，我会把他们调动到直接向我汇报的位置。我还会与人力资源部合作，发起一个绩效改进计划。
大多数被我调动到直接在我手下工作的人，最终都被解雇了。很可惜！但这是正确的做法。
然而，幸运的是，很少会有人走到这一步。大多数人都确实能找到了另一个欢迎他们贡献的团队。有时候，不适合这个团队的人可能会非常适合那个团队。
再说一遍，谁能比团队自己更了解这一点？
通过这种方式，我们得到了拥有自设计团队的诸多好处。而组织中的经理们也保留了在少数情况下我们认为必不可少的“微观控制”——例如当团队变得过于单一的时候。
世界似乎正朝着自设计团队的方向前进。（甚至很可能是自治团队。）朝着这个方向迈进几步，甚至只是局部尝试，对您的团队和组织来说都是一个很好的举措。
您怎么认为？
您的团队有雇佣或解雇的权力吗？您希望如此吗？团队组成方面的授权能在多大程度上帮助或阻碍您的团队？请在下面的评论区分享您的想法。
