技术敏感度 — 基层技术管理者必备

一说到管理者的能力特质,我们马上会联想到沟通、授权、决策等能力。然而,对于软件开发活动中的基层技术管理者(team lead、line manager等),我想指出被极为忽视的另一种重要能力 — 技术敏感度。

对于基层技术管理者来说,何为技术敏感度?技术敏感度表现为:1)工程师解释技术问题时,能快速理解并切中问题要害; 2)面对多个技术方案做选择时,具备权衡能力,并能给出有建设性的意见和建议,甚至做出选择;3)工程师提出技术想法时,能敏锐地意识到对产品和团队的意义; 4)能根据团队成员的个体差异和技能特点,及团队技能整体发展的需要,合理地调配团队成员的工作内容;5)从代码层面了解项目的质量状况;6)理解软件开发活动的复杂性本质。部分内容看似应是工程师应具备的,为何却要求基层技术管理者必备?

第一,基层技术管理者在日常工作中作为技术团队面向管理层的接口人,他们在各类与产品经理、项目经理的会议中代表着工程师队伍解释影响项目进展所面临的技术问题。这就要求管理者适时地了解项目在技术方面的进展,显然,这些进展得从工程师口中获得。日常工作中,基层技术管理者不仅要能理解工程师所解释的技术问题,还得掌握问题要害,而不能工程师解释时了解,过后却健忘。基层技术管理者如不具备这种能力,容易造成与管理层和技术团队的沟通不畅而影响工作效率。(注:我碰到过一些基层技术管理者,同样的技术问题得在不同时间段为他解释。开技术会议的主要工作是让他理解所出现的技术问题,效率之低可以想象)

第二,基层技术管理者在日常工作中不时会面临团队技术方案的选择问题。规模较大的技术方案(如系统级、子系统级)的选择通常由架构师们完成,但团队级别小规模的技术方案选择很多情形下会成为基层技术管理者的工作内容。当团队具备一个以上技术实力相当,但在设计理念上存在明显差异的工程师时,他们很有可能在项目实施的过程中主张不同的实现方案,如果设计方案无法及时达成共识,势必影响项目的顺利进展。此时,基层技术管理者得参与其中,通过运用自己的技术能力与团队共同做出设计方案的选择。在这种情况下,即使技术管理者不直接做决策,也得通过询问一些问题帮助团队做出决策。所问的问题可能有:各方案的开发成本如何?各方案所获得的长远与短期利益分别是什么?长远与短期利益哪一个更紧迫?等等。问怎样的问题,完全取决于基层技术管理者的技术能力和项目当时的具体状况,并没有标准问题集。基层技术管理者如果不具备这种能力,很容易让团队在技术方向上迷失,不利于在团队维持向上的技术氛围。(注:我看到过一些基层技术管理者,对于团队所出现的因为技术方案选择而产生的争议不闻不问,做决策时是根据各方案有多少人支持,而不是依靠自己的技术能力施加影响)

第三,工程师在工作中会提出这样或那样的技术想法,基层技术管理者很重要的工作内容是对这些想法进行积极的回应,以引导团队的技能发展。这就要求基层技术管理者对各种技术想法具备甄别能力,能敏锐地发现想法对产品与团队的意义。对于能改善产品质量与提高团队效能的想法,基层技术管理者应在团队内给予及时的肯定,并为想法的实施适当地分配资源。假如基层技术管理者缺乏这种能力,要让团队具备一定的创新能力几乎不可能。要知道,工程师所努力的方向很大程度上与基层技术管理者的认可内容有很大的关系。(注:这一点我认为是基层技术管理者做得很糟糕,他们似乎只在意项目计划和进度)

第四,提高团队技能是基层技术管理者的核心工作内容,这就要求基层技术管理者在工作中有意识地弥补团队的技能“短板”,通过考量团队成员个体的特点和技术特长合理安排工作。技术管理工作中,很害怕的是忽视个体特点以为每个人只要有机会都能成为技术专家。另外,软件开发活动中所出现的项目延期,很容易给人的假象是“任务估计不准”,而实际上,这是团队能力不足的表现。(注:请参见《技术管理的核心内容
- 提高团队技能
》一文)

第五,设计是软件产品的质量之本,但再好的设计也得通过程序代码这种“物质外壳”去表达,因此代码质量将决定软件产品的最终质量(引自《专业嵌入式软件开发》)。对于基层技术管理者来说,真实了解软件产品的质量状况并非简单地知晓发现了多少缺陷,或阅读所谓的“质量报告”,而应从产品代码中获得。由于软件开发团队是以交付高质量软件产品为使命的,这就要求基层技术管理者根据代码质量去指导技术管理工作,否则很容易浮在质量管理的表面。我认为基层技术管理者很重要的一个工作内容是帮助团队形成良好的编程习惯,如果对项目的质量没有代码级的认识,就很难就这一点在工作中引导团队。(注:有不少基层技术管理者根本没有阅读过项目的代码,而是一味地通过项目的缺陷率间接了解产品质量,甚至一厢情愿地生活在“产品质量很高”的梦境中)

第六,软件开发作为一种脑力密集型的工作,基层技术管理者如何管理知识工作者一直存在很大的挑战。在面对和克服挑战的过程中,一定需要基层技术管理者很好地理解软件开发的复杂性本质(没有“银弹”),否则很容易生搬硬套纯率的管理理论,而忽视技术因素。也只有理解软件开发的复杂性本质,才能对工程师因为面临技术难题而使得工作处于焦灼状态表示理解和保持耐心,也有助于在工作中区分问题的根源是来自管理域、抑或技术域。(注:不少基层技术管理者因为忽视管理工作中的技术因素,采用管理方法去解决技术问题,其效率与效果可以想象)

技术敏感度归结起来就是要求基层技术管理者应具备很强的技术能力(千万不要丢了“很强”两个字),或者说对技术具备良好的洞察力。对于以上谈到的几点,读者或许会想:绝大多数基层技术管理者都是技术出身的,难道就没有技术敏感度?我消极地认为,很多人都没有!

很多基层技术管理者是从技术能力较强的人群中提拔上去的,这是一个事实。然而,由于他们中的大多数在技术道路上积累的时间都比较短(8年以下),在走上管理岗位时其实对软件的复杂性本质并没有深刻的认识,更谈不上拥有自己的软件哲学思想,也没有多少成功克服技术困难的磨砺。加之,一旦走上管理工作岗位,公司在能力培养方面总爱假设他们在技术能力上能胜任工作,而大力弥补他们的管理技能。结果是,相当数量的基层技术管理者技术能力并没有达到相当的水准(管理水平也一般),谈不上对技术敏感。

基于这种现状,对于那些在技术积累还没有达到相当水准却一心想成为管理者的同仁,我的建议是:请不要急着去做管理,否则你会身不由已地失去技术的成长空间。尽管早走上管理岗位能让我们把握先机,但操之过急的职业发展是以牺牲自己的将来而换取的。在如今浮燥的社会,很少有工程师知道,其实精进自己的技术是通向成功技术管理的最有效途径。技术敏感度的缺乏会让我们在将来付出很多,也会在职业发展的道路上面临更大的困境(到时技术不精,管理也做不好,拿什么去竞争?你如何证明你的管理能力突出?)。

之所以如此强调技术敏感度,是因为只有这样基层技术管理者才更具软件开发常识,而运用常识去管理复杂的软件开发应是最为有效的方法。现实中,正是因为基层技术管理者常识的缺乏,他们在不了解工程师能力的情况下却做着绩效管理(能公平吗?),在很大程度不了解项目技术细节的情况下却做着项目计划(能合理吗?),在没有读过项目代码的情况下却做着质量控制(能有效吗?),……

强调技术敏感度并不是说基层技术管理者对所管理的项目需要了解每一个技术细节,而是强调他们应具备很好的技术积累。这里的技术积累并不是简单地指他曾经经历了多少项目、写过了多少代码(这些都是必须的),而是需要对软件开发能有深刻的认识,并拥有自己的思想,因为只有这些内容才对不同的项目具有普适性。

读到这,相信有读者会问:管理者如果没有技术敏感度,难道就不能通过用好技术人才而获得成功吗?这种话某种程度上具有一定的欺骗性。在我的工作经历中,的确碰到过一位技术敏感度缺乏,但在技术管理上却做得很好的基层技术管理者。这类人在心态上与大多数人不同,他们勇于承认自己技术能力的不足,且对团队中的技术人才给予允分的尊重和信任。实际上,要做到这些很难,尤其对于那些有很强控制欲的人来说,根本不可能。

对于基层技术管理者,最后我想说的是:你所获得的不只是权力,更有责任 —  让团队成员在快乐的工作中不断提高技能。

技术敏感度 — 基层技术管理者必备

时间: 2024-08-08 11:29:05

技术敏感度 — 基层技术管理者必备的相关文章

怎样做好基层技术管理工作?

近期有朋友与我探讨了软件基层技术管理工作方面的话题,借此从动机和方法双方面谈谈我的看法. 动机 要做好基层技术管理工作,首先要确保自己有良好的动机,即明确自己为何要走上技术管理岗位.做管理的根本是为了获得权力,但获得权力的动机却存在非常大的区别. 第一种单纯是为了利己.有相当数量的人往技术管理岗位"挤",是为了获得以后在工作中能够少做或挑做工作内容的权力:也有的人是为了更快.很多其它地获得公司动向的资讯,以体现"领导"的"与众不同":还有人是为了

如何做好基层技术管理工作?

最近有朋友与我探讨了软件基层技术管理工作方面的话题,借此从动机和方法两方面谈谈我的看法. 动机 要做好基层技术管理工作,首先要确保自己有良好的动机,即明白自己为何要走上技术管理岗位.做管理的根本是为了获得权力,但获得权力的动机却存在很大的差别. 第一种单纯是为了利己.有相当数量的人往技术管理岗位"挤",是为了获得以后在工作中可以少做或挑做工作内容的权力:也有的人是为了更快.更多地获得公司动向的资讯,以体现"领导"的"与众不同":还有人是为了更高的

唐巧:技术人如何成为管理者

_ 前不久趣直播举办了一场技术人成长交流会.邀请了小猿搜题产品技术负责人唐巧来分享.我也有幸参加了此次的交流会 以下是文字版: 我大概自我介绍一下,我叫唐巧,是小猿搜题的产品技术负责人.我之前在网易做过 2 年服务器的开发.后来和网易的同事一起参与一个之前叫做『猿题库』,现在叫做『猿辅导』的公司的创业.做 iOS 开发,现在做了有 5 年了. 大概 3 年前,2014 年 7 月份的时候我们打算做小猿搜题这个产品,当时没有人负责这款产品,我的老大就说让我来负责,所以从那个时候开始,我就慢慢的从一

AppCan CTO辩论会:移动开发者忠于技术or 背离技术

第一期CTO辩论会结束后,大家在微信群中讨论,学什么编程语言好.有位官人直呼"劳力者治于人,苦差,不学也罢". 在IT.科技变革世界的今天,移动开发者成为一个非常时髦的工种.就连老家的爷爷奶奶都知道,程序猿挣钱多,BAT待遇好,创业的孩子差不了. 但是,技术人已经不是单纯的工匠,他们正快速背离自己原本的身份,像更多元化的商业身份扩展:老板.管理者.商人等等.总之,在这个时代,技术人面临的诱惑和机遇爆发了. 热爱技术,享受技术带来的成就:也背负着技术,在每个难熬的关卡被技术所折磨. 忠于

当我们在谈论技术时,技术的本质和价值究竟是什么?

过去几年,硅谷最喜欢的口号悄悄地从"不创新,毋宁死!"换成了"不改良,毋宁死!". 湾区文化中,改良意味着全套的技术解决方案,它兜售着一种人类理想主义,从而让这里的极客们更有抱负.更愿意相信一己之力可以推动经验创新.社会发展.这就好比鉴赏者和艺术家,二者对"结构性颠覆和改革"有着截然不同的认知感及行动力. 如今这种对"改革"的认知变化,也发生在最近一年的中国互联网公司身上.这篇文章,要讲的就是"改革背后的力量&quo

论战技术管理,技术重要还是管理重要

1.项目的发起人 项目发起人是项目的执行组织(如一个企业)内部或外部的个人机体,他们以现金或实物为项目提供资金.资源,是对项目的获利负有责任的人.项目发起人有时指首先实际命令执行项目的人,他可能是客户,但在许多情况下是第三方.一般来说,项目发起人负责保证项目得到合适的预算款项,其计划可以接受以及项目组织具有达到要求的结果所需要的资源.发起人这个角色担负着相当大的责任,必须向所有关心项目成功与否的人证明项目的优势. 2.项目/程序管理小组 这个小组由高级管理人员组成,往往包含项目发起人.小组成员定

产品经理如何与强势的技术沟通? 技术比较有资历,会以技术无法实现等方面的原因拒绝处理产品提出的需求。 你们是否遇到这样的技术? 产品懂技术的话,是不是会好一些,因为可以和技术说“行话”了,并且产品懂技术就不会被忽悠了。

PM在YY...作为强势的技术来回答一下吧.说明白WHY,HOW,WHAT就好了. 我想点两个赞,u can u up,no can no bb 什么的. 微软的win8之父年轻时候也是一个PM应该是微软最伟大的pm之一了吧.他有一天和程序员起了冲突,程序员说必须有两周才能干完,他说项目等不及了.就这样冲突一直没有一方让步,直至一周后,这个PM带着自己写的code给程序员看,他只用一周就可以这些功能.所以产品经理还是要懂一些技术才能和程序员更好交流 我觉得碰到强势的工程师是一件好事.同时,别人拒

【CTO辩论会】移动开发者忠于技术or 背离技术

第一期CTO辩论会结束后,大家在微信群中讨论,学什么编程语言好.有位官人直呼"劳力者治于人,苦差,不学也罢". 在IT.科技变革世界的今天,移动开发者成为一个非常时髦的工种.就连老家的爷爷奶奶都知道,程序猿挣钱多,BAT待遇好,创业的孩子差不了. 但是,技术人已经不是单纯的工匠,他们正快速背离自己原本的身份,像更多元化的商业身份扩展:老板.管理者.商人等等.总之,在这个时代,技术人面临的诱惑和机遇爆发了. 热爱技术,享受技术带来的成就:也背负着技术,在每个难熬的关卡被技术所折磨. 忠于

调试逆向分为动态分析技术和静态分析技术(转)

在软件开发的过程中,程序员会使用一些调试工具,以便高效地找出软件中存在的错误.而在逆向分析领域,分析者也会利用相关的调试工具来分析软件的行为并验证分析结果.由于操作系统都会提供完善的调试接口,所以利用各类调试工具可以非常方便灵活地观察和控制目标软件.在使用调试工具分析程序的过程中,程序会按调试者的意愿以指令为单位执行. 调试逆向分为动态分析技术和静态分析技术. 动态分析技术指的是使用调试工具加载程序并运行,随着程序运行,调试者可以随时中断目标的指令流程,以便观察相关计算的结果和当前的设备情况.