聊聊技术专家的类型及其成长路径

我的职业生涯经历过多个角色，从普通程序员、高级工程师、项目经理、架构师、部门经理、总监，都经历过。虽然看上去有一些跨度，但总体来说跨度并不大，有一定的传承。 

有些岗位看上去差别挺大的，比如项目经理（这里专指的有技术背景的）和架构师之间，但往深了看，还是有些共通之处。这得看公司是什么类型、什么体量的，处于什么阶段。在中小公司体系下，有些title并没有很局限，比如总监有时候也干技术经理、项目经理和架构师的活。大公司分工细，就另说了。 

回到本期的主题，技术专家这里是泛指了，包括架构师、系统工程师（SE）、某个业务领域或技术领域的资深专家等。这里，如果是中小公司的技术专家，很可能也是要身兼多职了，一旦公司发展相对成熟，人力相对充沛之后，定位也会聚焦一些。当然，前提是这位技术专家还在这公司，或者他本身对公司还有相匹配的价值了。

 

一、架构师

这几年，架构师在技术领域算比较火的称谓。其实早些年，“架构师”的称谓并没有很流行，特别是在华为之类的设备厂商或者一些涉及底层技术比较多的企业里。这些企业，对技术专家的称谓一般是系统工程师（即SE或SA）。 

“架构师”的称谓，我认为更多是随着互联网的发展壮大而兴起的。它本身对业务层面的系统架构涉及会更多一些，当然这里面技术占了很重要的分量。 

一旦被称为架构师，往往代表公司对他技术能力的认可，这里的技术能力是综合的，包括技术基础、底层原理、架构思维、对通用架构的理解和使用。言而简之，就是技术功底和“技术生态”的理解和实操。当然技术之外，对业务的熟悉程度和行业的理解也是很重要的。 

架构师有时候并不是专程做技术，有的架构师也干高级工程师的活，需要写写核心代码甚至部分业务代码，一个道理。当然了，有的项目比较复杂，需要多端合作，如果这个项目没有专门的项目经理来拉通和跟进，那架构师很可能也要干项目经理的活。因为架构师是对业务和技术架构最熟悉的人，知道哪些人、哪些环节是关键。

 通过前面的分析，接下来就讲讲怎么能成为架构师。 

需要经过长时间的学习（包括工作中和业余）、实践、摸索和总结，才能具备基本的架构师素养。另外，要有大中型的项目历练，以架构师或技术骨干的身份参与的那种。

  

二、系统工程师

在上一节讲到了，系统工程师一般是在华为之类的设备厂商或者一些涉及底层技术比较多的企业里，对通用型技术专家的称谓。 

整体的成长路径和架构师类似了，只是涉及的产品形态、业务和技术层面不太一样（此次没有优劣之分）。所以可以参考架构师的成长之路。

 

三、某一技术领域的专家

这个怎么理解？和架构师、系统工程师有什么区别呢？ 

主要是针对某一个较为庞大的技术领域，或者其中某个细分方向了。 

举个栗子，音频处理专家、视频领域技术专家。我一个在阿里的同学，目前是P8，他就是专门负责音频的处理，一直干了很多年了。因为这个领域很宽广，业务应用也很广阔，技术上可以钻的很深，所以有些大厂就养得起这样的人长时间专门来研究这个领域。其实真正研究深入了，是很吃香的，很难被替代。 

其实这样的技术领域是有一些，应用方面千变万化，但技术底层往往是相通的。大家就看看，这些年，互联网各种应用层出不穷，技术架构、组件、模式不断更新，但大学里学的基础课程还是那几门。这就是底层技术的通用性。

 

四、某一业务领域的专家

类比上面某个技术领域的专家一节，业务领域也是有相应的专家的。 

当然这里说的业务领域专家，专指懂技术的业务专家，或者从技术领域转型过来的业务领域专家。 

懂技术，所以对业务的理解会更加深入。当跟客户交流，或者理解某一项业务的底层原理的时候，常常就需要对技术有一定的理解才行。 

所以就不难理解业务领域专家的由来了。 

同样举个栗子，泳池机器人领域专家，就需要对游泳池领域的场景有深刻的理解才行，同时要对机器人相关技术有足够的认知。结合起来，就是这个业务领域的专家了。 

要做到这种角色，需要有一定的技术背景，这里不一定需要很深的技术研究。另外，对行业和业务得有足够的认知，跟行业相关人士有一定的交流，跟进行业或领域的发展趋势。

 

五、大公司的技术专家

为什么把大公司的技术专家单独拎出来讲？ 

因为大公司本身体量大，技术栈庞杂，同时公司有自己的技术文化和技术特点。在某个公司体系下成长起来的技术专家，就有其特殊性，他对这个公司的玩法很熟悉，在别的公司未必很有优势。 

所以在某一家大公司待了很久的技术专家，如果持续在公司发展，那还是有优势的。特别是熟悉公司运作流程和特定业务的专家。市场通用型的技术专家就另说了。