谈谈程序员、技术主管和架构师

在程序员从初级走向资深的过程中，会面临两个支路，一个叫「技术主管」，另一个则是「架构师」。为什么这是两条支路？因为现在回过来看，这两条路从来都不是程序员的自然成长路径，下面我们先从「技术主管」开始吧。

技术主管

技术主管，有些公司可能又叫「技术经理」，英文一般是 Tech Leader 或简称 TL。在拉姆·查兰 (Ram Charan) 那本《领导梯队》中提到一个人的工作角色中至少有百分之五十以上的时间是花费在管理事务上，那么他的角色才算是一个经理（Manager）。所以技术主管（经理）类似产品经理属于以经理命名却是非经理的角色。

「技术主管」是开发团队中的某位程序员需要对一起创建系统的整个开发团队负责时所承担的角色。通常他既要对最终交付的软件系统负责，另外也会像一个程序员一样去开发实现系统。一个技术主管的 60% ～ 70% 的时间可能花在了开发任务分解分配、开发实践、代码审核和风险识别上，而余下的 30% ～ 40% 的时间则花在为了保障系统按时交付所需的各种计划、协作、沟通、管理上。和团队管理者不同的是，技术主管的大部分管理工作都是针对具体研发任务和技术事务的。

例如：在一个开发团队中经常会碰到因为技术方案和实现细节方面的分歧，如果程序员无法自主友好的完成对不同技术意见的统一，这时候技术主管就需要介入去了解两种不同意见所造成的冲突。对事不对人的去把问题搞清楚，分析各自方案的利弊，必要的时候甚至能够提出第三种更好的技术方案，以帮助开发团队达成共识。

另一方面，技术主管即使在日常的开发实现中，重点的内容一般也不是放在某个具体的功能实现上。在完成了具体的开发任务评估、分解并分配后，技术主管应该负责设计整体代码的结构和规范、必要时引入能提高整个团队生产力的新工具，推广代码模板，总结最佳实践。他需要经常性的关注整个团队完成一项研发任务的水平和实际要求的水平的差距问题，让团队不仅满足及时的软件系统交付，同时又得到成长。

现实中，一个开发团队中最优秀的程序员容易被指定承担技术主管的角色，但优秀的程序员又很容易陷入到实现功能的细节中，满足于完美的实现，优雅简洁的代码。实际上，这样优秀的程序员转入技术主管这个角色后，就很容易尝试控制设计和代码的实现，他们很难接受代码不按照他们希望的方式去编写，这个是他们作为优秀程序员一直以来的工作习惯，长此以往他们自身很容易变成整个开发团队的瓶颈，而团队里的其他成员却未能得到足够的锻炼和成长。

所以技术主管实际相比团队里的其他程序员对系统的视角更开阔，以更有策略和长远的方式来考虑问题。他们即使拥有比团队里所有其他程序员更高超的开发实现技能，对所有开发任务拥有最强大的实现自信，也需要转变为另一种「借助他人使之实现」的能力和自信，因为技术主管是一个承担更广泛责任的角色，必然导致能够专注有效编码的时间会相比以前减少很多，而这一点正是优秀程序员转变为技术主管的所面临的最大挑战之一。

最后，我们总结下技术主管的职责要求：

• 技术职责

    ♦ 研发任务管理

    ♦ 工作量评估

    ♦ 任务分解、分配

    ♦ 代码审核

    ♦ 风险识别

    ♦ 技术能力提升

    ♦ 代码规范制定和推广

    ♦ 生产力工具研发和推广

    ♦ 最佳实践总结和推广

    ♦ 关键代码实现

• 组织职责

    ♦ 协调沟通

    ♦ 招聘面试

    ♦ 教练指导

    ♦ 复盘总结

架构师

看完上面关于技术主管的职责能力要求，想必你会有些疑惑，感觉好像很多条目对架构师也是这么要求的。对，你的感觉没错，技术主管的角色与架构师这一角色会产生一些职责上的重叠，事实上我自己认为在团队规模比较小的时候（10 多人的规模），架构师和技术主管的职责几乎完全重叠，甚至技术主管还会代理一些团队主管的角色。

和技术主管一样，架构师也是一个在业界拥有著名的称谓，但在绝大部分公司却不属于一个职位序列。许多公司都很纠结于如何定义架构师的角色，以及架构师所做的工作。以前听阿里同学说 P7 属于架构师职位，不过最近在看另一个阿里同学写的文章说：“前几年是有专职的「架构师」职位的，现在已经回归到「工程师」、「技术专家」、「研究员」这样的纯技术职位。”。可见在一线互联网公司关于架构师的定义也是很模糊的。

曾经在一篇文章《在首席架构师眼里，架构的本质是…》提到了一个架构师能力模型，我曾经写过结合我自己的经历和经验，这个能力模型针对架构师这个角色来说还是比较符合的。

但正因为业界和公司对架构师这个角色的职责定义很模糊，所以很多经验积累到一定程度的优秀程序员，并且在公司内被提升到一定高度的技术级别后，都会冠以架构师之名。但实际情况是大部分刚刚冠以架构师之名的优秀程序员，其能力模型大部分停留在上图中的蓝色区域，而对其他区域并未有过系统性的认识和训练。

看过了架构师的能力模型，我们再来试着分析下对应的职责。随着软件系统复杂度和规模的提升，团队也相应变大，那么一个架构师此时所处的职责位置就开始和技术主管区别开来，如果把技术主管想成是站在楼顶看整个系统，那么架构师此时就是需要挂个气球（此处脑补下动画《飞屋环游记》的场景），飞到天上去看整个系统了。

除了技术主管的技术职责之外，架构师还需要站在更高的纬度去做关于软件系统的抽象和封装。如果技术主管的抽象和封装层次更多考虑的是语言函数、设计模式、代码结构等这一类的事务，那么架构师是站在整体软件系统高度，考虑不同子系统之间的交互关系、技术的合理性、需求的完整性、未来的演进可能性，技术体系发展与组织、产品商业诉求的匹配度。

这是相对技术主管更高纬度的全局视角，另一方面依然有很多技术主管可能感觉没把握的技术决策和技术争端需要架构师的介入协调。之所以要找架构师来对一些技术争端和方案进行决策判断，很多情况在于程序员对架构师在技术领域内专业力和影响力的信任，而建立这种专业力和影响力是实际构建架构师非权威领导力的来源。

这里提到一个「非权威领导力」，这是什么？非权威是相对权威而言，管理者的权威领导力来自于公司正式任命的职位和职权，而架构师在大部分公司基本连职位职责都没定义清楚，更没有职权一说，所以实际上就不会有任何权威领导力。所以，架构师要发挥更大的作用和价值就需要去构建自己的非权威领导力，而这需要长期的专业力和影响力积累，而关于如何去积累并很好的发挥作用，这一点我也还在摸索，还没有形成很系统的认知体系。

另一方面，架构师的组织职责除了技术主管承担的之外，架构师还承担着在技术团队和非技术团队（例如：产品设计等团队）之间的接口作用，明确产品的边界，勾勒技术蓝图，协调不同技能的技术团队协作，完成最终的软件系统交付。这时架构师的角色就像服务化架构中的 API，定义了协作规范、交互协议和方式，但并不会聚焦在具体的实现上。

在更大规模的系统上，架构师似乎还要去涉猎更多的跨领域知识，否则很可能无法做出最适合的技术决策。但人终究是有局限的，你不可能学完所有领域，所以特定的领域又会涌现一些垂直领域的架构师。比如：数据架构师、网络架构师、业务架构师、安全架构师。因而某一个领域背景出身的架构师，他对其他领域也只能做个初步了解，当需要作出关于涉及其他领域的架构决策时，他就需要和其他领域的垂直架构师做深度的沟通交流，以辅助决策判断。

最后，我们还是总结下架构师的职责要求：

• 技术职责

    ♦ 继承技术主管的职责

    ♦ 高纬度的系统设计、抽象和封装

    ♦ 产品技术蓝图绘制与关键技术决策

• 组织职责

    ♦ 继承技术主管的职责

    ♦ 跨技术和非技术团队的接口协作

发展取舍

从一开始，我就提到技术主管和架构师是程序员自然成长路上的两条支路，始终停留在上面「出色程序员」能力模型域的程序员是无法很好的胜任技术主管和架构师这两个角色的。所以程序员在成长到一定阶段就需要去考虑是否真要往技术主管和架构师的方向发展。而从技术主管走到架构师相对而言更有延续性，但技术主管也会有另一条路，就是转型走上纯管理岗位，成为一名真正意义上的经理。

一旦选择走入架构师这条路，基本你就从一名出色的程序员这个领域走出，需要尽快去补充上面能力模型中指出的其他能力。这一点会让刚刚走上这条路的程序员很不适应，因为承担了更多其他职责，就必然要减少在编码实现的时间，慢慢就会怀疑自己的编码能力会退化，也跟不上一线最新的技术栈，各种酷酷的新工具。我曾有一段时间就产生过这样的茫然与惶恐，如今算是释然了。

舍得，舍得，没有舍就没有得。成为架构师会拥有一个更立体的知识、技能矩阵，这是你的得。获得了一个面，在某些点上必然面临被超越的结局。如果成为一名架构师好几年后，你居然还是团队里面编码最多，编程能力最强的人，其实这是一个失败的架构师，在教练和指导这个职责上已经完全的失败了。而有些谈论架构师的文章说：

架构师一定要负责整个系统中最核心和最难的地方的代码编写，如果一个团队里需要一个架构师，那他一定必须是团队里写代码能力最好的，而且要负责至少 40% 以上的核心开发工作。

上面的说法就是扯淡，这样的架构师就是这个团队最大的瓶颈。一个稍具规模的软件系统和团队中，承担 40% 以上的核心开发工作，基本上这样的架构师就是一个资深程序员，而架构师的其他职责我估计他都没时间和能力去考虑了。他会意识到这种方式无法持久，同时也夺走了其他开发者的创新能力和解决问题的乐趣，一个有经验的架构师能够更好地表达某些指导原则，并且了解什么时候该插手，什么时候该放手。

而架构师到底要不要编码，承担多少的编码工作，不是由某种定义和说法决定的。而是由架构师自己决定的，因为架构师承担了软件系统的最终交付和过程风险识别，如果架构师认为某些关键部分，团队里没有其他人能在交付日期前写出达到他认可的足够可靠的代码，他把这识别为一种风险，决定自己完成，那么他就去编码实现，否则就委托给他认为足够可靠的团队成员，这就是前面提到的「借助他人使之实现」的能力和自信。

当团队里的程序员都逐渐获得成长，成了高级或资深程序员之后，架构师实际还需要写代码的机会越来越少。这方面的能力必然面临退化，所以这方面对一线技术栈的决策会越来越交给一线资深程序员来判断。但我们担心时代、环境变化，有一天又需要回到一线技术栈时，那时技术栈已经发生了巨大变化，架构师还能很好的适应么。技术的理解和基础如内功，而重新学通一门技术栈如招数，我觉得也未必需要多少时间，数月、半年或一年也许又让你恢复到在新技术栈上感觉良好的编程状态。

…

有时候安安静静的做个程序员，也挺好的。