技术管理者的多维度能力及成长路径
在多年的‘技术管理’工作中不断地遇到很多已经或者即将转型为‘技术管理者’的同事，他们都表达了一些类似的困惑：如何成功转型?我不想丢掉技术,如何在不丢掉技术的同时还能提升管理能力!以下是我自己在这个过程中经历困惑和挣扎后的一些个人想法，分享给大家：
一.什么是‘技术思维’ ?
技术思维的‘成长路径’：
1.基本编程：自己懂一点技术，能够编码实现一些具体的业务功能;
2.封装能力：具备一些基础功能的代码封装能力;
3.代码质量: 开始关注更多代码相关的范畴，性能/健壮性、可阅读/可维护性、注释/文档、测试意识和能力;
4.工具能力：关注工作效率的提升 , 编辑工具、搜索工具、测试工具、脚本、插件 , 甚至自己动手写工具 ;
- 5.抽象思维：
- 具备整体方案设计能力;
- 逐步培养出抽象思维能力;
- 开始具备对设计模式的理解及使用;
6.前沿技术：
- 逐步具备更广的技术视野,做前端的开始关注大前端、NODEJS等;
- 虚拟化、存储、大数据相关技术;
- 特定领域更深入的技术;
7.架构思维：
- 开始关注跨系统的整体高可用;
- 关注跨系统之间的各种问题: 服务化、服务治理等;
- 关注性能、安全性、可扩展性、开发效率 , 并注重几者之间的平衡;
- 关注基础系统、自动化系统;
- 开始关注云计算或具备更宽广的技术视野;
图1：技术思维的大致‘成长路径’
毋庸置疑，对于一名‘技术管理者’来讲，其当然应该具备一定的技术思维和技术能力。这是“技术管理者”的立足之本。但是，只具备“技术思维”的管理者，一般来讲喜欢随时冲在技术的第一线，对于技术还处在满足自己的 ‘技术成就’ 的心态阶段;
二.什么是‘产品思维’ ?
产品思维是从‘产品功能’ 的角度去看问题，站在最终‘使用者’的角度去思考。
产品经理一般要求具备一些产品设计方面的专业能力，并且具备较强的沟通表达能力。
对于互联网项目来讲，由于互联网产品本身就具有较强的传播性和连接用户的能力。因此产品思维显得尤其重要!
技术管理者应该具备什么样的‘产品能力’：
1.具备一定的产品交互体验设计能力;
2.具备一定的对于 ‘色彩、线条’的运用把握和‘审美'能力;
3.一定程度的原型设计和产品设计的能力;
4.具备较强的产品沟通能力以及快速理解产品设计逻辑和意图的能力;
5.快速的理解和学习新的业务逻辑比 ‘长期熟知某项具体的业务’ 更重要;
6.对于业界前沿的产品方向和趋势具备较强的敏感度和学习意识;
好的‘技术管理者’ 应该具备一定的产品思维和产品能力。而不仅仅是把自己放在 ‘用技术来实现产品’ 的被动接受的角度。好的‘技术管理者’ 应该理解 ‘永远没有一成不变’的产品功能，技术架构和代码都是为了产品功能的修改而存在。而我们要考虑的是：如何用更加灵活的代码设计，让其具备更好的可扩展性。提前预留接口，让系统具备一定程度的功能 ‘预见性’。以便在需求和产品功能更改的时候，更好的掌控修改工作量、掌控修改风险。
三.什么是‘管理思维’ ?
A.管理思维的‘成长路径’：
1.基本管理：是指管理者具备一些基本的以 ‘计划、监督、检查’ 为手段来进行管理的能力;
2.沟通管理：是指管理者开始有意识的提升自己的沟通方面的能力。
- 对内/对外/同级都表现出良好的沟通能力;
- 注重邮件沟通、汇报方面主动采用良好妥当的形式等;
- 含帮助自己的下级提高沟通能力;
3.项目管理：是指管理者开始有意识的提升自己对整体项目上的把控能力，含：
- 对项目管理三要素‘质量/进度/成本’的均衡达成的能力;
- 为项目制定适当的汇报机制、规范;
- 按承诺日期上线 ;
4.团队管理：是指对于人和团队的‘管理’，包含管理者基于对于团队中各个成员的不同特点的了解对其进行个性化引导和培养的能力。同时包含管理者凝聚一个团队，以及在需要时能够快速的形成和壮大一个团队的能力。一个团队管理的好坏，也会有如下一些方面的指标能够看出一些端倪：
- 团队活跃度：是否保持一些不同的团建形式，并能容纳一些不同的想法;
- 团队凝聚力: 团队中是否有一些非‘既得利益’的成员也愿意为团队的发展主动建言献策、主动承担;
- 团队稳定性: 是指团队员工的整体稳定性、离职率高低;
5.规范化、流程化：管理者在团队成长到‘适当’的阶段时，需要有意识的制定一些流程化、规范化制度。以便能够系统性的规避一些‘常见问题’。但是，‘流程规范’ 常常和 ‘效率’ 形成矛盾。因此管理者需要的是提出和团队当前阶段相‘适应的’的流程/规范/制度，并在团队的规模和阶段变化时不断的去作出调整和修正。而不是一味的去强调‘制度规范’，对于这个 ‘度’ 的把握才是对于管理者最大的挑战;
图2：管理思维的大致‘成长路径’
B.‘管理思维’ 是什么，不是什么?
1.管理思维是：我不一定亲自出技术方案、写代码。但是对这件事情从技术层面做得好与不好有一些超越具体的技术和框架之上的标准和原则;
2.尽量鼓励和引导 ‘好的方案’ 由团队中的技术人员口里说出来，而不是由技术管理者亲自定方案，即便在心里已经有结论。虽然技术方案不一定是由我全部定出， 但是技术的原则和边界，始终在我的掌控范围之内;
3.对于 ‘技术’ 永远保持着一定的 ‘敏感度’ 和不断的了解和学习;
4.对于如何调动技术员工的积极性、提升技术氛围有自己的见解和方法;
5.能够为团队指明技术的大方向，并前瞻性的作出一些 ‘技术储备’;
6.对于责任的拆分和分担、对于提高下级的执行力有自己的方法;
7.坚信只要队伍带得好，永远有比自己在某个具体‘技术上’更专业的人不断的涌现出来;
8. 不满足于带领团队解决具体的技术问题，而是满足于为团队建立起 “制度化”、“常态化”地规避某些技术风险、解决某些技术问题的能力;
9. 注重提升团队直接汇报对象管理能力方面的成长，注重在适当的阶段提升团队的流程化、规范化、制度化。因为团队这些方面的不足很多时候都是重复犯一些 ‘技术问题’ 的原因所在;
10.管理思维不是一味的‘埋头干活’，而是应当具备一些 ‘抬头看天、抬头问路’ 的意识;
四. 什么是多维度能力?
如果将一名 ‘技术管理者’ 的能力比喻为如下的立方体的体积，其 ‘能力公式’ 如下：整体能力 = 技术能力 * 产品能力 * 管理能力
则任何一个维度能力的短板都将严重影响其整体能量水平，如下图所示
图3：技术管理者的多维度能力
1.纯技术思维的人：很容易把自己封闭在一个纯粹的技术世界里，在那里只有自己研究的技术。容易固执的认为技术是万能的，技术可以解决一切问题。容易过分的‘高估’技术，人很单纯也很固执。无法很好的和不同类型的人达成真正的合作，其带领的团队也很难壮大。这样的人适合专注于搞技术，并不适合将其放在团队leader的位置;
2.纯产品思维的人：善于沟通、思维发散，初次交往时很会抓住别人的注意力。如果由其掌舵大型的技术团队，长时间后会发现他们容易出现思路逻辑不清，缺乏恒久的坚持和方向感，也容易出现以用户需求之名把团队带进坑里;
3.纯管理思维的人：如果没有技术或者产品或者其他某一方面能力的补足，在以技术/产品为驱动的团队很难建立起威信。从而很好的带领一个技术团队;
作为一个技术团队的驾驭者，技术管理者需要在头脑中形成技术思维、产品思维、管理思维，等等“多维度”的能力和思考方式。如果过分缺少某一方面的能力及思维维度，就如同生活中俗语所说的“少根筋”。从根本上来说，也会对团队带来很大的制约。技术管理者的思考维度越少，其对某些专项人才的理解能力可能会出现偏差。团队整体就有可能形成这方面的‘短板’, 要么是技术短板、要么是产品短板、要么是项目管理/按时按质上线的短板、要么就是团队成长方面的短板。这样的技术管理者基本上很难带出“特别优秀的”团队。由于缺乏太多其他思考维度，他们无法正确理解和驾驭整个团队的运作，难以接收和正确处理来自各个方向的外部团队反馈的各类信息，团队进步缓慢乏力。很容易被别的竞争团队实施 ‘降维打击’。在现实中不乏这样的团队和管理者;
另外，大部分IT从业人员有可能在一定的年龄、经验阶段在技术、产品、管理等单项能力上出现‘成长瓶颈’，表现迷茫。如果你是一名专注写了5、6年程序的程序员，可以根据兴趣有意识的去尝试在‘产品设计’或者‘管理能力’上进行提升。这种提升不一定非要转型为'产品经理'或者'管理者'才能启动，平时做程序开发时多主动参与需求分析和产品设计、多画画原型也能提升自己的‘产品能力’。多尝试做一些技术团队跟业务团队的沟通、推广工作，或者在团队中主动担负起‘带新人’也是管理能力某一方面的成长。
如果将一个人的整体能力看做 X * Y * Z，如果X的成长已经达到阶段性的'极限'，则Y和Z的增长也不失为提升整体能力的手段!
五. ‘七项核心能力’ 和‘成长路径’
下图是本人在某大型互联网公司时作为一名“技术管理者”为团队总结的“技术管理者” 应该具备的 ‘七项核心能力’ 和‘成长路径’：
图4：技术管理者的‘七项核心能力’和‘成长路径’
以上‘七项’也可以理解为‘技术管理者’应该具备的七个维度的能力。
虽然，包括我自己在内的很多人都无法同时让这七项能力都非常优秀，也不是每一个技术团队都有机会去同时发展这些能力。但是，我还是固执的将其作为自己在 ‘技术管理道路上’ 的成长目标。另外，能力维度和每一维度的能力的高低是有区别的。对于管理者来说，多一个维度少一个维度是‘质’的区别。同一个维度，能力高下只是‘量’的区别。对于某些阶段的团队，维度的多少甚至比维度的深浅更加重要。任何一个团队一定是在 ‘多维空间’ 中去 ‘经营’ 出来的，竞争对手不会‘原谅’你在别的某一项能力维度上的完全缺失!