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