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