技术管理者应具备哪些能力

作为技术管理者,要做好以下3个核心能力

1. 自我驱动是基本能力,没有自动驱动的人不能当管理层,不能带人

1.  架构上把握设计的大方向,技术架构不会走偏

2.  每个人的职责明晰,目标管理,每周定期过下每个人手上工作(给每个人下考核,每两天过一下进度,授权)

3.  团队中有疑难问题搞不定的时候快速出马搞定


如果将一名技术管理者的能力比喻为如下的立方体的体积,其能力公式如下:

整体能力 = 技术能力 * 产品能力 * 管理能力

则任何一个维度能力的短板都将严重影响其整体能量水平,如下图所示:


技术管理者应具备哪些能力_第1张图片
图3:技术管理者的多维度能力

1、纯技术思维的人:很容易把自己封闭在一个纯粹的技术世界里,在那里只有自己研究的技术。容易固执地认为技术是万能的,技术可以解决一切问题。容易过分的高估技术,人很单纯,也很固执。无法很好地和不同类型的人达成真正的合作,其带领的团队也很难壮大。这样的人适合专注于搞技术,并不适合将其放在团队leader的位置。

2、纯产品思维的人:善于沟通、思维发散,初次交往时很会抓住别人的注意力。如果由其掌舵大型的技术团队,长时间后会发现他们容易出现思路逻辑不清,缺乏恒久的坚持和方向感,也容易出现以用户需求之名把团队带进坑里。

3、纯管理思维的人:如果没有技术或者产品或者其他某一方面能力的补足,在以技术/产品为驱动的团队很难建立起威信。从而很好的带领一个技术团队


1. 论技术管理者的技术能力路径

技术管理者应具备哪些能力_第2张图片
图1:技术思维的大致成长路径

编程技术的提高需要不断的学习、总结、提炼、分享,这是一个环,也是一个迭代的过程。大学教给我们很好的学习能力,编程技术领域发展又快,日新月异,这要求我们通过各种方式来吸收新的知识。总结是在不断的项目实践、代码实现中,反思和归纳自己技术实现里的优点和缺陷。例如重构的过程、模式的使用等。提炼是提升的过程,从量到质,从更高的层次思考编程之道。分享是自己把经验和思考的结果传播出去,让别人认知,产生共鸣,给予反馈的过程,从中我们获得了别人的经验和能力,形成有效补充,又再次进入了学习的过程。

2. 论技术管理者的管理能力路径

技术管理者应具备哪些能力_第3张图片
图2:管理思维的大致成长路径

CSDN:你是如何从技术层提升到管理层的?期间有什么有意思的回忆?

蒋宇捷:我于2007年7月进入傲游,一个月转正,2个月担任项目负责人,3个月就被提升为技术Leader。这个过程非常顺利,我的经验是要快速的做出成绩,展现出自己的能力。我当时第一次接触Perl这门编程语言,一边学习一边开发项目,共花了一个多星期时间,完成了一个类似于百度知道,包含全文检索功能,从前端到后台功能齐备的网站,这一次的经历为我晋升打下了很好的基础。

CSDN:你认为一名技术经理或是技术管理者,应具备什么样的能力?

蒋宇捷:我认为技术管理者有几个必备的能力:

1. 沟通说服能力:作为管理者,每天做的最多一件事情就是沟通,向上、下级,以及横向沟通,要让团队、项目按照正常的方向前进,要能够说服别人按照你的想法去执行,这点非常重要。

2. 分析判断能力:进行技术决策时,要冷静、全面的思考和分析,给出正确的技术方向,是每个技术管理者必备的能力。方向的正确程度决定了项目开展的速度与质量,正确的方向和优秀的架构即便在多年过后仍然焕然如新。

3. 产品架构能力:技术管理者必须要对产品有很深刻的认识,要充当技术和产品之间的桥梁,否则永远只能孤立的从技术层面看待问题,而无法从整个产品、项目的高度评判需求,以及技术实现的合理性。

以下是本人实际操作中的一些体会:

1、“让程序员们觉得自己的工作有意义”这点很重要。

2、把项目里面的工作全面细化,将工作任务缩小到最小单位。并进行KPI考核。

3、使用一些现成的开发工具或解决方案,避免团队长期在做重复性的劳动。

4、通常“大牛”们不善于做管理,给他们经理的待遇,避免他们管人,让他们专心的去写程序。

5、和技术人员沟通之前,应明确自己对于产品功能需求。并在项目进行的过程中,尽力减少功能需求变更的频率。三天两头改需求,会导致程序员发疯。如果非这样做不可,可以考虑建一个 @蔡学镛 微博上提到的“发泄室”。

6、耐心听他们说完,再发表自己的观点。

CSDN:你现在是否坚持每天编程,这对你有何帮助?

蒋宇捷:我现在大部分时间都用在沟通、协调、思考、解决团队和项目中的问题,以及产品的方向上。不过前段时间我还主持并亲自参与了产品前端重构的项目,由此也对一些新的开发技术和框架有了新的了解和认识。技术来源于一线,永远不能脱离一线

CSDN:在用技术手段完成某战略或运营目标的过程中,有何常见的难题?身为技术管理者,能不能分享下都是如何解决的?

蒋宇捷: 常见问题有3个,需求的不确定性、需求方面和时间与质量的平衡点。

1. 需求的不确定性:需求的变化永远是无法预估的。有两个问题可能每个人都有亲身的体验。

第一个是“作为产品经理,你被技术问的最多的问题是什么?”,答案是“你确定以后不改了?”。

第二个是“作为工程师,你问产品经理最多的问题是什么?”,答案是“这个功能是不是可以放到下个版本再做?”。

解决方法:需求的不确定造成技术实现有很大的不确定和后期变更风险,这个时候我们要做的是先确定技术方向、技术框架,通过拆分模块、利用设计模式容纳变化,以及在产品层面细分story等各种方法,来减轻每个迭代时需求变化的风险。

2. 需求来自方方面面:有时候完成目标的过程中,需求会来自方方面面,而不仅仅是单纯的产品需求。

解决方法:这时候就需要技术管理者评估成本、抵挡一些需求,或向对方明确预期。我的经验是最好开诚布公的讨论代价和收益,也需要管理者从更高维度的战略层面来考虑,否则有可能违背公司的整体战略。

3. 时间与质量的平衡:完成目标的过程中,常常遇到时间与质量的平衡之困。例如,经常版本早已确定了发布日期,但是由于时间有限,开发和测试时间都严重不足,这会导致产品质量不可控,是否按时发布就变成了一个难题。

解决方法:管理者除了在流程上整体把控外,还需要向上、下级,以及和各种角色沟通,降低时间和质量的预期,并结合一些保障机制。例如,核心用户群、灰度发布来减轻风险。

CSDN:做产品的过程中最惨痛的失败教训有哪些?

蒋宇捷: 创业的经验和教训告诉我:产品好不好用,用户很快就会投票。如果用户量迟迟不能增长,那是产品本身的定位出现了问题。需要尽快改变产品方向,迅速试错。从最近一些成功的产品美丽说、唱吧中,我们都能找到同样的轨迹。另外创业初期,渠道没那么重要,运营却是非常重要的一部分。

CSDN:传统互联网企业转变到移动领域,你觉得技术难点在哪里?有何好方法能克服困难?

蒋宇捷:传统互联网企业转变到移动领域主要有几个门槛:意识门槛、技术门槛和商业模式门槛。意识门槛指没有意识到抢占移动领域的重要性和紧迫性;技术门槛是指企业里没有对移动领域有很深了解和专门的开发人员;商业模式门槛指在移动领域变现较难,要花很大力气去探索。

我的建议是传统互联网企业要从意识上加深认识,从技术上加大投入,从商业模式上加强对全行业和用户的调研,以及和移动互联网企业合作也是不错的选择。

CSDN:对于移动开发的未来,你觉得哪些技术最值得开发者关注,或者需要开发者掌握?对于希望学习开发的初学者,你有什么建议?

蒋宇捷:抛开比较成熟的Android和iOS开发技术,HTML5是未来移动开发的趋势。开发者应该或多或少认识到它的力量和作用。关注HTML5的初学者可以多参加一些HTML5的沙龙或者讲座,关注一些优秀的技术博客,或者阅读一些入门书籍。

你可能感兴趣的:(技术管理者应具备哪些能力)