Chinaunix首页 | 论坛 | 博客
  • 博客访问: 310764
  • 博文数量: 118
  • 博客积分: 2010
  • 博客等级: 大尉
  • 技术积分: 1163
  • 用 户 组: 普通用户
  • 注册时间: 2009-08-27 12:09
文章分类

全部博文(118)

文章存档

2023年(20)

2022年(3)

2021年(1)

2020年(1)

2019年(7)

2013年(2)

2011年(1)

2010年(37)

2009年(46)

我的朋友

分类: IT职场

2013-05-30 23:43:45

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

上一篇:正确理解ThreadLocal

下一篇:没有了

给主人留下些什么吧!~~