从程序员到技术主管和架构师你分别要掌握什么能力
在程序员从初级走向资深的过程中，会面临两个支路，一个叫「技术主管」，另一个则是「架构师」。为什么这是两条支路？因为现在回过来看，这两条路任何程序员发展到一定阶段面临选择的不同路径，下面我们先从「技术主管」开始吧。
技术主管是什么？
技术主管，有些公司可能叫「技术经理」。在拉姆·查兰 (Ram Charan) 那本《领导梯队》中提到一个人的工作角色中至少有百分之五十以上的时间是花费在管理事务上，那么他的角色才算是一个经理（Manager）。但是技术主管 （经理）类似产品经理属于以经理命名却是非经理的角色。
「技术主管」是开发团队中的某位程序员需要对一起创建系统的整个开发团队负责时所承担的角色。通常他既要对终交付的软件系统负责，另外也会像一个程序员一样去开发实现系统。
一个技术主管的 60% ～ 70% 的时间可能花在了开发任务分解分配、开发实践、代码审核和风险识别上，而余下的 30% ～ 40% 的时间则花在为了保障系统按时交付所需的各种计划、协作、沟通、管理上。
和团队管理者不同的是，技术主管的大部分管理工作都是针对具体研发任务和技术事务的。
例如：在一个开发团队中经常会碰到因为技术方案和实现细节方面的分歧，如果程序员无法自主友好的完成对不同技术意见的统一，这时候技术主管就需要介入去了解两种不同意见所造成的冲突。对事不对人的去把问题搞清楚，分析各自方案的利弊，必要的时候甚至能够提出第三种更好的技术方案，以帮助开发团队达成共识。
另 一方面，技术主管即使在日常的开发实现中，重点的内容一般也不是放在某个具体的功能实现上。在完成了具体的开发任务评估、分解并分配后，技术主管应该负责设计整体代码的结构和规范、必要时引入能提高整个团队生产力的新工具，推广代码模板，总结佳实践。他需要经常性的关注整个团队完成一项研发任务的水平和实际要求的水平的差距问题，让团队不仅满足及时的软件系统交付，同时又得到成长。
现实中，一个开发团队中的程序员容易被指定承担技术主管的角色，但的程序员又很容易陷入到实现功能的细节中，满足于完实现，优雅简洁的代码。 实际上，这样的程序员转入技术主管这个角色后，就很容易尝试控制设计和代码的实现，他们很难接受代码不按照他们希望的方式去编写，这个是他们作为程序员一直以来的工作习惯，长此以往他们自身很容易变成整个开发团队的瓶颈，而团队里的其他成员却未能得到足够的锻炼和成长。
所以技术主管实际相比团队里的其他程序员对系统的视角更开阔，以更有策略和长远的方式来考虑问题。他们即使拥有比团队里所有其他程序员更高超的开发实现技能，对所有开发任务拥有强大的实现自信，也需要转变为另一种「借助他人使之实现」的能力和自信，因为技术主管是一个承担更广泛责任的角色，必然导致能够专注有效编码的时间会相比以前减少很多，而这一点正是程序员转变为技术主管的所面临的大挑战之一。
架构师是什么？
看完上面关于技术主管的职责能力要求，想必你会有些疑惑，感觉好像很多条目对架构师也是这么要求的。对，你的感觉没错，技术主管的角色与架构师这一角色会产生一些职责上的重叠，事实上我自己认为在团队规模比较小的时候（10 多人的规模），架构师和技术主管的职责几乎完全重叠，甚至技术主管还会代理一些团队主管的角色。
和技术主管一样，架构师也是一个在业界拥有的称谓，但在绝大部分公司却不属于一个职位序列。许多公司都很纠结于如何定义架构师的角色，以及架构师所做的工作。以前听阿里同学说 P7 属于架构师职位，不过近在看另一个阿里同学写的文章说：“前几年是有专职的「架构师」职位的，现在已经回归到「工程师」、「技术专家」、「研究员」这样的纯技术职位。”可见在一线互联网公司关于架构师的定义也是很模糊的。
但正因为业界和公司对架构师这个角色的职责定义很模糊，所以很多经验积累到一定程度的程序员，并且在公司内被提升到一定高度的技术级别后，都会冠以架构师之名。但实际情况是大部分刚刚冠以架构师之名的程序员，其能力模型大部分停留在上图中的蓝色区域，而对其他区域并未有过系统性的认识和训练。
看过了架构师的能力模型，我们再来试着分析下对应的职责。随着软件系统复杂度和规模的提升，团队也相应变大，那么一个架构师此时所处的职责位置就开始和技术主管区别开来，除了技术主管的技术职责之外，架构师还需要站在更高的纬度去做关于软件系统的抽象和封装。如果技术主管的抽象和封装层次更多考虑的是语言函数、设计模式、代码结构等这一类的事务，那么架构师是站在整体软件系统高度，考虑不同子系统之间的交互关系、技术的合理性、需求的完整性、未来的演进可能性，技术体系发展与组织、产品商业诉求的匹配度。
这是相对技术主管更高纬度的全局视角，另一方面依然有很多技术主管可能感觉没把握的技术决策和技术争端需要架构师的介入协调。之所以要找架构师来对一些技术 争端和方案进行决策判断，很多情况在于程序员对架构师在技术领域内专业力和影响力的信任，而建立这种专业力和影响力是实际构建架构师非领导力的来源。
这里提到一个「非领导力」，这是什么？非是相对而言，管理者的领导力来自于公司正式任命的职位和职权，而架构师在大部分公司基本连职位职责都没定义清楚，更没有职权一说，所以实际上就不会有任何领导力。所以，架构师要发挥更大的作用和价值就需要去构建自己的非领导力，而这需要长期的专业力和影响力积累。
另一方面，架构师的组织职责除了技术主管承担的之外，架构师还承担着在技术团队和非技术团队（例如：产品设计等团队）之间的接口作用，明确产品的边界，勾勒技术蓝图，协调不同技能的技术团队协作，完成终的软件系统交付。这时架构师的角色就像服务化架构中的 API，定义了协作规范、交互协议和方式，但并不会聚焦在具体的实现上。
在更大规模的系统上，架构师似乎还要去涉猎更多的跨领域知识，否则很可能无法做出适合的技术决策。但人终究是有局限的，你不可能学完所有领域，所以特定的领域又会涌现一些垂直领域的架构师。比如：数据架构师、网络架构师、业务架构师、安全架构师。因而某一个领域背景出身的架构师，他对其他领域也只能做个初步了解，当需要作出关于涉及其他领域的架构决策时，他就需要和其他领域的垂直架构师做深度的沟通交流，以辅助决策判断。
从一开始，我就提到技术主管和架构师是程序员自然成长路上的两条支路，始终停留在上面「出色程序员」能力模型域的程序员是无法很好的胜任技术主管和架构师这两个角色。
所以程序员在成长到一定阶段就需要去考虑是否真要往技术主管和架构师的方向发展。而从技术主管走到架构师相对而言更有延续性，但技术主管也会 有另一条路，就是转型走上纯管理岗位，成为一名真正意义上的经理。
一 旦选择走入架构师这条路，基本你就从一名出色的程序员这个领域走出，需要尽快去补充上面能力模型中指出的其他能力。这一点会让刚刚走上这条路的程序员很不适应，因为承担了更多其他职责，就必然要减少在编码实现的时间，慢慢就会怀疑自己的编码能力会退化，也跟不上一线新的技术栈，各种酷酷的新工具。
舍得，舍得，没有舍就没有得。成为架构师会拥有一个更立体的知识、技能矩阵，这是你的得。获得了一个面，在某些点上必然面临被超越的结局。如果成为一名架构师好几年后，你居然还是团队里面编码多，编程能力强的人，其实这是一个失败的架构师，在教练和指导这个职责上已经完全的失败了。
技术主管是什么？
技术主管，有些公司可能叫「技术经理」。在拉姆·查兰 (Ram Charan) 那本《领导梯队》中提到一个人的工作角色中至少有百分之五十以上的时间是花费在管理事务上，那么他的角色才算是一个经理（Manager）。但是技术主管 （经理）类似产品经理属于以经理命名却是非经理的角色。
「技术主管」是开发团队中的某位程序员需要对一起创建系统的整个开发团队负责时所承担的角色。通常他既要对终交付的软件系统负责，另外也会像一个程序员一样去开发实现系统。
一个技术主管的 60% ～ 70% 的时间可能花在了开发任务分解分配、开发实践、代码审核和风险识别上，而余下的 30% ～ 40% 的时间则花在为了保障系统按时交付所需的各种计划、协作、沟通、管理上。
和团队管理者不同的是，技术主管的大部分管理工作都是针对具体研发任务和技术事务的。
例如：在一个开发团队中经常会碰到因为技术方案和实现细节方面的分歧，如果程序员无法自主友好的完成对不同技术意见的统一，这时候技术主管就需要介入去了解两种不同意见所造成的冲突。对事不对人的去把问题搞清楚，分析各自方案的利弊，必要的时候甚至能够提出第三种更好的技术方案，以帮助开发团队达成共识。
另 一方面，技术主管即使在日常的开发实现中，重点的内容一般也不是放在某个具体的功能实现上。在完成了具体的开发任务评估、分解并分配后，技术主管应该负责设计整体代码的结构和规范、必要时引入能提高整个团队生产力的新工具，推广代码模板，总结佳实践。他需要经常性的关注整个团队完成一项研发任务的水平和实际要求的水平的差距问题，让团队不仅满足及时的软件系统交付，同时又得到成长。
现实中，一个开发团队中的程序员容易被指定承担技术主管的角色，但的程序员又很容易陷入到实现功能的细节中，满足于完实现，优雅简洁的代码。 实际上，这样的程序员转入技术主管这个角色后，就很容易尝试控制设计和代码的实现，他们很难接受代码不按照他们希望的方式去编写，这个是他们作为程序员一直以来的工作习惯，长此以往他们自身很容易变成整个开发团队的瓶颈，而团队里的其他成员却未能得到足够的锻炼和成长。
所以技术主管实际相比团队里的其他程序员对系统的视角更开阔，以更有策略和长远的方式来考虑问题。他们即使拥有比团队里所有其他程序员更高超的开发实现技能，对所有开发任务拥有强大的实现自信，也需要转变为另一种「借助他人使之实现」的能力和自信，因为技术主管是一个承担更广泛责任的角色，必然导致能够专注有效编码的时间会相比以前减少很多，而这一点正是程序员转变为技术主管的所面临的大挑战之一。
架构师是什么？
看完上面关于技术主管的职责能力要求，想必你会有些疑惑，感觉好像很多条目对架构师也是这么要求的。对，你的感觉没错，技术主管的角色与架构师这一角色会产生一些职责上的重叠，事实上我自己认为在团队规模比较小的时候（10 多人的规模），架构师和技术主管的职责几乎完全重叠，甚至技术主管还会代理一些团队主管的角色。
和技术主管一样，架构师也是一个在业界拥有的称谓，但在绝大部分公司却不属于一个职位序列。许多公司都很纠结于如何定义架构师的角色，以及架构师所做的工作。以前听阿里同学说 P7 属于架构师职位，不过近在看另一个阿里同学写的文章说：“前几年是有专职的「架构师」职位的，现在已经回归到「工程师」、「技术专家」、「研究员」这样的纯技术职位。”可见在一线互联网公司关于架构师的定义也是很模糊的。
但正因为业界和公司对架构师这个角色的职责定义很模糊，所以很多经验积累到一定程度的程序员，并且在公司内被提升到一定高度的技术级别后，都会冠以架构师之名。但实际情况是大部分刚刚冠以架构师之名的程序员，其能力模型大部分停留在上图中的蓝色区域，而对其他区域并未有过系统性的认识和训练。
看过了架构师的能力模型，我们再来试着分析下对应的职责。随着软件系统复杂度和规模的提升，团队也相应变大，那么一个架构师此时所处的职责位置就开始和技术主管区别开来，除了技术主管的技术职责之外，架构师还需要站在更高的纬度去做关于软件系统的抽象和封装。如果技术主管的抽象和封装层次更多考虑的是语言函数、设计模式、代码结构等这一类的事务，那么架构师是站在整体软件系统高度，考虑不同子系统之间的交互关系、技术的合理性、需求的完整性、未来的演进可能性，技术体系发展与组织、产品商业诉求的匹配度。
这是相对技术主管更高纬度的全局视角，另一方面依然有很多技术主管可能感觉没把握的技术决策和技术争端需要架构师的介入协调。之所以要找架构师来对一些技术 争端和方案进行决策判断，很多情况在于程序员对架构师在技术领域内专业力和影响力的信任，而建立这种专业力和影响力是实际构建架构师非领导力的来源。
这里提到一个「非领导力」，这是什么？非是相对而言，管理者的领导力来自于公司正式任命的职位和职权，而架构师在大部分公司基本连职位职责都没定义清楚，更没有职权一说，所以实际上就不会有任何领导力。所以，架构师要发挥更大的作用和价值就需要去构建自己的非领导力，而这需要长期的专业力和影响力积累。
另一方面，架构师的组织职责除了技术主管承担的之外，架构师还承担着在技术团队和非技术团队（例如：产品设计等团队）之间的接口作用，明确产品的边界，勾勒技术蓝图，协调不同技能的技术团队协作，完成终的软件系统交付。这时架构师的角色就像服务化架构中的 API，定义了协作规范、交互协议和方式，但并不会聚焦在具体的实现上。
在更大规模的系统上，架构师似乎还要去涉猎更多的跨领域知识，否则很可能无法做出适合的技术决策。但人终究是有局限的，你不可能学完所有领域，所以特定的领域又会涌现一些垂直领域的架构师。比如：数据架构师、网络架构师、业务架构师、安全架构师。因而某一个领域背景出身的架构师，他对其他领域也只能做个初步了解，当需要作出关于涉及其他领域的架构决策时，他就需要和其他领域的垂直架构师做深度的沟通交流，以辅助决策判断。
从一开始，我就提到技术主管和架构师是程序员自然成长路上的两条支路，始终停留在上面「出色程序员」能力模型域的程序员是无法很好的胜任技术主管和架构师这两个角色。
所以程序员在成长到一定阶段就需要去考虑是否真要往技术主管和架构师的方向发展。而从技术主管走到架构师相对而言更有延续性，但技术主管也会 有另一条路，就是转型走上纯管理岗位，成为一名真正意义上的经理。
一 旦选择走入架构师这条路，基本你就从一名出色的程序员这个领域走出，需要尽快去补充上面能力模型中指出的其他能力。这一点会让刚刚走上这条路的程序员很不适应，因为承担了更多其他职责，就必然要减少在编码实现的时间，慢慢就会怀疑自己的编码能力会退化，也跟不上一线新的技术栈，各种酷酷的新工具。
舍得，舍得，没有舍就没有得。成为架构师会拥有一个更立体的知识、技能矩阵，这是你的得。获得了一个面，在某些点上必然面临被超越的结局。如果成为一名架构师好几年后，你居然还是团队里面编码多，编程能力强的人，其实这是一个失败的架构师，在教练和指导这个职责上已经完全的失败了。
