您当前的位置:首页 > 充电吧 > 猎聘集

当研发团队来了不懂技术的领导……

时间:2017-11-10 来源: 作者: 标签:研发团队   技术   领导   

管理学大师 Peter Drucker 有一句名言:

管理人员是与人打交道,其任务是使员工能够协同工作、扬长避短。

正如 Drucker 所说,作为管理者,我们的目标很清晰了。既然需要帮助员工实现以上目标,那么管理人员至少要能够明白员工的工作流程、内容,清晰地知道当前工作方式和模式下存在的优缺点,如果管理人员自身就是这一领域的大牛,那么他既能理解问题,也能解决问题,就好比能够做个既能干又通情达理的好婆婆。那么,如果实际情况超出了我们的设想?突然之间从其他部门调过来一位领导,而这位领导又完全不懂技术,那情况会怎么样呢?(事实上,这种情况并不少见)我们逐一讨论。

研发团队领导职责

 

前几天和朋友吃饭,他是 BAT 出身,习惯了在技术大牛领导带领下干活,而后工作换到了现在的大公司,刚开始境况还是相同,忽然有一天换了基本不懂技术的领导来带他,噩梦开始了:交互过程中频频出现不在一个频道的情况,而对于技术方案的差异看待,成为了直接的导火索,导致他们之间发生了激烈的争执,进而导致他吃到了两次季度不佳评价。他一度想主动离开,毕竟技术还在,不愁没工作,但转念一想,这种情况可能在哪都会出现,即便回到过去的环境,也不能保证一辈子不碰上,既然现在碰到了,就想办法应对,最不济就当交学费吧。

换位思考后,他开始不断自我调整,摆正心态,积极主动地与那位领导沟通,了解他的困难。现在,他俩好得和亲兄弟一样,工作上他成了领导的技术顾问,领导也把他当成自己的左膀右臂。但是,说实在的又有几个员工愿意这么做呢?很多人是不愿意这么做的,他们会认为这是委曲求全,此外,这种情况下也确实容易让员工出现“天花板现象”,毕竟那位领导可能不太会有上升空间了。

进一步扩展 Drucker 的想法,我认为,作为研发团队领导,我们的主要职责是组织整个团队的工作,合理安排、高效协调。同时,当他们出现任何问题时,无论是技术问题,还是管理问题,亦或者个人问题,我们都要能够给予有利支撑,让他们感觉背后有人站着,而不是背后就是悬崖,这样才能做到高质量、高效率地输出成果物,无论是技术上的,还是产品上都能输出优质的成果物。综合这些要求,坦白地说,我认为不懂技术的人如果做了研发团队的领导,很容易出现严重的问题。

理解研发团队领导工作

 

研发团队领导实质上在做的是技术管理工作。技术管理是一种组织团队一起进行研发的工作,它是一门细分工种,随着社会的进步、人类思维的开放、经济水平的提升,被管理者(工程师们)逐渐从单纯为了解决物质矛盾转化为追求工作的归属感、参与感、技术尊重感,他们逐渐地对跟着谁一起工作、采用哪种工作方式、解决了什么样的技术问题、做出了什么样的产品感兴趣,而不是仅仅满足于金钱多少。同时,被管理者之间还存在紧密的社交媒体关联关系,能够保持沟通,共享着对于在该公司 / 组织工作的感受,共享着对于管理者的能力、品德认识,这也是一种共享过程。我们每位技术团队管理者,也正在像书一样被摆放在被管理者面前,如果别人懒得翻你,就证明你不能给予他们指导,他们不会有归属感,最终都会匆匆离职。

可能会出现的问题

 

会出现哪些问题呢?比如研发团队会举办各种技术会议,产品需求、总体设计评审会议、调研项目技术选型会议、预研项目预研报告评审会议等等,其实也基本上是一个研发团队的大部分工作内容。这样问题就来了,如果他不懂技术,你觉得我们在召开会议的时候,这位领导到底需不需要参加?如果是一位技术专家出生的人,问题就变得简单了,毫无疑问他需要参加,因为很多技术设计环节需要他把关或批准,一些技术难题他可以牵头解决。

但如果情况相反,这时候就会出现麻烦。他参不参加,都会引起麻烦:如果参加,可能给不出任何意见,说不定还乱指挥,如果不参加,时间长了他自己会感觉被架空,说不定引起团队内部的大清洗。这是单纯从日常的技术工作上去考虑问题,我们每天需要应对的事情,也正是整个团队需要应对的,大家得在一个频道上,不然沟通起来确实很麻烦,增加沟通成本的同时也在消耗内部资源。

说完了技术日常工作,再来看研发过程管理。对于整个研发过程的管理,不懂技术的人很容易完全从产品角度出发,忽略研发团队面临的困难和风险,忽略技术人员对于技术的憧憬,造成团队超负荷工作的情况、技术团队缺少技术愿景等情况发生。举个例子,遇到业务方提出的需求完成时间点过于苛刻的情况(其实这是一个压力传导问题,业务方收到了客户的压力,本来可以通过向客户解释等方式减少研发的压力和风险,但是选择直接施压研发)。

这时候,你这位不懂技术的团队老大可能会说,没关系,我们一开始并不需要一个完美的系统,你先上了再说,先解业务的渴(怎么解渴其实他也说不清楚),我们后面有时间再重构再完善(当然有的技术人员也会用“架构和设计是逐步演化出来的”这句话来证明“故障驱动”开发是值得的),这样的想法本质上是错误的。

其实我们不应该把责任一股脑推卸到产品思维上去,我认为一名合格的研发团队领导,他本身就必须具备一定的产品思维,这样才能更好地让技术为产品服务,做好技术的落地工作。我们需要担心的也是很多时候容易出现的情况,这位领导的产品思维也是半桶水,这时候他口中的用户需求,是否准确我们得打问号,是否能够与研发体系融合在一起就更需要质疑,也许正是因为他本人的能力问题,造成产品牵着技术往前赶,而不是有条不紊地落地。

不懂技术的研发领导,虽然他不懂技术,但是他肯定懂别的,例如产品、运营等等。去年有一次和一位通信运营商高管聊天,她说自己所在的企业,选择的高管一般会来自三个领域,产品、运营、技术。无论他来自哪一个领域,他一定不会放弃自己所熟悉的领域,否则就做得有点虚了,而对于自己不懂的领域,比如技术领域,如果他觉得在技术上缺少抓手的时候,他就会迅速地寻找自己在团队内的技术代言人,只有找到这样的人,他才能真正对团队进行掌控,不让自己在技术上落虚。但是如果短时间内找不到,或者没有人愿意担当这样的角色,怎么办?

这个时候他可能会开始转向软件开发流程,因为这一点上的管理模式似乎和其他部门的管理方式差不多,拿需求、干活、输出给用户、接受反馈意见,看起来好像确实差不多,是吗?不是的,科技行业研发项目的产品需求不等同于用户需求,它是对用户需求的产品化转换。下地干活之前,一定需要对系统进行设计,无论是瀑布式开发模型,还是 XP、敏捷,都没有否定设计环节,而是对实现方式、模块划分方式进行切分,通过对于系统架构的树形结构进行有效切分,达到快速需求收集、设计、实现、验证、需求再收集、设计修改、实现、再验证,这样的快速重复过程,实现高效的迭代,满足各个行业用户的需求。

需要记住的是,无论对于懂或不懂技术的研发领导而言,任何的软件工程模型,都不会允许在需求完全不明确、描述不清楚的情况下,开始进行技术方案设计,也不会鼓励在方案设计缺失情况下开始编码,因为这个时候没有人知道究竟如何编码。

我的理解如果没有外界的干扰,许多程序员在独自面对自己的设备时通常都会很投入地写代码,一边写一边设计。研发团队管理者必须培养软件开发文化,而文化又是建立在可靠的开发实践基础上的,否则程序设计项目就可能失败。

这里需要聊一聊研发领导需不需要编码,我觉得,其实无关是否需要编码,如果是一家成熟的科技公司,它应该从多个维度评审技术团队管理者的工作过程和成绩,而不是采用单一化规则进行评判。关键看你的输出是否需要编码,是否编码是验证你的输出或者贡献的关键环节,如果是关键环节,那你就需要编码,如果编码的价值没有技术全局把握的价值大,那么你需要把时间用在编码以外的方面,毕竟,对于技术团队管理者,产品研发、技术调研和预研、系统架构设计、未来技术方向明确、团队管理等,都属于你的工作内容。

我认为,团队领导完全可以不是对口技术专业出身,甚至可以不是理工科毕业,但是他必须对技术有热情,之前工作经历包括了开发工程师经历(这其实是必要条件),其实懂不懂技术和是不是专业出身没有任何关系,事在人为,关键看你有没有认真去做积累。有一个同事,以前是学法律的,后来转行写代码,写出的代码比很多写的年份多得多的人还强的多。她对法律相关的思维缜密,很好地就转移到了代码逻辑的缜密上,不学自通。这就是程序员,你用正常思维理解不了他们的成长路线。研发领导需要对技术有敬畏之心,需要能够有效地掌控团队的技术输出,总结为以下几点:

基础知识和理论知识非常重要,不懂技术的领导应该利用业余时间多学习,不断强化自己的弱点,慢慢地可以跟上团队的研发节奏。其实勤能补拙的道理大家都懂,就看会不会真正去实践了,保持自己终身学习的状态,看看巴菲特,每天的学习时间都会超过 6 个小时,可见每一个人都需要不断学习、思考。

多使用已有的成熟的方案是稳定当前状态的关键手段,不懂技术的领导需要在团队内培养技术代言人,通过和他的交流,逐渐明确对于技术方案的意见、理解,慢慢地你也就有了对于技术的抓手,可以有效开展工作。

对技术要有一颗严谨和敬畏的心,只有这样你才能够真正和技术人员打成一片,没有他们的帮助,最终领导的绩效也不会好,互相尊重非常重要,都是高学历的人,别把工程师的木讷当成傻。

想清楚了再干,坚持高标准,很多事情都急不来,任何的软件开发流程,都是基于软件工程模型推导得来的,都是为了解决某一类特定问题而演化得来的,所以要深入理解方法论,只有理解了才能用好。

明确技术愿景。这一点对于研发团队的稳定性和成长性非常的重要,不懂技术的领导很难在短时间内明确技术愿景,因为他自己不懂,所以要么轻视这一点,要么无从下手,这时候,团队内部的技术大牛的作用就出现了,领导需要积极主动地与这些大牛沟通,通过分派任务、搭建团队梯队等形式,让这项愿景明确工作能有实质性进展,避免研发团队出现纯粹的支撑产品状态。

写在最后

 

今天我们具体讨论了研发领导如果不懂技术怎么办?首先,我的观点是如果研发领导不懂技术,那么会容易造成团队内部人员高频率流动,也会造成技术人员缺少技术支撑,也更有可能让技术人员遇到“天花板现象”。其次,容易出现业务严重驱动技术的情况发生。再者,可能会出现乱用项目管理手段的情况出现。所以,我的观点是最高管理层应该尽量避免这种情况出现,通过任职资格等方式进行严格把控,做到能上能下,需要用专业的人带领专业的团队。

但是如果真的遇到了,作为普通员工,我们还是需要面对现实、认清形势,既然最坏的情况已经出现了,如果想继续待下去,就要努力成为他的技术顾问,你就当是在和 CEO 一起工作吧,做好自己的向上管理,无论前途是否艰难,都要咬着牙走下去,只要别人不赶你,你就做下去。

()

相 关 推 荐

图 酷 信 息

让树莓派零蛋飞一会Red Bear IoT pHAT

让树莓派零蛋飞一会Red Bear IoT pHAT
让树莓派零蛋飞一会Red Bear IoT pHAT……