技术团队管理笔记(二)-带人

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

上一篇技术团队管理笔记(一)-识人得到了你们的喜好，也和不少朋友作了交流，很是感谢你们的支持，本篇咱们开讲技术团队管理笔记(二)-带人

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

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

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

电视剧汉武大帝里有一段曾让我印象很是深入，霍去病说本身打仗还会带厨子专门给本身作饭，被李广和卫青鄙视，他们说，为将者和士兵患难与共仍是须要的。霍去病回答道：带兵打仗，须要的毫不是行仁义。将帅的目标，只有一个，那就是赢。仗打不赢，就是每天和士兵患难与共，也是个无能之将(仗若是打赢了，将士天然论功行赏)。这正说明了，管理者为公司赢得红利高于一切。

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

1. 作项目的核心目的是为了带人，作成是结果
   ，理解这第一点最为关键和精妙，不少同窗在带项目的时候，看上去事必躬亲。天天像救火队员同样帮助团队成员解决各类技术问题，也会耐心和他们讲解好的技术方案，可是效果却不尽如人意。由于你会错意了，真正优秀的管理者是管人无论事，也是咱们常说的“无为而治”。若是你的团队成员够强，项目天然是能成功的。若是你的团队不够强，就算你一次次靠优秀的我的能力堵上了窟窿，你的团队也没有成长性，更没有将来。因此若是要作一个“四两拨千斤”的优秀管理者，请把你的重点放在带人上，放在关键的事情上，而不是在项目的杂事上。

2. 提高下属的思惟高度高于帮助其解决问题 ，深入理解到了第一点，那这第二点就是精彩的开始。咱们来推演一个场景，假设你团队里的一位工程师使用了一个开源框架，由于框架自己不是很是成熟或者他的使用方式有问题，最后在某个项目的发布中，致使程序内存溢出了。 咱们来看下以结果为目的和以带人为目的的不一样处理方式：

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

3. 怎么设定好下属的目标是个学问 ，给下属设定目标也是很是重要的，有了目标，他们才能往那个方向去努力，才能成长嘛。不少管理文章都会提到，设定的目标通常比人的当前能力高20%到30%左右。这个确定是没错的，也必须按照这样来，但这里有一个关键问题：修正幅度。 你不是先知，给下属设定的目标不必定每次都是对的，颇有可能高了或低了，这以后怎么办呢？切记不要一次修正幅度过大，要慢慢修正。高了或低了，就先正负修正10%左右，再观察一下下属的表现，若是仍是不匹配，那就再修正10%左右。这种作法有一个好处：对有上进欲望的同窗，不至于由于目标过高而让他失去积极性，慢慢加量，帮他不断提高。对无上进欲望的同窗，则能够慢慢边缘化，避免团队震荡，由于目标每每决定了你会负责多少事。

4. 越重要越紧急的项目越要严格要求 ，这也是一个很关键的点，我看过不少技术管理者，由于ceo的业务压力，在一些很是重要且时间紧急的项目中默认了团队不须要作很是详细的系统设计后再开始编码，甚至对开发的自我测试要求也会下降（指望早点发给专业的QA去测试以节省时间）。首先从项目的成功角度来讲，确定是错的，没有好的设计和测试，颇有多是会作失败的。另外从带人的角度来看，这种作法给团队传递了一种极其错误的态度：越是重要的项目（这种项目每每进度也很急）越不须要设计和自测。这不是带人了，简直就是毁人啊，对团队将来的成长带来不可估量的阻碍。今天你给本身所谓的方便，明天必将几倍的反噬于你，到时你再怎么努力扭转都无济于事。在军队中有一种观点，就算败了，阵型也不能乱，其实说的就是这个道理。对于重要的项目不但不应放松，反而应该更加严格要求，给团队传递正确的信号：越是重要的项目越要严格要求。

5. 先从核心人员带起 ，还记得上篇文章技术团队管理笔记(一)-识人里定义的5类人吗，在这个地方就要发挥做用了，以下处理方法：

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

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

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

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

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