【软件】软件角色和职称

我注意到业界对各种软件角色和头衔有很多困惑，甚至在创始人、招聘经理和团队建设者之间也是如此。软件团队的各种角色和职责是什么，哪些职位往往涵盖哪些角色？
在我深入探讨这一点之前，我想强调每个团队都是独一无二的，职责往往会在团队的不同成员之间浮动或分担。任何人在任何时候都可以出于各种原因将责任委托给其他人。
如果您的团队与我在这里描述的不完全一样，欢迎加入俱乐部。我怀疑很少有团队和特定的软件角色会与我们即将探索的内容完美匹配。这只是一个通用框架，它比任何特定角色或团队更能描述平均值。
我将从管理头衔开始，大致按资历来担任各种角色。
我还想强调，你不应该被你的职位束缚。我喜欢建立一种有利于：

• 技能胜于头衔
• 在最后期限内持续交付
• 支持胜过责备
• 合作胜于竞争

我喜欢用更多的责任来奖励主动性，如果有人有能力和主动性来承担和超越他们被聘用的头衔，我喜欢提升而不是冒险失去一颗冉冉升起的新星给另一家公司或团队。

软件开发角色

• 工程研究员
• 首席执行官
• 首席技术官
• CIO/首席数字官/首席创新官
• 工程副总裁/工程总监
• 首席架构师
• 软件架构师
• 工程项目经理/工程经理
• 技术主管/工程主管/团队主管
• 首席软件工程师
• 高级软件工程师/高级软件开发人员
• 软件工程师
• 软件开发人员
• 初级软件开发人员
• 实习软件开发人员

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

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

注意：有时“主管”或“主管”头衔表示技术经理和 C-Suite 之间的中层经理。通常，“首席”头衔表示最高管理层的头衔。 C-suite 员工通常直接向 CEO 汇报，并且在他们领导的组织中可能有许多报告。在非常大的公司中，这些替代头衔通常担任与最高层主管类似的角色，但向实际上是较大组织中较小业务部门的首席执行官的人报告。不同的业务部门有时就像是独立的公司一样运作，拥有自己独立的会计、财务人员等。不同的业务部门也可以有副总裁，例如“工程副总裁，商户运营”。

工程研究员(Engineering Fellow)

“Fellow”这个头衔是软件工程师成就的顶峰。它通常是为表彰在计算领域做出杰出贡献的人而颁发的，通常是在工程师写了多本畅销书、获得图灵奖、诺贝尔奖等奖项后颁发的。换句话说, 研究员通常已经在组织之外很有名气，公司正试图通过与受人尊敬和有影响力的人更紧密地联系来加强他们的品牌。
在我看来，组织不应该尝试招聘“同事”角色。相反，找到最优秀、最聪明的人，雇用他们，然后授予工程师应得的头衔（和福利）。
研究员通常还拥有公司的另一个头衔。通常是首席技术官、架构师、工程副总裁或主要角色，他们可以领导、指导或作为组织其他成员的榜样和灵感。

首席执行官

CEO是组织中最权威的职位。通常，他们为公司设定愿景和北极星。他们围绕对公司存在的原因、使命是什么以及公司的价值观是什么的共同理解团结大家。 CEO 通常也是公司的公众形象，在某些情况下，成为品牌的代名词（例如，苹果公司的史蒂夫乔布斯、特斯拉/SpaceX 的埃隆马斯克等）
在某些情况下，CEO 也是软件组织的技术创始人，在这种情况下，他们还经常担任 CTO 角色，并且可能有运营、销售、战略和营销副总裁帮助执行其他一些常见的 CEO 职责.
一家小公司的 CEO 经常身兼数职，因为当我提到一些 CEO 领导技术团队时，你可能已经从 CEO 头衔之外的所有其他角色中学习了。
无论如何，如果要做出重要的组织决策，您不能将其运行在比 CEO 更高的责任链上。
如果您是 CEO，请记住您最终要负责，并且您应该相信自己的直觉，但不要忘记，即使是大多数著名的 CEO，也有他们定期咨询的导师和顾问。相信你的直觉，但也要寻找聪明、有见地的人来挑战你的进步。

首席技术官

与 CEO 的角色一样，CTO 的角色也会随着时间而改变。在年轻的初创公司中，CTO 通常是有远见或领域驱动型 CEO 的技术联合创始人。他们通常没有资格在更大的公司获得头衔，并希望随着公司的发展而成长。通常，初创公司的 CTO 发现他们更喜欢技术工程职位，然后重新回到其他职位，如首席工程师、工程副总裁或首席架构师。
在许多组织中，成熟的 CTO 角色是面向外部的。他们参加业务发展会议，经常帮助建立大型合作伙伴关系或销售。他们中的许多人参加了会议并花费大量时间向更广阔的世界宣传组织的发展活动：分享公司的创新并发现与公司核心竞争力相匹配的市场机会。 CTO 经常与产品团队在产品战略上密切合作，并且通常在工程方面有一个面向内部的对应方，例如工程副总裁。
CTO 还经常设定工程团队的愿景和北极星。团队要努力实现的目标。

CIO/首席数字官/首席创新官

首席创新官 (CIO) 类似于 CTO，但通常受雇于通常不被视为“科技公司”的公司。首席信息官的目标是将公司重塑为消费者认为精通技术和创新的公司：向世界展示该行业的未来，无论该行业是什么。例如，一家家居装修连锁超市可能有一名首席信息官负责与科技公司合作构建一个混合现实应用程序，向购物者展示他们客厅中特定沙发或墙壁颜色的样子，或者使用区块链和加密货币来增强供应链物流的安全性和效率。
不要与首席信息官 (CIO) 混淆，该头衔通常用于那些更加脱离技术、对技术有助于其核心运营感兴趣的公司。与首席创新官不同，首席信息官更有可能领导技术集成和数据迁移项目，而不是构建新应用程序并试图弄清楚公司如何从内部颠覆自己。有些首席信息官更像首席创新官，但在我看来，他们应该使用适当的头衔。
大多数技术原生公司（应用程序开发人员等）都没有任何一种 CIO。相反，这些责任落在了首席技术官和工程副总裁身上。

工程副总裁/工程总监

虽然 CTO 经常面朝外，但工程副总裁经常面朝内。工程副总裁经常负责组建工程团队并建立工程文化和运营。 CTO 可能会告诉工程团队需要大规模完成什么，例如，“成为人机交互领域的领先创新者”。工程副总裁有助于培养一种管理“如何”的文化。最优秀的工程副总裁起初会被认为是帮助团队高效工作的人，然后他们几乎消失了。团队中的开发人员协作良好，互相指导，有效沟通，他们认为，“嘿，我们是一个很棒的团队。我们合作得非常好！”也许他们认为这都是一个幸运的意外。
事实是，这几乎不会偶然发生。之所以会这样，是因为有一位工程副总裁不断监控团队的进度、流程、文化和沟通基调。他们鼓励开发人员使用某些工具，在特定时间举行特定类型的会议，以促进更好的协作，减少中断。最好的工程副总裁是工程师，无论是在功能失调的团队中，还是在功能强大的团队中。他们知道有效的软件开发工作流程的模式和反模式。
他们与产品和产品经理的负责人合作，以确保有一个良好的产品发现过程（他们不领导或负责它，只是确保有人在它上面并且做得很好），并且那个产品和在交付实施之前，工程师对设计交付物进行了充分审查。在我写一本关于领导有效开发运营的所有工作的书之前，我将就此打住。有关我对这个主题的更多想法，请查看如何建立高速开发团队。
许多初创公司规模太小，无法聘请全职的工程副总裁，但尽早建立正确的工程文化仍然非常重要。如果您需要这方面的帮助，请联系。

首席架构师

在小型组织中，首席架构师可能是具有自我意识的技术联合创始人，他们意识到随着公司的发展，他们不会想要 CTO 的职责。也许他们不喜欢旅行，或者只是对软件设计比渗透到许多 CTO 生活中的会议会谈、业务开发和销售电话更感兴趣。首席架构师可能负责选择技术堆栈、设计计算系统之间的协作和接口、评估计算服务产品（AWS、Azure、ZEIT Now 等）等等。首席架构师可以评估广泛的行业产品，并提出预先批准或偏爱的建议以与特定供应商合作。
随着公司的成熟，首席架构师可能还需要与 CTO 密切合作，有时还需要与合作伙伴组织开发服务之间的集成。在许多公司，CTO 还担任首席架构师。

软件架构师

软件架构师服务于首席架构师的许多目的，但通常负责较小的功能横截面。架构师通常会与首席架构师合作，以实现他们在更大的架构愿景中的一部分。软件架构师经常为特定的应用程序或功能做出技术堆栈选择，而不是公司范围内的决策。

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

工程项目经理（也称为“工程经理”或简称“项目经理”）负责管理工程团队的工作流程。一些较大的公司同时拥有工程经理和项目经理。在这种情况下，工程经理通常在本地团队范围内充当工程副总裁，而项目经理则承担此处描述的职责。
项目经理通常与产品负责人和工程负责人（如工程副总裁、CTO 或中层经理）进行交流，以培养和修剪工作积压、跟踪工作票的进度、详细的进度报告（里程碑燃尽图、已完成与打开工单、月/月进度报告等）您可以将它们视为制造流水线的车间经理的类比。他们观察工作车间，确保装配线顺利运行，工作产品不会堆积在瓶颈前面的地板上。

最好的项目经理还会花费大量时间对问题和错误进行分类，以分析每个特征点的错误密度、导致最多错误的原因（设计错误、规范错误、逻辑错误、语法错误、类型错误等）等指标。等等。这些指标可用于衡量各种计划的有效性，并指出可以对工程过程进行改进的地方。
工程经理倾向于深入了解各个团队成员的优势，并善于将工作票分配给适当的责任方，尽管这应该是一种协作努力，寻求个人开发人员关于他们的职业目标的反馈，以及在可用的项目范围内，他们想要关注什么。

如果有时间压力或工作积压堆积，项目经理应与工程和产品负责人合作，找出根本原因并尽快纠正功能障碍。
在可能的情况下，项目经理应该是唯一直接将任务委派给单个工程师的人，以避免多个老板的问题。工程师应该清楚地知道他们直接向谁报告，以及谁负责委派给他们。如果您是不同类型的工程领导，并且您因直接委托给工程师而感到内疚，那么与负责您委托的报告的工程经理协调并通过他们进行委托可能是一个好主意，以便工作得到正确、协调的优先级，工程经理知道每个工程师在任何特定时刻都在积极从事什么工作。

在非常小的组织中，工程经理通常也是工程的首席技术官和副总裁（有或没有相应的头衔）。如果那是您，请不要担心上一段。
一个常见的功能障碍是，工程经理可能会开始认为，由于产品将工作交给工程实施，并且工程经理与产品团队密切合作，因此工程经理向产品经理报告。在我看到的每一种情况下，这是一个错误。请参阅下面的“避免功能障碍……”。

技术负责人/团队负责人

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

工程师职业发展

一般来说，工程师可以选择两条职业道路之一：进入管理领域，或者继续编码。管理职位并不适合所有人。许多工程师更愿意继续走技术路线。这种进展可能有许多方向、曲折和转弯，但可能看起来像这样：
实习生 -> 初级软件开发人员 -> 软件开发人员/工程师 -> 高级软件工程师 -> 首席软件工程师 -> 软件架构师 -> 高级软件架构师 -> 首席架构师 -> CTO -> 工程研究员
或者，对于那些对人员领导角色感兴趣的工程师，进展可能看起来像这样：
实习生 -> 初级软件开发人员 -> 软件开发人员/工程师 -> 团队负责人/技术负责人 -> 工程经理/项目经理 -> 高级工程经理 -> 工程总监 -> 工程副总裁

避免工程领导中的功能障碍

IMO、工程副总裁、CTO、产品副总裁和营销副总裁都应直接向 CEO 汇报。他们每个人都需要负责自己的流程。面向外部的 CTO 不应该有直接下属（如果有，通常意味着他们同时担任 CTO 和工程副总裁的角色）。相反，工程领导者向工程副总裁报告。这是为了避免两位老板功能失调，但也因为这些角色根本不同：一个专注于客户以及组织如何适应更广阔的世界，另一个专注于内部的日常运营。它们是两种截然不同的技能组合，有时具有相互竞争的优先级。
我见过很多工程领导的功能失调，因为不清楚哪些工程领导负责什么，这往往是灾难的根源。无论什么适合您的组织，确保职责和权力链是明确的，以避免工程师在两三个不同的“老板”之间感到左​​右为难。

同样，在一个规模足够大的组织中，产品和工程需要由两个单独领导的团队组成。我的意思是产品经理应该拥有产品路线图。他们应该是用户的布道者，他们应该真正融入用户，经常与他们进行一对一的互动，并深入了解他们的工作流程和痛点。他们应该是市场需求方面的专家，并且他们应该非常熟悉公司满足这些需求的优势和能力。
也就是说，工程副总裁（或担任该职位的任何人）需要负责交付和生产速度。虽然产品经理应该拥有路线图，但工程经理需要负责确定路线图的优先级，将它们与工程能力相匹配，并报告时间安排。产品和营销团队对于什么时候应该发货有强烈的意见，但只有工程管理人员才能很好地衡量这些交付时间表是否可能在路线图要求的情况下实现。工程团队需要的不仅仅是推迟时间安排，而且在大多数情况下，需要完全掌握时间安排，与 CEO、产品和营销团队合作确定优先事项，了解公司的战略需求，然后帮助塑造一种可以满足这些需求的开发节奏，而不会强加最后期限，最终损害公司以可靠速度交付优质产品的能力。
我参与过的表现最好的团队都采用无截止日期的方法。我们在不提前宣布的情况下打造出色的产品，然后让营销团队推广已经完成的工作。或者，当您在公众视野中工作时，透明度是一个很好的解决方案。与其为了满足任意期限而死记硬背，而是通过工单燃尽图积极分享您的进度，清楚地了解剩余工作、进度、进度和剩余范围，以及可以指示范围蔓延的随时间变化。当您分享有关正在取得的进展的详细信息，并分享我们无法承诺交付日期，但我们可以与您分享我们所知道的关于我们进展的一切的理念时，人们可以亲眼看到工作和进度。

由于不同的、经常相互竞争的目标，产品、营销和工程需要成为直接向 CEO 汇报的独立角色，而他们都不能互相发号施令。如果您的团队感到加班工作的时间压力，或者在某个截止日期之前急需完成一些关键的交付，这表明这里存在功能障碍。要么是工程经理向错误的人报告，要么团队缺乏一个强大的工程领导者，他了解软件估算的徒劳无功，以及工程和产品之间需要协作的让步，以确保按比例交付的灵活性- 支持 MVP 以达到交付目标。
产品应该拥有持续的发现过程。工程应该拥有持续交付过程。营销应该与产品团队携手合作，以确保向更广阔的世界传达产品信息。整个事情应该像管道一样组合在一起，创造一个流畅的、积极的反馈循环。就像流水线一样，流程中最慢的瓶颈必须为其余流程设定节奏，否则会导致积压不断增长，堆积得如此之多，以至于积压项目变得过时，积压管理变得全面- 时间工作。

感觉工程跟不上步伐的产品团队应该首先关注工程交付成果的质量。我们是否进行了充分的设计审查？工程师是否有机会在交接前提供建设性的反馈？ 80% 的软件错误是由规范或 UX 设计错误引起的，其中许多错误在将工作交给工程团队之前就已经被发现。一旦你对这个过程进行了微调，问问自己你是否真的对产品设计空间进行了足够彻底的探索。您是构建了一个 UX 并称之为完成，还是尝试了多种变体？构建和测试用户工作流程的变体是产品团队可以做出的最有价值的贡献之一。您是否有一组值得信赖的用户或客户可以与之一起运行 A/B 原型测试？
软件团队最大的功能障碍之一是产品团队正在生产低于标准的可交付成果（有时只不过是一些匆忙的、有缺陷的模型），并且在交付之前未能由客户或工程师运行任何一个.这种功能障碍会导致大量返工和工程积压，这些积压常常被归咎于工程团队。

确保职责的委派是有意义的，你不会对工程施加过度的时间压力，并且你有一个优秀的产品团队参与协作产品发现过程，与真实用户一起构建最好的产品。
工程经理，我不会让你摆脱困境的。 如果您的团队中存在这些功能障碍，您有责任通过产品、营销和业务领导力解决它们，并带头满足工程交接的要求。 您还有责任保护您的团队的生产进度，如果您的团队被迫生产超出您当前能力的产能，请争取额外的资源，清楚地报告工作进度和积压工作，并演示已完成的工作 并确保您的团队因所做的出色工作而获得应有的赞誉。
不要责备，但要证明你的团队正在尽他们最大的努力。