技术管理:技术管理人员的多维能力和成长路径
这篇文章我读了后,有种“读君一篇文,胜读十年书”的感觉。有很多启发,由衷的感谢作者!我把它放在这里,希望也能给其他人带来思考与启发。
本文原作者陈旭,原文链接:http://developer.51cto.com/art/201603/507074.htm
注:原文图片缺失, 我给找回来了。
隔一段时间再看,会有不同感悟,比如去熟悉市场,销售,了解偏商业部分的内容等,T 型发展路线,这些都是 T 的那一长横,也就是我们常说的广度宽度
以下是原文:
在多年的‘技术管理’工作中不断地遇到很多已经或者即将转型为‘技术管理者’的同事,他们都表达了一些类似的困惑:如何成功转型?我不想丢掉技术,如何在不丢掉技术的同时还能提升管理能力!以下是我自己在这个过程中经历困惑和挣扎后的一些个人想法,分享给大家:
一. 什么是‘技术思维’ ?
技术思维的‘成长路径’:
1.基本编程:自己懂一点技术,能够编码实现一些具体的业务功能;
2.封装能力:具备一些基础功能的代码封装能力;
3.代码质量: 开始关注更多代码相关的范畴,性能/健壮性、可阅读/可维护性、注释/文档、测试意识和能力;
4.工具能力:关注工作效率的提升 , 编辑工具、搜索工具、测试工具、脚本、插件 , 甚至自己动手写工具 ;
5.抽象思维:
- 具备整体方案设计能力;
- 逐步培养出抽象思维能力;
- 开始具备对设计模式的理解及使用;
6.前沿技术:
- 逐步具备更广的技术视野,做前端的开始关注大前端、NODEJS等;
- 虚拟化、存储、大数据相关技术;
- 特定领域更深入的技术;
7.架构思维:
- 开始关注跨系统的整体高可用;
- 关注跨系统之间的各种问题: 服务化、服务治理等;
- 关注性能、安全性、可扩展性、开发效率 , 并注重几者之间的平衡;
- 关注基础系统、自动化系统;
- 开始关注云计算或具备更宽广的技术视野;
图1:技术思维的大致‘成长路径’
毋庸置疑,对于一名‘技术管理者’来讲,其当然应该具备一定的技术思维和技术能力。这是“技术管理者”的立足之本。但是,只具备“技术思维”的管理者,一般来讲喜欢随时冲在技术的第一线,对于技术还处在满足自己的 ‘技术成就’ 的心态阶段;
二. 什么是‘产品思维’ ?
产品思维是从‘产品功能’ 的角度去看问题,站在最终‘使用者’的角度去思考。
产品经理一般要求具备一些产品设计方面的专业能力,并且具备较强的沟通表达能力。
对于互联网项目来讲,由于互联网产品本身就具有较强的传播性和连接用户的能力。因此产品思维显得尤其重要!
技术管理者应该具备什么样的‘产品能力’:
- 具备一定的产品交互体验设计能力;
- 具备一定的对于 ‘色彩、线条’的运用把握和‘审美'能力;
- 一定程度的原型设计和产品设计的能力;
- 具备较强的产品沟通能力以及快速理解产品设计逻辑和意图的能力;
- 快速的理解和学习新的业务逻辑比 ‘长期熟知某项具体的业务’ 更重要;
- 对于业界前沿的产品方向和趋势具备较强的敏感度和学习意识;
好的‘技术管理者’ 应该具备一定的产品思维和产品能力。而不仅仅是把自己放在 ‘用技术来实现产品’ 的被动接受的角度。好的‘技术管理者’ 应该理解 ‘永远没有一成不变’的产品功能,技术架构和代码都是为了产品功能的修改而存在。而我们要考虑的是:如何用更加灵活的代码设计,让其具备更好的可扩展性。提前预留接口,让系统具备一定程度的功能 ‘预见性’。以便在需求和产品功能更改的时候,更好的掌控修改工作量、掌控修改风险。
三. 什么是‘管理思维’ ?
A.管理思维的‘成长路径’:
1.基本管理:是指管理者具备一些基本的以 ‘计划、监督、检查’ 为手段来进行管理的能力;
2.沟通管理:是指管理者开始有意识的提升自己的沟通方面的能力。
- 对内/对外/同级都表现出良好的沟通能力;
- 注重邮件沟通、汇报方面主动采用良好妥当的形式等;
- 含帮助自己的下级提高沟通能力;
3.项目管理:是指管理者开始有意识的提升自己对整体项目上的把控能力,含:
- 对项目管理三要素‘质量/进度/成本’的均衡达成的能力;
- 为项目制定适当的汇报机制、规范;
- 按承诺日期上线 ;
4.团队管理:是指对于人和团队的‘管理’,包含管理者基于对于团队中各个成员的不同特点的了解对其进行个性化引导和培养的能力。同时包含管理者凝聚一个团队,以及在需要时能够快速的形成和壮大一个团队的能力。一个团队管理的好坏,也会有如下一些方面的指标能够看出一些端倪:
- 团队活跃度:是否保持一些不同的团建形式,并能容纳一些不同的想法;
- 团队凝聚力: 团队中是否有一些非‘既得利益’的成员也愿意为团队的发展主动建言献策、主动承担;
- 团队稳定性: 是指团队员工的整体稳定性、离职率高低;
5.规范化、流程化:管理者在团队成长到‘适当’的阶段时,需要有意识的制定一些流程化、规范化制度。以便能够系统性的规避一些‘常见问题’。但是,‘流程规范’ 常常和 ‘效率’ 形成矛盾。因此管理者需要的是提出和团队当前阶段相‘适应的’的流程/规范/制度,并在团队的规模和阶段变化时不断的去作出调整和修正。而不是一味的去强调‘制度规范’,对于这个 ‘度’ 的把握才是对于管理者最大的挑战;
图2:管理思维的大致‘成长路径’
B.‘管理思维’ 是什么,不是什么?
-
管理思维是:我不一定亲自出技术方案、写代码。但是对这件事情从技术层面做得好与不好有一些超越具体的技术和框架之上的标准和原则;
-
尽量鼓励和引导 ‘好的方案’ 由团队中的技术人员口里说出来,而不是由技术管理者亲自定方案,即便在心里已经有结论。虽然技术方案不一定是由我全部定出, 但是技术的原则和边界,始终在我的掌控范围之内;
-
对于 ‘技术’ 永远保持着一定的 ‘敏感度’ 和不断的了解和学习;
-
对于如何调动技术员工的积极性、提升技术氛围有自己的见解和方法;
-
能够为团队指明技术的大方向,并前瞻性的作出一些 ‘技术储备’;
-
对于责任的拆分和分担、对于提高下级的执行力有自己的方法;
-
坚信只要队伍带得好,永远有比自己在某个具体‘技术上’更专业的人不断的涌现出来;
-
不满足于带领团队解决具体的技术问题,而是满足于为团队建立起 “制度化”、“常态化”地规避某些技术风险、解决某些技术问题的能力;
-
注重提升团队直接汇报对象管理能力方面的成长,注重在适当的阶段提升团队的流程化、规范化、制度化。因为团队这些方面的不足很多时候都是重复犯一些 ‘技术问题’ 的原因所在;
-
管理思维不是一味的‘埋头干活’,而是应当具备一些 ‘抬头看天、抬头问路’ 的意识;
四. 什么是多维度能力?
如果将一名 ‘技术管理者’ 的能力比喻为如下的立方体的体积,其 ‘能力公式’ 如下:
整体能力 = 技术能力 * 产品能力 * 管理能力
则任何一个维度能力的短板都将严重影响其整体能量水平,如下图所示
图3:技术管理者的多维度能力
-
纯技术思维的人:很容易把自己封闭在一个纯粹的技术世界里,在那里只有自己研究的技术。容易固执的认为技术是万能的,技术可以解决一切问题。容易过分的‘高估’技术,人很单纯也很固执。无法很好的和不同类型的人达成真正的合作,其带领的团队也很难壮大。这样的人适合专注于搞技术,并不适合将其放在团队leader的位置;
-
纯产品思维的人:善于沟通、思维发散,初次交往时很会抓住别人的注意力。如果由其掌舵大型的技术团队,长时间后会发现他们容易出现思路逻辑不清,缺乏恒久的坚持和方向感,也容易出现以用户需求之名把团队带进坑里;
-
纯管理思维的人:如果没有技术或者产品或者其他某一方面能力的补足,在以技术/产品为驱动的团队很难建立起威信。从而很好的带领一个技术团队;
作为一个技术团队的驾驭者,技术管理者需要在头脑中形成技术思维、产品思维、管理思维,等等“多维度”的能力和思考方式。如果过分缺少某一方面的能力及思维维度,就如同生活中俗语所说的“少根筋”。从根本上来说,也会对团队带来很大的制约。技术管理者的思考维度越少,其对某些专项人才的理解能力可能会出现偏差。团队整体就有可能形成这方面的‘短板’, 要么是技术短板、要么是产品短板、要么是项目管理/按时按质上线的短板、要么就是团队成长方面的短板。这样的技术管理者基本上很难带出“特别优秀的”团队。由于缺乏太多其他思考维度,他们无法正确理解和驾驭整个团队的运作,难以接收和正确处理来自各个方向的外部团队反馈的各类信息,团队进步缓慢乏力。很容易被别的竞争团队实施 ‘降维打击’。在现实中不乏这样的团队和管理者;
另外,大部分IT从业人员有可能在一定的年龄、经验阶段在技术、产品、管理等单项能力上出现‘成长瓶颈’,表现迷茫。如果你是一名专注写了5、6年程序的程序员,可以根据兴趣有意识的去尝试在‘产品设计’或者‘管理能力’上进行提升。这种提升不一定非要转型为'产品经理'或者'管理者'才能启动,平时做程序开发时多主动参与需求分析和产品设计、多画画原型也能提升自己的‘产品能力’。多尝试做一些技术团队跟业务团队的沟通、推广工作,或者在团队中主动担负起‘带新人’也是管理能力某一方面的成长。
如果将一个人的整体能力看做 X * Y * Z,如果X的成长已经达到阶段性的'极限',则Y和Z的增长也不失为提升整体能力的手段!
五. ‘七项核心能力’ 和‘成长路径’
下图是本人在某大型互联网公司时作为一名“技术管理者”为团队总结的“技术管理者” 应该具备的 ‘七项核心能力’ 和‘成长路径’:
图4:技术管理者的‘七项核心能力’和‘成长路径’
以上‘七项’也可以理解为‘技术管理者’应该具备的七个维度的能力。
虽然,包括我自己在内的很多人都无法同时让这七项能力都非常优秀,也不是每一个技术团队都有机会去同时发展这些能力。但是,我还是固执的将其作为自己在 ‘技术管理道路上’ 的成长目标。另外,能力维度和每一维度的能力的高低是有区别的。对于管理者来说,多一个维度少一个维度是‘质’的区别。同一个维度,能力高下只是‘量’的区别。对于某些阶段的团队,维度的多少甚至比维度的深浅更加重要。任何一个团队一定是在 ‘多维空间’ 中去 ‘经营’ 出来的,竞争对手不会‘原谅’你在别的某一项能力维度上的完全缺失!
同样的道理,对于创业者一样的需要多维度思考能力。当然,对于‘创业者’来讲其还应该更多的具备‘商业思维’、‘财务知识’、‘拉投资的能力’等等。所以,如果创业者认知和能力“缺维”,即使是大公司出来的技术大牛,其独立创业或者作为 ‘合伙人’ 创业的表现可能还不如那些当前各项能力一般但能力比较均衡的 ‘新人’。
以上想法,与诸君共勉!
本文原作者陈旭,原文链接:http://developer.51cto.com/art/201603/507074.htm
下一篇: 从技术专家到技术管理者,我对管理的思考
推荐阅读
-
技术管理:技术管理人员的多维能力和成长路径
-
技术管理:技术管理人员的多维能力和成长路径
-
像首席技术官一样思考:如何高效管理 30 人的研发团队?-管理越多越轻松。好的研发团队,应该是上拨下用,即下级对上级的向上管理;而不是反过来,总是向下管理,甚至是 CTO 做经理的事,经理做工程师的事,工程师最终会被当成实习生。如果是这样,就会越管越累,不仅团队无法成长,而且团队整天很忙还效率低下,问题一大堆。 有这样一个小故事:一位高级经理下班后帮忙倒垃圾,结果被老板训斥了一顿。这就好比首席技术官做了实习生自己该做的事。事情本身没有对错之分,只是从不同的角度有不同的理解。 古人云:"用人不疑,疑人不用"。在面对自己的研发团队时,应该相信他们能做好,授权一线开发人员充分发挥专业特长,不要限制他们的工作。但在相信他们的同时,也要进行二次确认,始终秉持 "我相信,但我要确认 "的原则和严谨的精神。因为每个人都会犯错和疏忽,通过发挥团队的智慧,团队犯错的机会就会大大减少。比如回归测试、代码审查、开发演示、变更审批等等。 如前所述,每个人都难免会犯错。但作为管理者,你所设计和商定的流程不能出错。管理者的每一个决定和沟通都应该经过深思熟虑。就像红绿灯的交通设计,某辆车不小心闯红灯可能会扣分,但红绿灯的设计一定要正确、人性化、统一。再比如,开发人员可能会因为疏忽大意写出 bug,但研发流程的设计和上线流程的发布不能有任何差错。因此,流程体系的设计,一方面要结合当前团队规模、业务特点和需要重点解决的问题来设计,另一方面也要在人员防错、效率提升、发挥团队集体智慧等维度进行综合考量。应该站在更高更抽象的角度去思考,不断思考一个倍受欢迎的园区应该如何设计,思考一个灵动、经典、永恒的建筑应该遵循怎样的模式,思考一个成功、优秀、卓越的研发团队应该需要怎样的流程和制度。 最后,反馈很重要。向上汇报很重要,向下反馈也很重要。能够保持顺畅的双向反馈和闭环管理,对研发团队的协作和沟通有着非常明显的积极作用。在向上汇报方面,要培养团队在正式汇报、会议汇报、私下沟通、书面总结、非正式场合等方面的沟通能力,提醒下属报喜也要报忧。凡事先记录,再跟进,最后反馈。反馈很重要,主动汇报更难得。 另一方面,同时也不要忽视向下反馈。好的爱,是双向的。团队也是如此,没有严格的上下级之分,只是分工和角色不同而已。作为管理者,不必总保持一种 "神秘感",让人 "捉摸不透 "才是牛。当团队做得好或有人做得好时,要记得在公开或私下场合给予肯定和赞许。业务有增长、业绩有提升时,别忘了给团队一些鼓励,或者安排一次下午茶或聚餐。在例会或正式会议上,也可以同步向大家传达一些重要信息和高层指示。"欲速则不达,欲远则同行"。 当向上汇报、向下反馈的沟通闭环形成后,同时结合前面研发过程的管理闭环,双管齐下,就能形成良性循环。如此反复,持之以恒,优秀卓越的研发团队,必将呈现。 能力、产出和效率 接下来,继续重复关于能力、产出和效率的话题。 站在不同的角色,以及一个企业经营、生存和发展所需要的基础上,我把研发生产力分为三个层次,分别是:一线员工关心的研发能力、管理层关心的软件产出和操作人员关心的企业生产效率。简单概括就是:既要把工作做好,又要能出成果,还要能帮企业赚钱。
-
InfoQ,谈谈百度开源高性能搜索引擎 Puck-Ben:Puck是团队长期研究和努力的成果,作为Puck的负责人,我对这个项目有着深深的热爱和执着,对我个人而言,它不仅仅是一个搜索引擎,而是代表着团队心血和智慧的结晶,它是我们对技术的追求,对创新的执着,也是我们对未来的期望和愿景,Puck的每一次升级和优化都记录着我们的成长和进步。这是我们对技术的追求,对创新的执着,也是我们对未来的期望和憧憬,帕克的每一次升级和优化都记录着我们的成长和进步。 我对帕克的未来充满期待。首先,我希望 Puck 能够在开发者社区得到广泛应用,同时得到社区的反馈,不断优化和改进。我期待看到更多的人参与到Puck的开发和使用中来,通过大家的共同努力,让Puck成为人工智能领域有影响力的工具。其次,我希望Puck能够不断创新和优化,保持技术领先地位,不仅要适应当前的技术需求,更要预测和引领未来的技术趋势。最后,我希望Puck能在更多的实际应用中实现自身价值,为人工智能在各行各业的应用提供有力支撑,推动科技发展。 访谈嘉宾简介: Ben,百度搜索内容技术部主任架构师,负责多模态内容理解、超大规模内容关系计算、内容处理与生成、模型优化等方向。 欢迎加入朋克技术交流群:913964818 本部门招聘ANN搜索工程师、模型优化工程师、分布式计算研发工程师等多个职位。欢迎勇于接受挑战、具有优秀分析和解决问题能力的人才加入我们。 招聘邮箱:tianyakun@baidu.com --END-- 推荐阅读
-
刘韧工作手册(2023年版)-17 共同学习,共同进步,搭建共识。一起工作的基础,是对彼此能力的认可,继续一起工作的基础,是能力的共同提高。共同进步的基础,就是共同学习,共同学习的基础,是看过同样的书。 年轻时,男女谈恋爱,双方世界观趋同,差距不大。后来,世界观逐渐拉大,对话成了鸡同鸭讲,我讲,你听不懂。你讲,我不感兴趣,甚至闹离婚,双方自然而然走不下去了。工作也一样,同事间如果差距越来越大,最终,无法一起工作。 我为了和别人搭建共识,会处心积虑向其推荐读书。听什么歌,观什么电影,看什么书,能在一定程度了解一个人。 有人说,金庸的书是文学。我说,那是娱乐。文学是“真、善、美”,首先是要“真”,就是情感真实。而在金庸的小说里,类似“九阴真经”、“葵花宝典”的秘籍是假的,小说里的人物寻得秘籍,一夜之间就能武功猛增……这样的情节,在现实中可能吗?生活中,漂亮的富家女黄蓉会爱上傻小子郭靖吗?金庸看多了,人会追求走捷径,工作生活“走捷径”会害死自己。 18 礼物,是人际交往中的情感润滑剂。互相送礼物,增进感情。不知道买什么,就买吃的。 英国人做客,会送主人红酒、鲜花和小卡片,回家后,会写感谢信。在新加坡,朋友们来家,常带些做好的熟食,大家一起吃。 2000年,我听说谷歌在办公室给员工备吃的。当时不太理解,后来才知道,“在一起吃”这个行为,有助于消除紧张和敌意,人更容易感到温暖和轻松,更愿意敞开心扉,是社交中增进感情的好方式之一。脸书新加坡总部,午餐,公司会请高级厨师做六种风格的菜,每一道菜都做的极好,甚至比五星级酒店的饭菜都好吃。他们的员工告诉我,根本不想回家,就想在公司吃饭。 19 坦诚,不装懂,打破沙锅问到底。想当然半天,不如简单试一下。要学会积攒各种低成本测试方法,并勤快地去试。超大额跨国汇款,先汇1元,测试路径是否畅通。没有招,没有策略库,一筹莫展。 有句古话,叫“以其昏昏,使人昭昭”。很多人对“学而优则仕”这句话的理解,是典型的“以其昏昏,使人昭昭”。这句话常被人解释为“学习好了就去当官”,若照此解释,下一句“仕而优则学”只能解释为“当官当好了就去学习”!这显然说不通。这里的“优”,不是“优秀”,而是“空闲”的意思。很多人不清楚,却到处教人解释这句话。 《水浒传》是中国版的黑帮小说,讲的是厚黑学,没有道德底线。梁山人为了拉扈三娘入伙,杀光了她全家,把原本是千金小姐,花容月貌的扈三娘指婚丑陋的王英。直到今天,《水浒传》常被解释为“侠义”。 在群里,遇到信口雌黄国学的人,我会问他们,论语中,第一句话“学而时习之不亦说乎”中的“习”是什么意思?很多人解释为“复习”。其实,繁体字中,“习”的写法是“習”,下面一个“白”,上面一个“羽”,指的是“雏鸟学飞”。意思是,雏鸟利用老鸟教的技巧,终于飞起来了。因此,“习”的本意是指老师手把手把心得教给你,让你学会了,有了收获和进步,绝不是指反复“复习”和“练习”的意思。 维特根斯坦说:“凡是可说的就要说清楚,凡是不可说的就该保持沉默。”别不懂装懂。 20 善待帮助你的人。一个人能否成功,要看有没有人愿意帮你。有多大成功,要看有多少人愿意帮你。 别人发现你出错了,提醒你,这些都是你所能得到的“举手之劳”的帮助,你知道了,能改掉,你容易成长。 如何做一个有很多人愿意帮你的人呢? 首先,滴水之恩,当涌泉相报。每次收到礼物,我一定会表示感谢。 其次,得到帮助,一定要反馈。很多帮助不一定非得要你用物质来交换,可能仅仅是你要领情。我会记录所有受到的帮助,并广而告之。我写书时,会把帮助我的人都列举出来,这样做成本不高,但被提到的人会感动。 你们可以回忆一下,有多少人帮过你?如果脱口说出的人数越多,说明你离成功越近。要是发现世界上,愿意帮你的人只有父母,那就要反思了。(完) 刘韧商业写作通识