程序员“封爵之路”：工程师、架构师和项目经理有何区别？

编者按：CTO、项目经理、软件工程师……各种软件开发相关的职位琳琅满目，很多人并不清楚各个职位之间的共性和差异。需要清楚的是，国内的这些职位其实都是“舶来品”，大多是模仿硅谷技术企业而设立的。本文由外国专家撰写，详细分析了技术人员的职位职责和职业路径。需要注意的是，本文针对的是国外的软件开发行业，与国内环境略有不同。编译自medium原题为Software Roles and Titles的文章，作者 Eric Elliott 。

近来，我注意到在业内对很多与“软件”相关的职位存在很多角色和头衔方面的混淆，即使是公司创始人、招聘经理或者团队建设者都很容易分辨不清。今天我们就来谈一下，软件团队中各种职位的角色和职责分别是什么，以及哪些职位更倾向于涵盖哪些角色。

在深入研究这个问题之前，我想强调的是，每个团队都是独一无二的，某种责任往往会在不同时间段在各个成员间浮动，或由团队的不同成员共同承担。任何人都可以出于各种原因将责任委托给其他人，毕竟每个团队都有自己的运作方式。

如果你的团队不完全符合我接下来的描述，也欢迎交流指正。事实上，我认为确实只有很少一部分团队和特定软件工作者的角色能够与我们即将要探讨的内容完美匹配——相比于特性，这只是一个更倾向于平均化的通用框架。

我将从管理职称开始，按资历由深至浅地分析各种角色。不过开始之前强调一点，永远不要被你的职称所束缚。在我看来，

• 技能比职称重要；

• 持续不断有成果输出比死盯截止日期重要；

• 支持比责备重要；

• 协作比竞争重要；

总之，我喜欢以更高的责任来作为主动性的奖励。如果某位员工有主动的意愿和相应的技能去承担超过他们头衔的责任，我会更愿意去提拔他，这是一个很不错地培养潜力员工的机会。

下面进入正题。软件开发角色包括：

• 工程院士

• CEO

• CTO

• 首席信息官/首席数字官/首席创新官

• 工程副总裁/工程总监

• 首席架构师

• 软件架构师

• 工程项目经理/项目经理

• 技术主管/工程主管/团队负责人

• 首席软件工程师

• 高级软件工程师/高级软件开发人员

• 软件工程师

• 软件开发师

• 初级软件开发人员

• 实习软件开发人员

• 我们还将讨论这些角色与其他角色的关系，包括：

• 产品管理副总裁/产品负责人

• 产品经理

• 营销副总裁

注意：有时也会有“主管”或“总监”等头衔用来表示介于技术管理人员和“首席”之间的中层管理人员。 通常，“首席（Chief）”头衔表示一套比较高级的职称，高级管理人员通常会直接向首席执行官报告。 在非常大的公司中，“主管”或“总监”通常扮演着与高层管理人员类似的角色，区别在于他们是向相当于大公司中一个较小的业务单元的负责人（类似于这个单元内的CEO）进行汇报。不同的业务部门有时像独立的公司一样运营，完成自己部分的独立会计工作，拥有自己部门专门的财务人员等。不同的业务部门也可以有副总裁，商务运营部的工程副总裁”。

工程院士

“院士”是软件工程师成就的巅峰之作，它通常是为了表彰那些为计算机领域做出杰出贡献的人而颁发的，并且通常在工程师撰写一些畅销书籍，获得图灵奖，诺贝尔奖等奖项后颁发。换句话说，院士通常在组织外已经很有名，此时公司试图通过更有影响力的、值得敬仰的人来强化自身的品牌。

在我看来，组织不应该试图聘请“院士”角色。相反，我认为应该去找到最好和最合适的人，雇用他们。如果工程师具有相应能力，再授予这份头衔作为荣誉和奖励。

一位工程院士通常还会在公司担任另一个头衔。通常是CTO、架构师、工程副总裁等。他们能够领导、指导或作为组织其他成员的榜样和灵感。

CEO

首席执行官是组织中最具有权威的职位。通常情况下，他们为公司设定了愿景和目标。围绕着对于公司使命、战略和核心价值观的共识，CEO将每一位员工团结在一起。

一般来说CEO也是公司的公众形象，在某些情况下，还会成为品牌的代名词（例如，Steve Jobs与Apple，Elon Musk与Tesla / SpaceX等）

在某些情况下，首席执行官也是软件组织的技术创始人，在这种情况下，他们也经常担任CTO角色，并可能拥有运营，销售，战略和营销副总裁，帮助解决其他一些常见的CEO职责。当然，一家小公司的首席执行官经常顶着很多其他的头衔。

无论如何，如果要做出重要的组织决策，责任的核心就在于CEO。

如果你是首席执行官，请记住：你最终要对自己负责。虽然你应该相信自己的直觉，但不要忘记，即使是大多数有名的CEO都会有定期咨询的导师和顾问。因此，相信直觉的同时，也要寻找聪明、有见地的人来帮你寻求进步。

CTO

与CEO角色一样，CTO角色随着时间的推移而变化。在年轻的创业公司，CTO通常是有远见或领域驱动的CEO的技术联合创始人。他们通常还不具备在一家大公司获得高级头衔的资格，希望随着公司的发展而成长。通常，创业公司首席技术官更喜欢更多技术工程师的角色，并同时兼任其他角色，如首席工程师，工程副总裁或首席架构师。

在许多组织中，成熟的CTO角色是面向外部的。他们参加业务发展会议，经常帮助建立大型合作伙伴关系或推广销售业务。他们中的许多人都会出席很多会议，花费很多时间将组织的发展活动传播到更广阔的世界：分享公司的创新，发现市场中与公司核心竞争力相匹配的机会。CTO经常与产品团队在产品战略上密切合作，并且通常会担任工程方面面向内部的对应职位，例如工程副总裁。CTO还经常设定工程团队的愿景和目标。

首席信息官/首席数字官/首席创新官

首席创新官（CIO）跟CTO很类似，但通常由一家通常不被视为“科技公司”的公司雇用。首席信息官的目标是将公司重塑为消费者认为精通技术和创新的公司：向世界展示行业的未来。例如，家庭改造超市连锁店可能有一位CIO负责与科技公司合作，建立一个混合现实应用程序，向购物者展示他们在客厅中特定的沙发或墙壁颜色，或使用区块链和加密货币来增强供应链物流的安全性和效率。

不要把首席创新官（CIO）与首席信息官（CIO）混淆，后者通常用于那些更加脱离技术的公司，或者是只对某项技术感兴趣、抑或是需要某种技术支持的公司。与首席创新官不同，首席信息官更有可能领导技术集成和数据迁移项目，而不是构建新的应用程序。首席信息官的行为更像首席创新官，但在我看来，他们根据不同的职责还是应该使用不同的头衔。

工程副总裁/工程总监

虽然CTO经常面向外部，但工程副总裁往往面向内部。工程副总裁经常负责建立工程团队并建立工程文化和运营。CTO可能会告诉工程团队需要在大规模上完成哪些工作，例如“成为人/计算机互动的领先创新者”。工程副总裁则偏重于帮助培养管理“如何”的文化，最好的工程副总裁善于在无形中帮助团队进行更有效工作。项目过程中，团队中的开发人员协作良好，互相指导，有效沟通，所有人都觉得，“嘿，我们是一个伟大的团队，我们在一起工作非常愉快！”大多数时候，团队成员会认为这份顺畅是一种“幸运的偶然事件”，自然而然就发生了。

事实是，这种情况几乎不会自发地出现。之所以能有这份顺畅，是因为工程副总裁会不断监控团队的进度、流程、文化和沟通基调。他们鼓励开发人员使用某些工具，在特定时间举行特定类型的会议，以便通过更少的中断促进更好的协作。无论是功能失调的团队还是功能强大的团队，最好的工程副总裁是工程师，因为他们了解有效软件开发工作流程的模式和反模式。

他们与产品和产品经理的负责人合作，以确保有一个良好的产品发现过程（他们不会引导它或负责它，只是确保有人在跟进并且做得好）；以及，产品在实施交接之前，工程师会对设计可交付成果进行充分的审查。

许多创业公司规模太小，无法聘请全职工程副总裁，但尽早建立起良好工程工作文化仍然非常重要。

首席架构师

在小型组织中，首席架构师可以成为技术联合创始人。他们不太想承担CTO偏向管理部分的职责。也许他们不喜欢到处出差，又或者是比起会议谈话、业务发展和渗透到许多CTO生活中的销售电话，他们只是单纯对软件设计更感兴趣。 首席架构师可能负责选择技术堆栈，设计计算系统之间的协作和接口，评估计算服务产品（AWS，Azure，ZEIT Now等）等。 首席架构师可以评估各种行业产品，并提供预先批准或赞成的建议，以便与特定供应商合作。

随着公司的成熟，首席架构师可能还需要与CTO密切合作，有时还需要与伙伴组织合作来开发一些集成类的服务。 在许多公司，CTO也担任首席架构师。

软件架构师

软件架构师需要实现首席架构师的许多目标，但通常负责较小的功能横截面。软件架构师经常与首席架构师合作，实施他们对更大建筑愿景的切面。软件架构师经常为特定应用程序或功能选择技术堆栈，而不是在整个公司范围内做出决策。

工程项目经理/工程经理/项目经理

工程项目经理（也称为“工程经理”或简称“项目经理”），负责管理工程团队的工作流程。一些大公司同时拥有工程经理和项目经理。在这种情况下，工程经理通常在本地团队范围内扮演工程副总裁的角色，而项目经理则承担此处所述的职责。

项目经理通常与产品负责人和工程副总裁（如工程副总裁，CTO或中层经理）进行交流，以添加或删减工作细节，跟踪项目流程，完成详细的进度报告等。

最好的项目经理需要花费大量时间对问题和错误进行分类，以便分析每个特征点的错误密度，导致最多错误（设计错误，规范错误，逻辑错误，语法错误，类型错误等）的指标等等。这些指标可用于衡量各种计划的有效性，并指出可以对工程流程进行哪些改进。

工程经理需要充分了解各个团队成员的优势，并善于为相应的责任方分配工作单，但这应该是一项协作工作，寻求个别开发人员对他们的职业目标的反馈和他们想要关注的是，也在项目经理的工作范围内。

如果存在时间压力或工作积压，项目经理应与工程和产品负责人合作，找出根本原因并尽快让项目按计划运行。

理想化的情况下，项目经理应该是唯一直接将任务委派给个别工程师，以避免“多个老板”问题的人。工程师应该清楚地了解他们直接向谁报告，以及谁负责委派工作给他们。如果你是一名不同类型的工程领导者，并且你一般直接委派工作给工程师，那么在你和工程师之间设置一位工程经理来进行协调并通过他们进行工作委派可能是一个好主意。

在非常小的组织中，工程经理通常也是由CTO和副总裁兼任。

一个常见的误区是，由于工程团队与产品团队紧密合作，因此，工程经理会直接向产品经理报告。我看到过很多这样的情况，这是一个错误。下文还会更详细地探讨这个问题。

技术主管/团队负责人

技术主管或团队负责人通常是少数开发人员的领导者。 他们通常是高级工程师，他们的行为就像团队其他成员的导师，范例和指南。 通常，工程师向项目经理或工程经理报告，但技术负责人可能负责团队的代码质量把控，例如确保正在进行充分的代码审查，以及确保团队的技术标准（如TDD）。

工程师职业上升路径

通常，工程师有以下两种职业道路：进入管理层，或继续走技术路线。

管理职位并不适合所有人。很多工程师都喜欢坚持技术道路。这种路径可能会经历多种方向、曲折和转弯，整体看起来像这样：

实习生——初级软件开发人员——软件开发人员/工程师——高级软件工程师——首席软件工程师——软件架构师——高级软件架构师——首席架构师——首席技术官——工程院士

而对于那些对人员领导角色感兴趣的工程师，进展可能看起来像这样：

实习生——初级软件开发人员——软件开发人员/工程师——团队负责人/技术主管——工程经理/项目经理——高级工程经理——工程总监——工程副总裁

避免组织功能失调

IMO，工程副总裁，首席技术官，产品副总裁和营销副总裁都应直接向首席执行官汇报。他们每个人都需要掌控自己这一部分的过程。面向外部的CTO不应该有直接的报告（如果他们这样做，通常意味着他们正在填补CTO和工程角色副总裁）。相反，工程领导者应该向工程副总裁报告，这是为了避免“两个老板”的功能失调，也是因为这些角色根本不同：一个侧重于客户以及让组织更加适应更广阔的世界，一个侧重于内部的日常运营。他们是两种截然不同的技能组合，这些技能在每个人、每个职位上会有相互竞争的优先级。

我曾经看到过很多工程团队的功能失调，就是因为他们混淆了哪些工程领导者应该对哪一块业务负责，而这往往会导致灾难。无论什么样是组织结构是适合你当下公司的，都需要确保责任和权限链清晰，以避免工程师在两个或三个不同的“老板”之间感到挣扎。

同样，在规模足够大的组织中，产品和工程需要由两个独立的团队组成。也就是说，产品经理应该拥有产品路线图，他们应该成为用户的传达者，他们应该真正深入挖掘用户，并深入了解他们的工作流程和痛点。他们应该是市场需求的专家，他们应该非常熟悉公司满足这些需求的优势和能力。

换句话说，工程副总裁（或任何正在充当这一角色的人）需要负责交付和生产节奏。虽然产品经理应该拥有路线图，但工程经理需要负责制定路线图优先级，将其与工程能力相匹配，并报告时间安排。产品和营销团队对于什么时候应该交付有强烈的意见，但只有工程管理层能够根据路线图要求很好地判断这些交付时间表是否可行。工程团队需要的权力不仅仅是缩短时间，而且在大多数情况下，要完全拥有时机，与CEO，产品和营销团队合作以确定优先级，了解公司的战略需求，然后帮助塑造一个可以满足这些需求的开发节奏。

我参与过的最佳表现团队采取了无截止日期的方法。我们在不事先通知的情况下构建出色的产品，然后让营销团队推广已经完成的工作。

或者，当你在相对开放的环境中工作时，透明度是一个很好的解决方案。使用项目管理软件积极分享你的进度，制作图表来清楚地查看工作的进度、速度和剩余范围，以及随时间变化做出相应的调整。就算项目无法按时交付，与项目相关的人也可以亲眼看到实际的进程，阶段性的成果相对容易接受。

目标、产品、营销和工程常常是相互竞争的独立角色，且需要直接向CEO报告。如果你的团队有加班加点的压力、或者最后期限之前匆匆忙忙地交付一些东西，那么肯定是出于这两个原因：要么工程经理正在向错误的人报告，要么团队缺乏强大的工程领导者。一个强大的工程领导者，应该了解软件估算的无效性以及工程和产品之间协作交换的必要性，以确保最小化目标的灵活性。

产品应该拥有持续的发现过程。工程应该拥有持续的交付流程。市场营销应与产品团队携手合作，确保向更广阔的世界传达产品信息。整个事情应该像管道一样融合在一起，创造一个平稳流动、积极的反馈循环。像流水线一样，流程中最慢的瓶颈必须为流程的其余部分设定步伐，否则会导致积压项目不断增加。

产品团队如果感觉到项目进度有问题，则应首先关注项目交接质量。问自己这几个问题：我们做过充分的设计审查吗？工程师是否有机会在交接之前提供建设性的反馈？ 80％的软件错误是由规范或UX设计错误引起的，其中许多错误可以在项目交给工程团队之前捕获。如果已经对该过程进行了精细调整，就要问问自己是否对产品进行了足够充分的设计，包括这些问题：是否构建了一个UX并将其调用完成，或者尝试了多种变体（构建和测试用户工作流程的变体是产品团队可以做出的最有价值的贡献之一）？是否拥有一组可信赖的用户来进行A / B测试？

软件团队最大的功能障碍之一，就是产品团队生产低于标准的可交付成果（有时只是一些匆忙的、有缺陷的模型），并且在交付之前未能交由客户或工程师测试。这种功能障碍导致了工作团队的重复工作和工程积压，这往往归咎于工程团队。

良好的开发团队必须确保责任分配有意义，不给工程施加不必要的时间压力，并且有一个优秀的产品团队参与产品开发过程，并与真实用户进行合作。

如果一个开发团队存在这些功能障碍，那么项目经理有责任通过产品、营销和业务领导来解决这些问题，并提出工程交接的要求。保护团队的高效节奏也是项目经理的责任，如果团队压力大，项目经理要寻找额外的资源，清楚地报告工作节奏和项目积压情况，演示已完成的工作，并确保团队做的事情被老板赏识。

原文链接： https://medium.com/javascript-scene/software-roles-and-titles-e3f0b69c410c

编译组出品。