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

最近在进一步思考程序员的成长，曾经写过一篇《程序员的成长阶梯和级别定义》 ，里面写了我对程序员主要成长阶段的定义，但在程序员从初级走向资深的过程中，会面临两个支路，一个叫「技术主管」，另一个则是「架构师」。为什么这是两条支路？因为现在回过来看，这两条路从来都不是程序员的自然成长路径，下面我们先从「技术主管」开始吧。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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