|
|
作者：jackjoe_刘轶
（一）技术管理笔记：识人
声明：所谓的技术管理笔记，是一位原大公司的码农不甘寂寞，出来加入创业公司后的管理心得记录。大公司到创业公司的落差是全方位的，制度，氛围，资源，人才皆有。从最初的不适应到一路磕磕碰碰活到现在。心中充满感恩和侥幸，觉得有必要强迫自己做下记录和总结。遂开始于2017年11月份，截止此时我所管理的技术团队为50人。此背景可做参考，例子可能和您的团队不符，但是思路可能相同，欢迎同道中人一起讨论切磋。
很多同学从工程师慢慢转型到技术管理者时，常常会有两种思路:
管理范：作为技术出身的我向来逻辑缜密，管理不就是追求严谨吗？我自信可以设计出一套制度流程让团队变得有序高效，比如好的发布流程，系统设计评审流程，code review流程
技术范：我是技术精英，所以我的团队也一定要是精英。像美剧硅谷一样，我不应该对我的团队过多干涉，尊重每个人的想法，让大家自由发挥，每周必须要搞高大上的技术分享，技术也要紧跟潮流，go，虚拟化，机器学习一个都不能少。这样就可以做出牛逼的产品，吸引更多的牛人加入
单靠这两种思路都无法带出强力的团队，本质在于只重了形，而没有关注神，真正好的管理是“无为而治”。老子认为“我无为，而民自化；我好静，而民自正；我无事，而民自富；我无欲，而民自朴”，而且强调“无为而无不为”。
“无为而治”并不是什么也不做，而是不过多的干预、充分发挥万民的创造力，做到自我实现。简单来说要真正做到“关注人”，而不是“管理”。
很多同学会说关注人嘛，好啊我天天找大家谈心，了解他们的想法，满足需求就可以了吧。诚然这是非常重要的手段，但是在这之前有一步非常关键的工作需要去做，那就是识人。
举个例子为什么韦小宝能够顺风顺水，八面玲容，还能把事办成？因为他很早就分清了，哪些是皇上的人，哪些是天地会的人，哪些是神龙教的人，哪些人是为钱的，哪些人是为权的，哪些人是为民的。对于每一种人他都采取了不同的对待策略，精确匹配了各种人的需求，就像我们代码里写的switch case一样，逻辑隔离精确。只有做到这样，才能发挥好团队中每一个人的能力，从而让团队变得越来越高效。
下面说说我自己总结的“识人流程”
先识人再做事
和之前说的一样，当你在组建或接收一个团队的时候，先不要急着去改变既有的做事方式或流程。应该把重点先放在识人上，搞清楚你的团队有哪些人组成，他们在意需要什么，目标是否和你一致，他们的能力和潜力如何。就像在熟悉一个系统一样，在没有看清原有逻辑，发现有多少坑前，就不要动手去改，否则很容易改出BUG，这个逻辑顺序千万不能错。这些关于人的信息掌握得越细致，对后续工作的展开越有利。
建立成员的类别
一般来说，对于一个技术团队我会把成员分为如下类别：
类别 定义
优秀的工程师 技术优秀，认同公司目标，有很强的自驱力，喜欢发现问题，解决问题
有一定工程师思维的潜力程序员 认同公司目标，有很强的自驱力，技术尚在快速成长期
有一定工程师思维的普通程序员 认同公司目标，有很强的自驱力，技术潜力一般
熟练的程序员 技术比较扎实，但是没有太多工程师思维
普通程序员 技术一般，也没有太多工程师思维
识别成员进不同的类别
一般识别的方式有：当面沟通，私下侧面了解，观察他们的做事方式等。把握一个原则：客观真实，把他们的在过往项目中的实际表现，在日常沟通中的思维表现一一和以上表格做对比。假设一个人有10个判断素材，则占比80%以上的类别，那基本就是符合的。
不同的类别采取不同的策略
类别 应对策略
优秀的工程师 让他承担更多的责任，负责更多的事情(比如负责一大块的技术架构)，提供更多的资源
有一定工程师思维的潜力程序员 提供更多专业的指导和更大的舞台(让他参与关键项目，在技术上严格要求，从代码细节抓起)，提供更多的资源
有一定工程师思维的普通程序员 让他们负责一些技术难度不高但要求非常严谨认真的工作，提供一定的指导，不用给太多压力，让他们慢慢成长
熟练的程序员 更对地要去提升他的思考方式(非技术)，需要谨慎考虑他的潜力和价值比。在思考方式没有提升前，可能只能去做一些相对独立，对团队协作要求不高的工作。可以让他们在技术上给新员工做出指导，但不能是思考方式。
普通程序员 维持现状，无资源倾斜
简单来说，所谓的用人策略就是：如何定义人的角色，如何安排事务，如何安排资源的综合计划。有一个关键点是集中你的精力做好最关键的事，把精力放在真正需要关心的人身上。团队越大，对你的精力挑战越大，有一种说法，你能高效直接管理的只有6个人。
识人的基本方法已经讲完了，这一步如果做对了，对团队管理而言40%已经成功了。如果要提升识人的能力，要严格遵守上面的流程。如果在实践中发生了偏差（主要是由于经验问题把成员识别错了类别），需要不断做总结反思并及时修正。在我搭建团队的初期，几乎每天都会做反思总结，把大家写的代码，做的系统设计，沟通的表现，项目的完成度拿出来反复衡量斟酌。一旦类别定了，就要对自己有信心，坚决执行相应的策略。这点是非常重要的，一个领导者必须对自己反复思考的决策有信心，并坚定执行，否则就不要做。
（二）技术管理笔记：带人
首先我们先搞清楚一个核心问题：为什么要带人
有的同学会说带人是为了让团队更有战斗力，从而可以做好项目; 有的会说可以让自己从细节工作中慢慢解脱出来，有更多时间考虑架构的问题; 有的会说非常有成就感，看到下属一个个成长起来这种感觉喜不胜收。这些说法从结果来看，都是正确的，但似乎和公司的整体战略目标好像有点距离？
在这里，我提一个新的观点，带人的核心目的是：通过提升团队的能力，为公司赢得3到6个月的成长红利期，且暂时不需要付出额外成本(一般6个月到1年左右会有加薪需求)。当这个红利帮助公司拿下既定业务目标后，整个团队就可以享受公司成长的收益(加薪)，从而形成良性循环
这句话看上去非常市侩，恩，很像资本家无情的剥削想法:)，但这其中透露了几个关键点：
为公司赢得3到6个月的成长红利期高于一切，只有当公司获得收益后才能反哺团队，你才能够建立真正的威信。
在带人的时候难免会让团队觉得更累了，要付出更多了。但此时绝不能心软，更不能有“万一我在技术上对大家要求很严格，但是公司最后没有给团队加薪，那我的个人信用岂不是破产”的错误想法。因为没有那3到6个月的成长红利期，公司是不可能成功的。说句打击士气的话，万一努力了，公司还没赢得业务目标怎么办？哈哈，这不是你作为技术管理者能决定的问题了，你只有往前看一条路
带人是没有止境的，因为你需要永远为公司的发展创造出空间，所以一刻都不能松懈
电视剧汉武大帝里有一段曾让我印象非常深刻，霍去病说自己打仗还会带厨子专门给自己做饭，被李广和卫青鄙视，他们说，为将者和士兵同甘共苦还是需要的。霍去病回答道：带兵打仗，需要的绝不是行仁义。将帅的目标，只有一个，那就是赢。仗打不赢，就是天天和士兵同甘共苦，也是个无能之将(仗如果打赢了，将士自然论功行赏)。这正说明了，管理者为公司赢得红利高于一切。
明白带人的意义后，我们来讲一下带人的几个心法
1.做项目的核心目的是为了带人，做成是结果
，理解这第一点最为关键和精妙，很多同学在带项目的时候，看上去事必躬亲。每天像救火队员一样帮助团队成员解决各种技术问题，也会耐心和他们讲解好的技术方案，但是效果却不尽如人意。因为你会错意了，真正优秀的管理者是管人不管事，也是我们常说的“无为而治”。如果你的团队成员够强，项目自然是能成功的。如果你的团队不够强，就算你一次次靠优秀的个人能力堵上了窟窿，你的团队也没有成长性，更没有未来。所以如果要做一个“四两拨千斤”的优秀管理者，请把你的重点放在带人上，放在关键的事情上，而不是在项目的琐事上。
2.提升下属的思维高度高于帮助其解决问题
，深刻理解到了第一点，那这第二点就是精彩的开始。我们来推演一个场景，假设你团队里的一位工程师使用了一个开源框架，因为框架本身不是非常成熟或者他的使用方式有问题，最后在某个项目的发布中，导致程序内存溢出了。 我们来看下以结果为目的和以带人为目的的不同处理方式：
以结果为目的：使用专业的内存分析工具，帮助工程师发现问题所在，并剖析开源框架的源代码，告知工程师框架有何问题或以后该怎么使用
以带人为目的：干完以结果为目的该干的所有事之后，问一下工程师，你觉得使用一个第三方的开源框架，怎么样才算是正确的做法？在和工程师一番讨论后，你抛出自己鲜明的观点：1 开源框架也是人写的，可能就是有问题的 2 在使用任何开源框架前，我们都该知其然知其所以然 3 牛逼的技术不在于你研究和使用了多少开源框架，而是你能不能永远做出稳定的商业化系统，开源只是你的手段和工具而已。
明白两者的区别了吗？以结果为目的你只是看到了一棵树，而放弃了整个森林，看似解决了这次的问题，保证了项目顺利发布，但是下一次你的工程师还会掉进开源的坑里。而以带人为目的的方案，你不但解决了问题，还开始尝试提升下属的思维高度，以后他不再会掉入任何的开源坑里，且真正明白了何为稳定的商业化系统。在日后，就算使用公司内的其它公共服务，他都会非常小心，那是质的变化！所以，请一定要记住，提升下属的思维高度高于帮助其解决问题。
3.怎么设定好下属的目标是个学问
，给下属设定目标也是非常重要的，有了目标，他们才能往那个方向去努力，才能成长嘛。很多管理文章都会提到，设定的目标一般比人的当前能力高20%到30%左右。这个肯定是没错的，也必须按照这样来，但这里有一个关键问题：修正幅度。
你不是先知，给下属设定的目标不一定每次都是对的，很有可能高了或低了，这之后怎么办呢？切记不要一次修正幅度过大，要慢慢修正。高了或低了，就先正负修正10%左右，再观察一下下属的表现，如果还是不匹配，那就再修正10%左右。这种做法有一个好处：对有上进欲望的同学，不至于因为目标太高而让他失去积极性，慢慢加量，帮他不断提升。对无上进欲望的同学，则可以慢慢边缘化，避免团队震荡，因为目标往往决定了你会负责多少事。
4.越重要越紧急的项目越要严格要求
，这也是一个很关键的点，我看过很多技术管理者，因为ceo的业务压力，在一些非常重要且时间紧急的项目中默认了团队不需要做非常详细的系统设计后再开始编码，甚至对开发的自我测试要求也会降低（期望早点发给专业的QA去测试以节省时间）。首先从项目的成功角度来说，肯定是错的，没有好的设计和测试，很有可能是会做失败的。另外从带人的角度来看，这种做法给团队传递了一种极其错误的态度：越是重要的项目（这种项目往往进度也很急）越不需要设计和自测。这不是带人了，简直就是毁人啊，对团队未来的成长带来不可估量的阻碍。今天你给自己所谓的方便，明天必将几倍的反噬于你，到时你再怎么努力扭转都无济于事。在军队中有一种观点，就算败了，阵型也不能乱，其实说的就是这个道理。对于重要的项目不但不该放松，反而应该更加严格要求，给团队传递正确的信号：越是重要的项目越要严格要求。
5.先从核心人员带起
，还记得上篇文章技术团队管理笔记(一)-识人里定义的5类人吗，在这个地方就要发挥作用了，如下处理方法：
类别 定义 带人策略
优秀的工程师 技术优秀，认同公司目标，有很强的自驱力，喜欢发现问题，解决问题 需要你亲自带
有一定工程师思维的潜力程序员 认同公司目标，有很强的自驱力，技术尚在快速成长期 由第1类人来带，在需要你带的时候再介入
有一定工程师思维的普通程序员 认同公司目标，有很强的自驱力，技术潜力一般 由第1类人来带
熟练的程序员 技术比较扎实，但是没有太多工程师思维 由第1或第2类人来带
普通程序员 技术一般，也没有太多工程师思维 由第2类人来带，你需要关注不能因为个体原因影响到整个团队
记住，你的带人精力是有限的，要把精力花在最该需要的地方和人身上，才能事半功倍。
6.细心留意真正需要你介入的时机
，带人的介入时机也是很有讲究的，因为带人总免不了说教。你想想如果你作为一个员工，被自己的老板指出这里和那里的不足，就算老板是为你好，你的心里总是不舒服的，因为人的本能就是抗拒自己的缺点的。如果你在向下属指点的时候，他在本能上是抗拒的，那效果肯定是不好的。那何时是你介入的好时机呢？
这里有一个窍门：在你的下属碰到了一些困难正手足无措需要帮助的时候，且这个困难不至于对整个项目产生致命的威胁。雪中送炭，才是你带人的好时机，你的下属在这个时候更多是感恩，能听得进你的建议。千万不要迷恋什么每月谈话，看看下属需要什么帮助这种冠冕堂皇的套路，远远没有雪中送炭的作用和意义大。但是度要把握好，不能等你的下属都要被烧死了，你才进去帮忙，那真是晚了。你下属的每一次跌倒，一定能记住痛，也是他能否成长的关键时刻，这个时候才需要你的出现！
带人这篇已经表完，总的来说理解带人的目的最为重要。在真正理解带人的意义之后，只要足够耐心，采用合理的方法就能把团队越带越强，从而享受到产生的红利
（三）技术管理笔记：用人
首先我们探讨一个问题，用人的最大核心是什么？
你一定有过这样的困扰：
为什么我的团队能力都不错，但从项目的结果来看，总是磕磕碰碰，要么就是进度延期要么就是系统不稳定？
为什么我常常告诉下面的同学要在赶项目进度的同时，兼顾好系统的扩展性，稳定性，却还是很难做到位？
为什么我和团队讨论了一些好的流程制度，但最后大家都会慢慢淡忘，直至废弃？是推进的同学能力不够吗？
这里抛出一个观点，90%的原因是因为团队“懒”，用人最最重要的一点，就是帮大家克服“懒”
看到这里，团队里的很多同学肯定要喷我了，自从干了这一行，天天加班到9,10点，黑芝麻，枸杞都吃上了，这还算懒，又开始剥削了？
别急，听我慢慢道来。我们来借鉴一下产品经理的思考方式，一个好的产品如果要成功，必须把握人性。比如支付宝等年账单统计，在年底的时候朋友圈被刷爆了，其本质就是满足自我的虚荣心。
支付宝不花任何推广费用，自然就达到了传播的效应，这里就是把握到了“虚荣心”这个人性。
不管时代和科技是如何发展的，人性是永远不会变的。懒惰是一个非常基本的人性，任何人骨子里其实都是懒惰的，再优秀的人也会点外卖，这也是懒惰的一种表现，他不愿意去饭馆吃饭，懒。
但是没有人愿意直接承认自己“懒”
为什么？很简单，因为人还有虚荣的人性，直接承认自己“懒”，多没面子啊。
你一定经常听到团队里的成员会这么和你说“我知道这个系统优化很重要，但这次为了项目进度不延期和稳定上线，所以暂时先延后”，这其实就是一种懒的表现。
我们来翻译下他内心的真实想法：
这个系统优化确实挺重要，但是我感觉以我现在的能力做起来有些挑战，算了，暂时不要去碰这个麻烦的事了。以项目进度不延期和稳定上线为由，老大估计也不会有意见。恩，我还是想优化的哦，这次先等等，下次有机会再优化，我还是一个好同学，恩。（其实他只要有这种想法，几乎不会再去优化，并且往往就算他本次做了优化，也不会多加太多班，好的架构是持续不断积累出来的，而不是靠一次优化）
这里我强调一下，我并没有鄙视这种想法，每一个人都会有懒的想法，只是表现形式不同而已。用更官方的话来说：只要不愿意离开舒适区，去探索一些自己当前不怎么熟悉的事，都是懒的表现
不肯离开舒适区的表现很多啦，比如：
我就是测试我不想去学一点开发的代码逻辑（以开发不会教我为由）
我是运维我不关心开发的服务是处理什么业务的，我只管部署（以了解业务，对做好运维没有帮助为由）
我是业务开发，我知道底层的框架有这里那里的不足，但和我没关系，我不需要参与底层框架的优化（以技术部门已经分业务组，框架组为由）
但是作为一个优秀的管理者，你需要做到：
尽量要通过各种方式让团队时刻承认自己是懒的，包括你也是懒的
当发现大家懒的时候，退却的时候，你在后面要去推一把，小事比大事有时候更重要
做到这两点有什么好处呢？
首先对于第一点，目的就是先要让大家克服虚荣心的人性，先承认自己是懒的，这样会让以后的沟通变得十分高效。想做就做，不想做就说自己懒了，不要绕那么多弯。先得承认自己懒了，这样别人才能来推你一把，克服懒。
对于第二点，就是你发挥技术专业的时候了，作为技术管理者，你的专业经验可以帮助你识别出当前团队是否用了全力，还有多少潜力可以挖掘。
只要还有余力，并且大家确实是懒了，你应该给大家鼓劲，用你的专业经验去帮助大家，目的就是让大家克服这次的懒，努力去做，最后体验到一次完整的克服懒-成功的经验。这段经验非常重要，会让你团队的成员慢慢建立起克服懒的自信心。
以后你只要说出目标，他们都会用自己不断摸索积累来的经验去100%努力达成，而不是用你给的方法碰壁后，就原地继续等待直至你给出另一个新方法，这样才算是用好了人！
合适的人做合适的事
人尽其才也是用人非常重要的一点，在这里我们简单做一个分类总结
类别 适合做的事
技术能力强，且做业务项目意愿强 50%时间做基础技术建设，50%时间做业务项目
技术能力强，做业务项目意愿一般 70%时间做基础技术建设，30%时间做业务项目，还是需要做一些业务项目来积累实际经验，避免一直做基础技术变成空中楼阁
技术能力一般，做业务项目意愿强 20%时间做基础技术建设，80%时间做业务项目，以做业务项目为主，适当参与一些基础技术建设，持续提升技术能力
技术能力一般，做业务项目意愿一般 100%时间做业务项目
定目标时要虚实结合
我们来举一个例子，比如这个时候线上系统发生了一个不太紧急但比较重要的问题，你和下属说去查一下问题，然后告诉我原因。这个目标从排查角度来说是没有问题的，但是太实了，缺少一点虚的味道。如果你能再补上下面一段话，就非常好了：对于这个问题我除了想知道原因，更希望你是用逻辑准确的方式去查出这个问题，否则没有意义。因为我希望你从现在起就锻炼自己查问题的能力，查的准查的快，把它当作是一种练习。这样以后线上如果发生非常紧急的问题，你就可以很快解决了，不用通宵加班了。
我相信虽然你并没有改变实质的目标，但这个虚的说法会让你下属的心有一些“小触动”，并埋入了一根刺。哪怕这次没有发生化学反应，在之后他一定能有所体会。比如又发生了一次紧急的问题，而他因为没有积累正确的查问题经验，导致最后加班到很晚。这个时候你去帮他一把，并把之前说过的虚的事情再提下，他一定会有所变化。之后再发生新的问题，他除了查出原因之外，一定会非常重视自己经验的积累和提高，从而使他在查问题的能力上会变得越来越强。
去中心化
记住这句话：永远不要依赖一个人的能力。就像一个球队一样，你必须保证替补板凳的深度，并做出一定的轮换。对你的团队而言，除了几个核心成员之外，你必须保证有第二梯队，第三梯队。任何项目，都应该是核心成员+第二梯队+第三梯队一起来推进。找各种机会，让第二梯队的同学可以顶上来，在一些重要项目上让他们也慢慢牵头推进。
去中心化会带来几个好处:
核心成员人数在团队里是有限的，不要因为他们的精力有限，而让业务项目的推进发生瓶颈，核心成员应该去做更关键的事情。
项目的成功不依赖于任何一个人，让核心成员和第二梯队的同学都觉得自己是可以做的，形成一定的良性竞争氛围，从而更好推进项目。
万一核心成员有变动，因为第二梯队已经锻炼过了，可以马上顶上，从而降低对团队的冲击影响。
去中心化比较简单的策略就是：除了发挥好核心成员的作用外，尽量找各种机会去锻炼第二梯队的同学，让他们也成为准核心同学。万一他们在某个项目上顶不住了，让核心成员来帮忙兜底，保证项目的顺利落地。
顺便再说一句，哪怕是你，作为最终管理者也应该是被去中心化的，个中道理大家自己去体会下。
用人篇到此结束了，最近这段时间因为公司完成了新一轮融资，事情非常之多，所以耽搁了很久，非常抱歉。
后续会约束自己，不管是管理上还是技术上，每两月至少更新一篇，希望能做到共勉，谢谢！
转自：https://segmentfault.com/a/1190000012464174
程序猿的技术大观园：www.javathinker.net
|
|
Java技术网站 → 『 IT人员的生存、生活和人文 』 → 『 IT职场随笔 』 → 技术团队管理笔记
消息
查看
搜索
好友
邮件
复制
引用
IP: 已设置保密
