声明：所谓的技术管理笔记，是一位原大公司的码农不甘寂寞，出来加入创业公司后的管理心得记录。大公司到创业公司的落差是全方位的，制度，氛围，资源，人才皆有。从最初的不适应到一路磕磕碰碰活到现在。心中充满感恩和侥幸，觉得有必要强迫自己做下记录和总结。遂开始于2017年11月份，截止此时我所管理的技术团队为50人。此背景可做参考，例子可能和您的团队不符，但是思路可能相同，欢迎同道中人一起讨论切磋。

上一篇技术团队管理笔记(一)-识人获得了大家的喜爱，也和很多朋友做了交流，非常感谢大家的支持，本篇我们开讲技术团队管理笔记(二)-带人

首先我们先搞清楚一个核心问题：为什么要带人
有的同学会说带人是为了让团队更有战斗力，从而可以做好项目; 有的会说可以让自己从细节工作中慢慢解脱出来，有更多时间考虑架构的问题; 有的会说非常有成就感，看到下属一个个成长起来这种感觉喜不胜收。这些说法从结果来看，都是正确的，但似乎和公司的整体战略目标好像有点距离？在这里，我提一个新的观点，带人的核心目的是：通过提升团队的能力，为公司赢得3到6个月的成长红利期，且暂时不需要付出额外成本(一般6个月到1年左右会有加薪需求)。当这个红利帮助公司拿下既定业务目标后，整个团队就可以享受公司成长的收益(加薪)，从而形成良性循环

这句话看上去非常市侩，恩，很像资本家无情的剥削想法:)，但这其中透露了几个关键点：

为公司赢得3到6个月的成长红利期高于一切，只有当公司获得收益后才能反哺团队，你才能够建立真正的威信。
在带人的时候难免会让团队觉得更累了，要付出更多了。但此时绝不能心软，更不能有“万一我在技术上对大家要求很严格，但是公司最后没有给团队加薪，那我的个人信用岂不是破产”的错误想法。因为没有那3到6个月的成长红利期，公司是不可能成功的。说句打击士气的话，万一努力了，公司还没赢得业务目标怎么办？哈哈，这不是你作为技术管理者能决定的问题了，你只有往前看一条路
带人是没有止境的，因为你需要永远为公司的发展创造出空间，所以一刻都不能松懈

电视剧汉武大帝里有一段曾让我印象非常深刻，霍去病说自己打仗还会带厨子专门给自己做饭，被李广和卫青鄙视，他们说，为将者和士兵同甘共苦还是需要的。霍去病回答道：带兵打仗，需要的绝不是行仁义。将帅的目标，只有一个，那就是赢。仗打不赢，就是天天和士兵同甘共苦，也是个无能之将(仗如果打赢了，将士自然论功行赏)。这正说明了，管理者为公司赢得红利高于一切。

明白带人的意义后，我们来讲一下带人的几个心法

做项目的核心目的是为了带人，做成是结果
，理解这第一点最为关键和精妙，很多同学在带项目的时候，看上去事必躬亲。每天像救火队员一样帮助团队成员解决各种技术问题，也会耐心和他们讲解好的技术方案，但是效果却不尽如人意。因为你会错意了，真正优秀的管理者是管人不管事，也是我们常说的“无为而治”。如果你的团队成员够强，项目自然是能成功的。如果你的团队不够强，就算你一次次靠优秀的个人能力堵上了窟窿，你的团队也没有成长性，更没有未来。所以如果要做一个“四两拨千斤”的优秀管理者，请把你的重点放在带人上，放在关键的事情上，而不是在项目的琐事上。
提升下属的思维高度高于帮助其解决问题 ，深刻理解到了第一点，那这第二点就是精彩的开始。我们来推演一个场景，假设你团队里的一位工程师使用了一个开源框架，因为框架本身不是非常成熟或者他的使用方式有问题，最后在某个项目的发布中，导致程序内存溢出了。我们来看下以结果为目的和以带人为目的的不同处理方式：

以结果为目的：使用专业的内存分析工具，帮助工程师发现问题所在，并剖析开源框架的源代码，告知工程师框架有何问题或以后该怎么使用
以带人为目的：干完以结果为目的该干的所有事之后，问一下工程师，你觉得使用一个第三方的开源框架，怎么样才算是正确的做法？在和工程师一番讨论后，你抛出自己鲜明的观点：1 开源框架也是人写的，可能就是有问题的 2 在使用任何开源框架前，我们都该知其然知其所以然 3 牛逼的技术不在于你研究和使用了多少开源框架，而是你能不能永远做出稳定的商业化系统，开源只是你的手段和工具而已。明白两者的区别了吗？以结果为目的你只是看到了一棵树，而放弃了整个森林，看似解决了这次的问题，保证了项目顺利发布，但是下一次你的工程师还会掉进开源的坑里。而以带人为目的的方案，你不但解决了问题，还开始尝试提升下属的思维高度，以后他不再会掉入任何的开源坑里，且真正明白了何为稳定的商业化系统。在日后，就算使用公司内的其它公共服务，他都会非常小心，那是质的变化！所以，请一定要记住，提升下属的思维高度高于帮助其解决问题。

怎么设定好下属的目标是个学问 ，给下属设定目标也是非常重要的，有了目标，他们才能往那个方向去努力，才能成长嘛。很多管理文章都会提到，设定的目标一般比人的当前能力高20%到30%左右。这个肯定是没错的，也必须按照这样来，但这里有一个关键问题：修正幅度。你不是先知，给下属设定的目标不一定每次都是对的，很有可能高了或低了，这之后怎么办呢？切记不要一次修正幅度过大，要慢慢修正。高了或低了，就先正负修正10%左右，再观察一下下属的表现，如果还是不匹配，那就再修正10%左右。这种做法有一个好处：对有上进欲望的同学，不至于因为目标太高而让他失去积极性，慢慢加量，帮他不断提升。对无上进欲望的同学，则可以慢慢边缘化，避免团队震荡，因为目标往往决定了你会负责多少事。
越重要越紧急的项目越要严格要求 ，这也是一个很关键的点，我看过很多技术管理者，因为ceo的业务压力，在一些非常重要且时间紧急的项目中默认了团队不需要做非常详细的系统设计后再开始编码，甚至对开发的自我测试要求也会降低（期望早点发给专业的QA去测试以节省时间）。首先从项目的成功角度来说，肯定是错的，没有好的设计和测试，很有可能是会做失败的。另外从带人的角度来看，这种做法给团队传递了一种极其错误的态度：越是重要的项目（这种项目往往进度也很急）越不需要设计和自测。这不是带人了，简直就是毁人啊，对团队未来的成长带来不可估量的阻碍。今天你给自己所谓的方便，明天必将几倍的反噬于你，到时你再怎么努力扭转都无济于事。在军队中有一种观点，就算败了，阵型也不能乱，其实说的就是这个道理。对于重要的项目不但不该放松，反而应该更加严格要求，给团队传递正确的信号：越是重要的项目越要严格要求。
先从核心人员带起 ，还记得上篇文章技术团队管理笔记(一)-识人里定义的5类人吗，在这个地方就要发挥作用了，如下处理方法：

类别	定义	带人策略
优秀的工程师	技术优秀，认同公司目标，有很强的自驱力，喜欢发现问题，解决问题	需要你亲自带
有一定工程师思维的潜力程序员	认同公司目标，有很强的自驱力，技术尚在快速成长期	由第1类人来带，在需要你带的时候再介入
有一定工程师思维的普通程序员	认同公司目标，有很强的自驱力，技术潜力一般	由第1类人来带
熟练的程序员	技术比较扎实，但是没有太多工程师思维	由第1或第2类人来带
普通程序员	技术一般，也没有太多工程师思维	由第2类人来带，你需要关注不能因为个体原因影响到整个团队

记住，你的带人精力是有限的，要把精力花在最该需要的地方和人身上，才能事半功倍。

细心留意真正需要你介入的时机 ，带人的介入时机也是很有讲究的，因为带人总免不了说教。你想想如果你作为一个员工，被自己的老板指出这里和那里的不足，就算老板是为你好，你的心里总是不舒服的，因为人的本能就是抗拒自己的缺点的。如果你在向下属指点的时候，他在本能上是抗拒的，那效果肯定是不好的。那何时是你介入的好时机呢？这里有一个窍门：在你的下属碰到了一些困难正手足无措需要帮助的时候，且这个困难不至于对整个项目产生致命的威胁。雪中送炭，才是你带人的好时机，你的下属在这个时候更多是感恩，能听得进你的建议。千万不要迷恋什么每月谈话，看看下属需要什么帮助这种冠冕堂皇的套路，远远没有雪中送炭的作用和意义大。但是度要把握好，不能等你的下属都要被烧死了，你才进去帮忙，那真是晚了。你下属的每一次跌倒，一定能记住痛，也是他能否成长的关键时刻，这个时候才需要你的出现！

带人这篇已经表完，总的来说理解带人的目的最为重要。在真正理解带人的意义之后，只要足够耐心，采用合理的方法就能把团队越带越强，从而享受到产生的红利带好了人后，只有用对了，才能真正发挥作用，下一章，我们讲一下技术团队管理笔记(三)-用人

技术团队管理笔记系列链接：技术团队管理笔记(一)-识人技术管理者如何向上汇报