## 程序员的必经之路
技术人转型做管理后，可以分配在技术上的时间会越来越少，尤其是写代码的机会也越来越少，手越来越生疏。而需要做的技术评审和技术决策类工作却有增无减，加上管理者的决策产生的影响比之前更大了，因此对技术判断力的要求也越来越高。无怪乎会有新经理抱怨说：
>“技术管理者是有违人性的，一方面自己的技术越来越差，另外一方面却要带领整个技术团队。”
技术管理者对于如何保持技术能力的焦虑，可见一斑。
不仅我们自己焦虑，我们的上级和前辈也时常告诫我们：“技术管理者要保持自己的技术判断力”，可见这个问题是大家都很重视的。话说，大家也只是强调，却很少有人明确告诉我们，技术判断力都包含了哪些内容，以及应该怎么去保持。现在，我就来聊一聊这个问题，看看在管理工作越来越繁重的情况下，技术管理者该如何保持在技术上的判断力。
## 兼顾“技术”和“管理”
技术管理者和普通管理者最大的区别就是“技术”二字，这也是技术管理者最鲜明的标签和最大的竞争力。也正是因为这两个字，让众多的技术新经理陷入困扰之中，不知道该如何兼顾“技术”和“管理”。
实际上，从技术工程师到技术管理者的转型，有很多做事的思路和方法都需要转变。其中一个重要的转变就是你和技术的关系，也就是技术对你来说意味着什么。
当你还是一位工程师时，你是技术的操作者和实现者，一个个技术服务都从你的手中诞生；而在成为一个越来越成熟的管理者的过程中，你越来越少地直接去实操，慢慢变成了技术的应用者，你需要的是把工程师生产出来的技术服务装配成更大的服务或产品。
这么说可能有点枯燥，前面我们曾经把做技术管理类比成组装计算机：当你是一名技术工程师时，需要关心的是一个电子芯片该如何生产，一个特定功能的板卡该怎么实现；而如果你成为一名技术管理者后，需要关心的则是如何使用这些电子芯片和板卡，组装成一台好用的计算机，甚至是各种各样的其他设备。而做管理前后对于技术的态度，就好比研制板卡组件和计算机整机组装的关系，我们更关心这些组件的功能设计、性能指标、兼容情况，而不是去弄清楚每一个组件的内部实现逻辑。
由此可见，当你的工作角色，从一个“技术实现者”变为一个“技术应用者”时，你和技术的关系就发生了变化，“技术能力”这个词的含义也就悄悄发生了转变。如果你没有意识到这一点，对技术的追求依然从“技术实现者”的角度出发，便会把轻重倒置。由于你的目标不允许、精力不允许，被这种既要做好管理又要做好技术的两难困境困扰必然会发生。
## 从技术实现者到技术应用者，具体发生了哪些转变呢？
对于技术实现者来说，程序设计能力、编码实现能力、技术攻坚能力和技术评估能力，都是需要具备的，主要关心的是“怎么把事情做出来”，属于“how”的范畴。
对于技术应用者来说，技术评估能力变得尤其重要，因为技术管理者主要关心的是“要不要做这件事”以及“这是件什么事儿”，属于“why”和“what”的范畴，是要在综合评估之后，做出决策和判断的。所以，很多前辈都会告诉我们要保持“技术判断力”，而并没有要求我们保持编码能力，原因就在这里。
既然对于技术管理者来说，需要保持和精进的技术能力是技术判断力，那具体该如何保持技术判断力呢？
## 技术判断力
所有的判断，都需要先评估。所以技术判断力，其实就是指对技术的评估能力。你可能会说，技术评估能力还是挺虚的，具体都评估什么呢？
作为一个技术管理者，即技术应用者，技术评估的维度主要体现在以下三个方面。
### 第一个维度是技术项目结果评估
作为管理者，在决策要不要做一个事情的时候，需要回答清楚三个问题。
1．这究竟是件什么事情？
2．希望得到什么结果？
3．要从哪几个维度去衡量结果？从哪几个技术指标去验收成果？
只有这几个问题清楚了，才可以以终为始地去做出准确的判断和正确的决策。下面举几个例子。
你可能会因为提升服务稳定性，去完善服务架构。
也可能为了提升数据准确性，去改写数据采集程序。
还可能为了提升性能指标，去重构数据读写模块。
其中“完善服务架构”“改写数据采集程序”和“重构数据读写模块”是我们要做的事情，但是这是事情的内容，却不是事情的“究竟”。这三件事情的“究竟”其实是“提升服务稳定性”“提升数据准确性”和“提升性能指标”。显然，事情的内容是为事情的“究竟”服务的，而希望得到的结果，就是“稳定性”“准确性”和“性能”的提升。那么，该如何衡量它们有没有提升呢？要用什么技术指标来衡量呢？如果无法衡量和评判，那么又如何判断各项技术工作做得好或是不好呢？管理者可不能只是关注一个个项目的完成，而是要关注通过完成一个个项目达成了什么目的。
事关每项工作的效果和业绩，因此，管理者对于技术项目结果的评估能力最为关键。虽然结果验收都是放在项目完成后，但是在事先就要明确如何验收，这样才能让大家有的放矢，以终为始。
### 第二个维度是技术可行性评估
可行性有两层含义：一是“能不能做”，二是“值不值得”。
所谓“能不能做”，是指有没有能力做到。这是个能力问题。
所谓“值不值得”，是指能力允许，但是否有足够的收益值得做。这是个选择问题。
显然，“能不能做”和“值不值得”，是两码事。不懂技术的管理者一般问的都是“能不能做”，而有经验的技术管理者和资深工程师，考虑的是“值不值得”。
要评估“值不值得”，就得思考成本和收益。收益，往往是显而易见的；而成本，就有很多方面需要考虑了，这正是体现技术判断力的地方。
那么，通常的技术项目，都有哪些成本要考虑呢？
1．投入的资源成本
，通常指“人财物时”。这是几乎每位工程师和管理者都能考虑到的，即需要投入多少人、多长时间，甚至是多少资金和物资在该项目上，这项成本相对容易评估。
2．技术维护的成本
。由于我们考虑投入的时候，往往只考虑到项目发布，而发布后的维护成本很容易被忽略。所以，这是评估技术方案时要重点关注的。
具体，常见的技术维护成本有如下几个方面。
技术选型成本
。指在做技术选型的时候，选择不成熟的技术所带来的成本。越成熟的技术，其技术实现成本和人力成本都相对要低，但是并不是说，选择新技术就一定不划算，只是要考虑到成本和风险，才能做出合理决策。
技术升级成本
。这是指在评估技术方案的时候，其兼容性和扩展性水平带来的后期升级的难度和成本。
问题排查成本
。在做技术实现的时候，要特别关注后续的问题排查。好的技术实现，几分钟就可以排查出问题原因；而不好的技术实现，查一个问题可能需要花上几天时间，成本开销不可同日而语。
代码维护成本
。在编写代码的时候，要记得代码是要有可读性的。这体现在别人升级代码要花多长时间才能看明白，修改起来是否简单、安全。
考虑维护成本是技术管理者和架构师视野宽阔、能力成熟的体现。
3．机会成本
。这是技术管理者做决策时要意识到的。也就是，当你把人力、时间花在这件事上，同时就等于放弃了另外一件事，而没有做另外这件事将带来什么样的影响呢？就是你要考虑的机会成本，你可能会因为这个思考而调整技术方案的选择。
4．协作成本
。协作成本，即多人协作所增加的时间、精力和人力开销。一个方案的协作方越多，需要沟通协调的成本也就越高，可控度就越低。如果可能的话，尽量减少不同团队和人员之间的耦合，这样会大大降低协作成本。但这很考验管理者的功力。
### 第三个维度是技术风险评估
技术风险评估，也叫技术风险判断。也就是，有哪些技术风险需要未雨绸缪，该技术方案带来最大损失的可能性和边界是什么，以及在什么情形下会发生。
这项评估工作很考验技术管理者的技术经验和风险意识，经验越丰富，对风险的判断就越敏锐，所以主要是靠积累。值得一提的是，技术风险的评估需要借助全团队的技术力量来做出准确判断，并非只靠管理者一人的技术判断力。
前面，我们介绍了技术评估能力所需要关注的三个评估维度，对于一个技术方案或一项技术决策，如果你能从以上三个维度去评估，说明你拥有了很好的技术意识。同时，如果你能够很好地做出判断的话，你会发现，自己的技术能力并不会降低，还会持续扩展。
## 有哪些具体的做法可以帮助自己提升技术判断力呢？
判断力不是天生的，也不是一蹴而就的。新经理的技术判断力，基本都来自于之前技术上的实际操作，来自于自己的经验积累。而做管理之后，技术评估方面的要求更高了，研究技术的时间和精力却减少了，这该如何应对？
别忘了，从你带团队的那一天起，你就已经不是一个人在战斗。所以，你可以依靠团队和更广的人脉，去拓展技术视野和技术判断力。常见的几种方式如下。
### 建立技术学习机制
。盘点你负责的业务需要哪些方面的技术，成立一个或几个核心的技术小组，让团队对各个方向的技术保持敏感，要求小组定期做交流和分享，这样你就可以保持技术的敏感度。
### 专项技术调研项目化
。如果某项技术对团队的业务有重要的价值，可以专门立项做技术调研，并要求项目负责人做调研汇报。
和技术专家交流
。越是厉害的技术人，越能深入浅出地把技术讲明白，所以针对某项技术找专家取经，也是学习的好途径。做管理后，虽然实际操刀的时间少了，但是你和技术专家的交流机会多了，一方面因为你有更大的影响力了，另一方面，你和大牛有了共同的诉求，就是把技术“变现”，让技术产生价值。
### 听取工作汇报
。因为你带的是技术团队，大部分工作都和技术相关，在读员工的周报、季度汇报时，相互探讨，也是一种切磋和学习。
总之，技术管理者的技术判断力的提升和保持，主要看能从周围人的身上汲取到多少信息和知识，而不再只是靠自学。
归根结底，从技术实现者到技术应用者的转变，不断提升的是技术的应用能力，而技术实现能力由于投入的时间和精力越来越少，的确会逐渐减弱。如果说带团队做项目就像组装一台计算机的话，你会越来越清楚如何把各个组件有效地集成起来，但团队中总会有人比你更懂每一个电子元器件的内部逻辑和性能参数。既然你选择了做更大的事情，就不得不适当放弃一些细节，放弃一些技术实现能力，不断提升你的技术判断力，从而让团队行进在正确的方向上。
## 管理者是不是必须技术最强
最后补充说明一种情况，有的技术管理者忧虑技术实现能力的丧失，主要是担心自己一旦不是“团队里技术最强的那个人”，会让团队成员不服气，甚至看不起。对此，我想说以下三点。
1．管理者的“技术最强”不体现在技术的专业精深和编码熟练度上，而是体现在能否带着团队高效地交付出高质量的产品和服务上。具体来说就是对三个评估维度的判断力：结果评估、可行性评估和风险评估。
2．管理者不能依靠专业上的“技术最强”来让员工服气。你确定要做管理的话，就得明白一件事情，团队里比你专业技术更强的人越来越多，是一种必然，而且，这是一个良好的现象。如果你做了多年管理，依然是团队里技术最强的那个人，那么这个团队的技术能力得多糟糕，你的管理工作得多么不到位。
3．技术强只是让员工服气的方式之一，却不唯一，管理者让员工“服气”的方式还有很多。想让员工服气，其实就是管理者对员工有良好的影响力。带着员工取得良好的业绩，获得良好的回报，以及支持和帮助员工成长，都可以让员工认可你的价值。
参考文章：https://blog.csdn.net/epubit17/article/details/93170068
