四年前，我跳槽到一家开发公司自主APP的科技公司。当时的技术团队总共25人左右，包括.NET服务器端、iOS、Android、测试、产品、UI设计等多个小组。

在跟BOSS面试的时候，老板问了我一个问题：“你如何在一个新团队中建立自己的威信”。

这个问题我从来没有思考过，威信是什么，为什么要建立威信啊？一听到这个问题确实是有点懵。然后老板解释说，威信不是要在团队中耀威扬威，不是要让其他人怕你，威信是让你的下属服你，你发布的指令可以被很好的执行，而不是跟你对着干。听老板这么一解释，我就觉得自己好像还有那么一些心得，于是就把自己那浅薄的认知拿来回答，我说：“从自己过去两三年带团队的经验来看，程序员还是很单纯的，只要管理者技术过硬，下面的人都很好管理”。

老板听了我的回答，沉默了一会，没有做任何评价。现在看来，当时老板应该也不知道如何解这个问题。

入职后，很快我就遇到了面试时老板问我的问题。

Android跟iOS两个小组里面有3个人工作态度有严重问题，安排的任务拖拖拉拉，要么就说任务太难不会做，一个人一周就改几个简单的BUG，写的代码质量极差、惨不忍睹，跟他们说怎么怎么改，反而被怼“你能你来啊”。开会、讨论过程中也是多次顶撞我、反驳我，让我难堪。

技术部剩下的人大多也是消极怠慢，工作毫无责任感，能耍就耍，能拖就拖，一点不注重质量，BUG遍地皆是。这部分人， 相当大的原因是受那一小搓人的影响。

然后我找每一个人谈话，每个人都谈半个小时到一个小时。全部谈完了之后，对整个技术部的工作状态和人心也有了一个大概的了解。那一小搓人虽然在我跟他们的谈话过程中态度还不错，也表示会支持、配合我的工作，就当给我面子。但是谈话结束之后，整个技术部的工作状态几乎一成不变。

现在看来，这是理所应当的事。

当时的我非常的苦恼、困惑，工作压力也比较大：我完全没有想到团队是这样的状况，完全hold不住啊。

当时出现这样的困局还有另一个原因，就是boss虽然让我负责技术部，但是没有公开授权，有一部分事务还是老的负责人在负责，另外，由于没有得到老板的充分信任，老板安排了一个更有实权的副总来负责技术部，而该副总对团队的状况了解甚少。结果就是，我当时获得的管理权力是比较尴尬的。

如果是现在，我定不会困惑、苦恼。我会在给那一小搓人机会之后，如果他们还是不改变，那么我会迅速让其走人。虽然当时那几个人后来陆陆续续的也离开了，但那不是我的功劳。

为什么我现在敢这么强势？并不是因为我多工作了几年，也不是因为技术和管理经验更加丰富，那是因为我在这些年得到了一个理论支撑，是一位大佬对他的下属说的：我决不允许你的团队中出现人渣，要么你改造他，要么你开除他。

我想跟大家分享的是，在管理的实践过程中，正确的理论支撑是多么的重要。一个极其简单的理论，可能会化解一个极其困难的局面。就像我4年前亲身经历的一样，大家都看在眼里的局面竟然当时没有一个人能解。

就像这个人渣淘汰理论一样，当我把这句话引用出来的时候，大家都觉得这个理论非常简单吧，甚至不需要我做解释相信大家都同意。但就这样一个简单的理论，可以帮助我们管理者避免陷入困惑、苦恼，轻松将团队中的这个人渣大问题给解决掉。

这就是理论支撑在管理实践过程中的重要性。

但是在大多数团队中，可能并没有这么明显的人渣成员，即使有，可能人家也是在暗地里的给团队使坏。如果遇到这样的团队，特别是当你又是一个空降的管理者时，你应该如何快速建立自己的威信呢？

这才是本文想跟大家分享的，可能比人渣淘汰论更加有价值的一个话题：如何在一个新团队中快速建立起管理者的威信？下面，我就从理论跟方法两个方面来跟大家分享我们团队这些年获得的一些经验。

一、理论篇

1. 为什么一个管理者要建立威信？

略。（对这个问题有疑问的朋友可以在评论区留言）

2. 管理者的威信应该包含哪些内容？

我觉得一个管理者是否具有威信的最重要的体现就是，管理者安排的任务下级必须坚决执行。允许下级提出疑问，但是不允许下级带着消极、抵触、敷衍的情绪去执行，如果出现这样的问题，那就是管理者没有威信。

那么，作为一个管理者，就必须对下属工作任务的完成情况进行评估了，否则如何知道下级是否坚决去执行了上级安排的任务，以及执行的情况如何。从而我们才知道这个管理者有没有威信。

3. 管理者的工作内容之一：对下属工作任务的评估

为什么这里我要说“对下属工作任务的评估” 是管理者的工作内容之一呢？并且我认为是非常重要的工作内容之一。首先这句话我相信就会有很多朋友反对。虽然我相信这个理论肯定不是我第一个提出，但是我作为该理论的认同者和推广者，还是有必要回答一下这个问题。

大多数反对这个观点的人认为，管理者通常特别忙碌，而工作任务的评估如果要在安排任务之前就去做，这个难度较大且比较违背人性，而如果要在任务完成之后还去对工作任务做评估，那好像意义不大，纯属浪费时间。总结出来就是：对工作任务的评估除了浪费时间别无用处，因为管理者太忙了。而如果还要把这项工作提升为“重要工作内容之一”，那自然是更加无法理解。

我先不正面回答这个问题。让我们先来看看社会中大多数管理者是怎么来的。我想说， 大多数管理者都是因为这两个原因被提拔成管理者的：（1）工作比别人多工作几年，（2）业务比别人更精通。大多数的管理者并没有管理意识，都忙于业务。我想说的就是，这部分管理者并没有意识到自己身份的转变，并没有意识到自己的管理者责任。然后以忙、没有时间、浪费时间为理由反对：把事情做好了就行了嘛，搞那些虚的有什么用。

因此，我认同的理论是：对下属工作任务的评估是一个管理者的基本责任。

4. 工作任务评估：产出和质量

工作任务的评估可以简单分为两个维度：产出和质量。（在我们的实践中还包括了难度和BUG扣分的评估）

产出，更准确的叫法应该叫“标准产出”。标准产出的定义：完成某任务的有效产出等于一个行业中等偏上的业务员完成该任务所需要的时间。

所以，管理者对下属工作任务的产出的评估，并不是按照管理者自己的业务水平，也不是按照指派者的业务水平来评估所需时间，而是按照行业中的一个中等偏上水平的人员来评估所需要的时间。“标准产出”是一个非常重要的概念。之前有好几个朋友问我任务的产出不知道怎么填写，而当我给他们提了标准产出的概念之后都豁然开朗。

如果下属完成的每个任务都有一个标准产出，那根本就不用担心某个下属拖拖拉拉了（原因略）。不仅如此，如果团队把标准产出纳入奖金算法，那还会起到意想不到的作用。

第二个维度就是对工作质量的评估。这实际上是对有效产出评估机制的一个补偿机制，因为团队中难免遇到有些人敷衍了事，工作质量严重不达标。而质量评估就可以让这部分人无处遁形，这也是对另一部分积极上进的员工的公平。

5. 工作任务评估：事前评估和事后评估

工作任务评估按评估时间分为事前评估和事后评估。

事前评估是指管理者在安排任务之前，已对此任务的有效产出（可能还包含难度系数）做了评估。事前评估对一个管理者的计划能力要求较高，而对于那些全是临时任务的团队，可能就很不适用。

事后评估则是指下属将任务完成并提交给管理者验收的时候，管理者才对该任务进行评估，或者是，如我们团队，在每周五写周报的时候对本周已完成的任务集中进行评估。

我认为事前评估和事后评估都是OK的，当然，如果项目任务比较确定，那事前评估的管理者要比事后评估的管理者更高级。

6. 工作任务评估：数字化评估和描述性评估

评估的方法可以分为：数字化评估和描述性评估。

其实有很多团队都建立了考核机制，只不过考核大都是描述性的。描述性的考核意义其实并不大。

而如果一个管理者建立了数字化的对工作任务的产出、质量的评估，那该团队就可以很轻松的建立数字化的考核。因为，工作任务的有效产出和完成质量是考核一个基层员工的最重要的指标。

二、方法篇 

 下面，我就结合我们团队的实践经验跟大家分享：如何在新团队中快速建立威信。

1. 获得上级（或老板）的支持

带着上文理论篇的知识，得到上级的理解、认可、公开授权、公开支持。因为大多数的基层员工很难在一开始就理解到这个考核制度实际上是为了团队利益、为了团队公平、为了做到赏罚分明、为了避免勾心斗角等等。因此，大多数的基层员工都是本能抵触考核的，特别是数字化的考核，特别是新领导带来的新的考核制度。

因此，获得上级的支持能够让新制度更加顺利的被执行。

虽然基层员工一开始会本能的抵触，但是无需担心，因为：（1）大多数员工很快会明白这套制度的先进性；（2）上级大多数情况都会非常支持。

2. 你需要一个带考核功能的任务管理系统 

该任务系统必须带有的特性：

（1） 可以对每个任务填写有效产出，并且该数字只能由管理者填写，下属员工不能自己填有效产出；

（2）管理者可以对工作中出现的质量问题进行记录；

（3）每周/月自动生成统计报表。

在我们的实践过程中，下属工作人员可以自己创建任务，但是任务的有效产出只有管理者可以填写，这样的话管理者只需要将大块的任务分配出去，下属员工可以自行拆分记录。然后每周五管理者填写周报时，集中对本周完成的任务进行有效产出的评估。然后管理者将来自任务系统的统计数字纳入当周周报的考核中，我们具体的操作实践请参考我的另一篇博文：分享我们团队管理的最佳实践——程序员的周报应如何填写

如果你找不到这样一个现成的管理系统，可以试试我们一直在使用的管理系统（点击查看），也可以先用Excel试试。重要的是这套管理思想能否在你们团队落地，以及能不能帮你们快速建立管理者的威信。

3.  坚持

在新团队实施新制度，必然会遇到各种阻碍。但一旦你实施成功，你的团队会获得巨大的收益，大大的提高工作效率，大大的减少加班，大大的改善员工工作氛围。

所以，这是一件非常值得去干的事。