技术管理者的必修课：识人和用才的十项要义

“识人之术与带人之要的关键点是集中你的精力做好最关键的事，把精力放在真正需要关心的人身上。"

 

 

首先在开头声明，本文所讲的技术管理，是一位原先在大公司的码农不甘寂寞，出来加入小公司后的管理心得记录。

 

大公司到小公司的落差是全方位的，制度、氛围、资源、人才，各方面皆有。从最初的不适应到一路磕磕碰碰坚持到现在，心中充满感恩和侥幸，觉得有必要让自己做下记录和总结。

 

从 2017 年 11 月份开始，截至此时我所管理的技术团队为 30 人。此背景可做参考，例子可能和您的团队不符，但是思路可能相同，欢迎同道中人一起讨论切磋。

 

管理技术——识人之术

 

很多同学从工程师慢慢转型到技术管理者时，常常会有两种思路：

 

• 管理范：作为技术出身的我向来逻辑缜密，管理不就是追求严谨吗？我自信可以设计出一套制度流程让团队变得有序高效，比如好的发布流程、系统设计评审流程、code review 流程。

• 技术范：我是技术精英，所以我的团队也一定是精英。像美剧硅谷一样，我不应该对我的团队过多干涉，尊重每个人的想法，让大家自由发挥，每周必须要搞高大上的技术分享，技术也要紧跟潮流，Go、虚拟化、机器学习一个都不能少，这样就可以做出牛逼的产品，吸引更多的牛人加入。

 

单靠这两种思路都无法带出强力的团队，本质在于只重了形，而没有关注神，真正好的管理是“无为而治”。老子认为“我无为，而民自化；我好静，而民自正；我无事，而民自富；我无欲，而民自朴”，而且强调“无为而无不为”。

 

“无为而治”并不是什么也不做，而是不过多的干预、充分发挥万民的创造力，做到自我实现。简单来说要真正做到“关注人”，而不是“管理”。

 

很多同学会说，关注人？好啊，我天天找大家谈心，了解他们的想法，满足需求就可以了吧？

 

诚然这是非常重要的手段，但是在这之前有一步非常关键的工作需要去做，那就是识人。

 

举个例子，为什么韦小宝能够顺风顺水，八面玲珑，还能把事办成？因为他很早就分清了，哪些是皇上的人、哪些是天地会的人、哪些是神龙教的人；哪些人是为钱的、哪些人是为权的、哪些人是为民的。

 

对于每一种人他都采取了不同的对待策略，精确匹配了各种人的需求，就像我们代码里写的 switch case 一样，逻辑隔离精确。只有做到这样，才能发挥好团队中每一个人的能力，从而让团队变得越来越高效。

下面说说我自己总结的“识人流程”：

 

先识人再做事

 

和之前说的一样，当你在组建或接收一个团队的时候，先不要急着去改变既有的做事方式或流程，应该把重点先放在识人上，搞清楚你的团队有哪些人组成，他们在意需要什么，目标是否和你一致，他们的能力和潜力如何。

就像在熟悉一个系统一样，在没有看清原有逻辑、发现有多少坑前，就不要动手去改，否则很容易改出 BUG，这个逻辑顺序千万不能错。这些关于人的信息掌握得越细致，对后续工作的展开越有利。

 

建立成员的类别

 

一般来说，对于一个技术团队我会把成员分为如下类别：

 

识别成员进不同的类别

 

一般识别的方式有：当面沟通、私下侧面了解、观察他们的做事方式等。

 

把握一个原则：客观真实。把他们在过往项目中的实际表现、在日常沟通中的思维表现一一和以上表格做对比。假设一个人有 10 个判断素材，则占比 80% 以上的类别，那基本就是符合的。

 

不同的类别采取不同的策略

 

 

简单来说，所谓的用人策略就是：如何定义人的角色、如何安排事务、如何安排资源的综合计划。有一个关键点是集中你的精力做好最关键的事，把精力放在真正需要关心的人身上。团队越大，对你精力的挑战越大，曾经有一种说法是“你能高效直接管理的只有 6 个人。”不是没有道理的。

 

识人的基本方法大概就是这样。这一步如果做对了，对团队管理而言 40% 已经成功了。遵守上面的流程，提升识人的能力。如果在实践中发生了偏差（主要是由于经验问题把成员识别错了类别），需要不断做总结反思并及时修正。

 

在我搭建团队的初期，几乎每天都会做反思总结，把大家写的代码、做的系统设计、沟通的表现、项目的完成度拿出来反复衡量斟酌。一旦类别定了，就要对自己有信心，坚决执行相应的策略。这点是非常重要的，一个领导者必须对自己反复思考的决策有信心，并坚定执行，否则就不要做。

 

技术管理——带人之要

 

接下来我们来谈谈“带人”的问题。

 

首先我们先搞清楚一个核心问题：为什么要带人？

 

有的同学会说带人是为了让团队更有战斗力，从而可以做好项目; 有的会说可以让自己从细节工作中慢慢解脱出来，有更多时间考虑架构的问题; 有的会说非常有成就感，看到下属一个个成长起来这种感觉喜不胜收。这些说法从结果来看，都是正确的，但似乎和公司的整体战略目标有点距离？

在这里，我提一个新的观点，带人的核心目的是：通过提升团队的能力，为公司赢得 3 到 6 个月的成长红利期，且暂时不需要付出额外成本（一般 6 个月到 1 年左右会有加薪需求）。

 

当这个红利帮助公司拿下既定业务目标后，整个团队就可以享受公司成长的收益（加薪），从而形成良性循环。

 

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

 

• 为公司赢得 3 到 6 个月的成长红利期高于一切，只有当公司获得收益后才能反哺团队，你才能够建立真正的威信。

• 在带人的时候难免会让团队觉得更累了，要付出更多了，但此时绝不能心软，更不能有“万一我在技术上对大家要求很严格，但是公司最后没有给团队加薪，那我的个人信用岂不是破产”的错误想法。

  因为没有那 3 到 6 个月的成长红利期，公司是不可能成功的，说句打击士气的话，万一努力了，公司还没赢得业务目标怎么办？哈哈，这不是你作为技术管理者能决定的问题了，你只有往前看一条路。

• 带人是没有止境的，因为你需要永远为公司的发展创造出空间，所以一刻都不能松懈。

 

电视剧汉武大帝里有一段曾让我印象非常深刻，霍去病说自己打仗还会带厨子专门给自己做饭，被李广和卫青鄙视，他们说，为将者和士兵同甘共苦还是需要的。

 

霍去病回答道：带兵打仗，需要的绝不是行仁义。将帅的目标，只有一个，那就是赢。仗打不赢，就是天天和士兵同甘共苦，也是个无能之将（仗如果打赢了，将士自然论功行赏）。这正说明了，管理者为公司赢得红利高于一切。

 

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

 

做项目核心目的是为了带人 做成是结果

 

理解这第一点最为关键和精妙，很多同学在带项目的时候，看上去事必躬亲，每天像救火队员一样帮助团队成员解决各种技术问题，也会耐心和他们讲解好的技术方案，但是效果却不尽如人意。

 

因为你会错意了，真正优秀的管理者是管人不管事，也是我们常说的“无为而治”。

如果你的团队成员够强，项目自然是能成功的；如果你的团队不够强，就算你一次次靠优秀的个人能力堵上了窟窿，你的团队也没有成长性，更没有未来。

 

所以如果要做一个“四两拨千斤”的优秀管理者，请把你的重点放在带人上、放在关键的事情上，而不是在项目的琐事上。

 

提升下属思维高度高于帮助其解决问题

 

深刻理解到了第一点，那这第二点就是精彩的开始。

 

我们来推演一个场景，假设你团队里的一位工程师使用了一个开源框架，因为框架本身不是非常成熟或者他的使用方式有问题，最后在某个项目的发布中，导致程序内存溢出了。 我们来看下以结果为目的和以带人为目的的不同处理方式：

 

以结果为目的：

 

使用专业的内存分析工具，帮助工程师发现问题所在，并剖析开源框架的源代码，告知工程师框架有何问题或以后该怎么使用。

 

以带人为目的：

 

干完以结果为目的该干的所有事之后，问一下工程师，你觉得使用一个第三方的开源框架，怎么样才算是正确的做法？在和工程师一番讨论后，你抛出自己鲜明的观点：

 

• 开源框架也是人写的，可能就是有问题的。

• 在使用任何开源框架前，我们都该知其然知其所以然 。

• 牛逼的技术不在于你研究和使用了多少开源框架，而是你能不能永远做出稳定的商业化系统，开源只是你的手段和工具而已。

 

明白两者的区别了吗？以结果为目的就只是看到了一棵树，而放弃了整个森林，看似解决了这次的问题，保证了项目顺利发布，但是下一次你的工程师还会掉进开源的坑里。

 

而以带人为目的的方案，你不但解决了问题，还开始尝试提升下属的思维高度，以后他不再会掉入任何的开源坑里，且真正明白了何为稳定的商业化系统。在日后，就算使用公司内的其他公共服务，他都会非常小心，那是质的变化。

 

所以，请一定要记住，提升下属的思维高度高于帮助其解决问题。

 

怎么设定好下属的目标是个学问

 

给下属设定目标也是非常重要的，有了目标，他们才能往那个方向去努力，才能成长。很多管理文章都会提到，设定的目标一般比人的当前能力高 20% 到 30% 左右。这个肯定是没错的，也必须按照这样来，但这里有一个关键问题：修正幅度。

你不是先知，给下属设定的目标不一定每次都是对的，很有可能高了或低了，这之后怎么办呢？切记不要一次修正幅度过大，要慢慢修正。高了或低了，就先正负修正 10% 左右，再观察一下下属的表现，如果还是不匹配，那就再修正 10% 左右。

 

这种做法有一个好处：对有上进欲望的同学，不至于因为目标太高而让他失去积极性，慢慢加量，帮他不断提升。对无上进欲望的同学，则可以慢慢边缘化，避免团队震荡，因为目标往往决定了你会负责多少事。

 

越重要越紧急的项目越要严格要求

 

这也是一个很关键的点，我看过很多技术管理者，因为 CEO 的业务压力，在一些非常重要且时间紧急的项目中默认了团队不需要做非常详细的系统设计后再开始编码，甚至对开发的自我测试要求也会降低（期望早点发给专业的 QA 去测试以节省时间）。

首先从项目的成功角度来说，肯定是错的，没有好的设计和测试，很有可能是会做失败的。

 

另外从带人的角度来看，这种做法给团队传递了一种极其错误的态度：越是重要的项目（这种项目往往进度也很急）越不需要设计和自测。这就不是带人了，只会对团队未来的成长带来不可估量的阻碍。

 

今天你给自己所谓的方便，明天必将几倍的反噬于你，到时你再怎么努力扭转都无济于事。

 

在军队中有一种观点，就算败了，阵型也不能乱，其实说的就是这个道理。对于重要的项目不但不该放松，反而应该更加严格要求，给团队传递正确的信号：越是重要的项目越要严格要求。

 

先从核心人员带起

 

前文我们定义了5类人：

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

 

细心留意真正需要你介入的时机

 

带人的介入时机也是很有讲究的，因为带人总免不了说教。你想想如果你作为一个员工，被自己的老板指出这里和那里的不足，就算老板是为你好，你的心里总是不舒服的，因为人的本能就是抗拒自己的缺点的。

 

所以当你在向下属指点的时候，如果他在本能上是抗拒的，那效果肯定是不好的。何时是你介入的好时机呢？

 

这里有一个窍门：

 

在你的下属碰到了一些困难正手足无措需要帮助的时候，且这个困难不至于对整个项目产生致命的威胁，雪中送炭，才是你带人的好时机，你的下属在这个时候更多是感恩，能听得进你的建议。

 

千万不要迷恋什么每月谈话，看看下属需要什么帮助这种冠冕堂皇的套路，远远没有雪中送炭的作用和意义大。但是度要把握好，不能等你的下属都要被烧死了，你才进去帮忙，那真是晚了。你下属的每一次跌倒，一定能记住痛，也是他能否成长的关键时刻，这个时候才需要你的出现！

总的来说理解带人的目的最为重要。在真正理解带人的意义之后，只要足够耐心，采用合理的方法，就能把团队越带越强，从而享受到产生的红利。带好了人后，只有用对了，才能真正发挥作用，团队管理才会产生好的效果。

 

作者：jackjoe

来源：https://www.jianshu.com/u/d49dd66f7663