今天简单聊聊如何带人。所谓的带人，其实就是一个放权的过程，但是这是一个极其缓慢的过程，不可能一蹴而就。如果在最开始的时候，给予的自由过大，员工就会如同野草一样，疯狂的自我生长，最终的结果肯定是良莠不齐。

先来看几个场景：

1. 拿到一个原始的需求，Leader：“这个功能，做一下，没问题吧？”员工：“没问题。”
   过了几天，Leader：“做完了没有？”员工“......”
2. Leader：“你需要在这里增加一个接口去给另外一个系统提供一下数据，你去做吧，有问题问我。”
   下属很快去做了，完成了编码，测试也没问题，愉快的上线了。
   过了几个月，需要改动一下接口，然后一看这代码：“这是什么情况？怎么能这样调用底层呢？我去......”
   下属：“为什么不行......”
3. Leader：“你去跟客户沟通一下，看看他这个功能想怎么做？”
   员工回来吧啦吧啦的说了一堆：“客户想要的就是这么一个功能。”
   Leader大概听明白了：“你去做吧”
   员工做完了，客户炸了。

也许在正常工作当中，这种情况出现的并没有那么极端，但是类似的肯定不少。Leader一般想的是，我很忙，还得操心这些事，我已经说的很明白了，为什么员工就不能发挥一下主观能动性呢。员工一般想的是，我就是个开发人员啊，你不说明白，我怎么做啊。

抛开员工的想法，我今天只说Leader需要做的。既然已经到了这个岗位上，不管是被迫也好，主动也好，都是要在其位谋其政的。带人避免不了，那就得摆正位置，负责的去做，这也是工作内容，也是需要忙碌的内容。

带人要由浅入深，放权要由紧到松。一开始的时候，两人都处于磨合期，脾气秉性、技能程度都处在一个摸索的阶段，这个时候指望着员工能够帮助自己分担工作压力，简直就是痴人说梦，能够愉快的沟通就已经很不错了。这时候，带人者首先做的事情就是统一风格，也就是说要保证两个人的行事准则基本上能够统一。总不能是，带人者雷厉风行，被带人慢吞吞，这么干，有多别扭就多别扭。

带人者一般都是既要保证自己的工作产出，又要保证被带人的工作产出。所以每天的工作安排其实必不可少，如果一上班就进入自己的工作模式，那导致的都是被带人的放羊状态。保证关键节点的检查是必不可少的，就拿开发工作来说，开发主管自以为说的很明白，但是程序员懂不懂就难说了。这时候，就需要检查，这里的检查有时候也很简单，让他复述一遍就行了，再不行的话，画个顺序图复述一遍，要是还不行，那就写段伪代码复述一遍。

每一个小的阶段，每一个里程碑，都需要总结一下。这段工作顺利的原因是什么，这段工作不顺利的原因又是什么，能不能进行改进，下一次需不需要着重检查关键节点，自由度是不是能够放宽，甚至于还能不能继续合作下去。这些都是需要的，总不能这一次员工说没问题，结果问题频出，下一次带人者还相信“没问题”这三个字吧？

我认为，金无足赤人无完人，不是什么人都适合于带人的，不是说本职工作干的好，就能够提拔成Leader，进而带出一批能干好本职工作的人。本职工作干的好，证明这个人符合被提拔的条件，但是能不能胜任被提拔之后的岗位要求，这其实是需要再次确认的。

当我们在带人的时候，时刻要记得的是，我们不单单是要对自己负责了，还要对所带的人负责。这是一荣俱荣，一损俱损的局面。如果我们带的人不出成绩，或者我们带的人不令上级满意，而这些又是由于我们的方式、方法有问题，或者又是由于我们的不作为导致的，那这就是我们的失职。如果我们带的人态度不错，潜力也还没有到达天花板，却停滞不前或者失去了工作，我觉的我们应该考虑一下：我们是否适合带人，是否适合这个岗位。