做好互联网公司的角色定位，认清职责才能避免“扯皮”
我注意到，业内对软件开发中的角色和头街存在很多困惑，甚至对创始人、招聘经理和团队建设者来说也是如此。软件开发团队中的各种角色和职责是什么，那些头衔又倾向于涵盖哪些角色呢？
在深入探讨这个问题之前，我想强调的是，每一个团队都是独一无二的，责任往往会在团队的不同成员之间浮动或分担，任何人在任何时候，都可以出于各种原因将责任委托给他人。
我怀疑，很少会有团队和特定的软件开发的角色与我们将要谈到的内容完美匹配。这只是一个总体“框架”，比任何特定的角色、团队通常描述的那些内容都要多。
我将从管理头街开始，然后大致按照资历来划分各种角色。
我还要强调的是，你不应该觉得自己被工作头街束缚了。我喜欢建立这样的一种工程文化，它有利于形成以下理念：
技能比头街更重要
持续交付比最后期限更重要
支持比责备更重要
合作比竞争更重要
我喜欢用更多的责任来奖励主动性，如果有人具备技能，并且也有主动性去接受并超越他们被聘用的头街，我很乐意提拔这种人，而不是冒着将一颗冉冉升起的新星丢给另一家公司或团队的风险。
工程研究员-CEO-CTO-CIO / 首席数字官 / 首席创新官
工程副总裁 / 工程总监
首席架构师
软件架构师
工程项目经理 / 工程经理
技术主管 / 工程主管 / 团队主管
首席软件工程师
高级软件工程师 / 高级软件开发工程师
软件工程师
软件开发工程师
初级软件工程师
实习软件开发人员
我们还将讨论这些角色与其他角色之间的关系，包括：
产品管理副总裁 / 产品主管
产品经理
市场营销副总裁
注：有时候“主管”或“负责人”头街指的是介于技术经理和高管层之间的中层管理人员。通常，“首席”头街表示高管头街。高管层通常直接向 CEO 汇报，并且在他们领导的组织中可能有许多汇报。在非常大的公司中，这些候补职位通常扮演与高管层类似的角色，但实际上是向大型组织中较小业务部门的 CEO 汇报。不同的业务部门有时像独立的公司一样运营，有各自独立的会计、财务人员等。不同的业务部门也可以有副总裁，例如“工程副总裁、商业运营”。
“研究员”这个头街，代表了软件工程师的最高成就。它通常是为了表彰那些为计算机领域做出杰出贡献的人而授予的，通常是在工程师出版了许多畅销书或获得图灵奖、诺贝尔奖等奖项之后颁发的。换句话说，研究员通常在组织之外就已经很有名了，公司正试图通过与受人敬仰和有影响力的人更紧密地联系来强化自己的品牌。
在我看来，组织不应该试图聘请“研究员”这个角色。相反，找到最优秀、最聪明的人，聘用他们，然后如果工程师名实相副的话，再授予他们“研究员”头街也不迟。
研究员通常在公司中还有另外一个头街，一般是 CTO、架构师、工程副总裁或其他主要角色，他们能够领导、指导或作为组织其他成员的榜样。
CEO 是组织中最权威的职位。通常，他们为公司设定愿景和目标。他们将公司所有人团结起来，共同理解公司为什么存在，公司的使命、价值观是什么。CEO 往往也是公司的公众形象，在某些情况下，还会成为品牌的代名词（例如，Steve Jobs 之于 Apple，Elon Musk 之于 Tesla/SpaceX 等）。
在某些情况下，CEO 也是软件组织的技术创始人，在这种情况下，他们也经常担任 CTO 角色，并可能有运营、销售、战略和营销副总裁来帮助执行其他一些常见的 CEO 职责。
一家小公司的 CEO 经常身兼数职，当我提到一些 CEO 领导技术团队时，你可能已经从所有其他角色中脱颖而出了。
无论如何，如果要做出重要的组织决策，你就不能把责任推到 CEO 之上。
如果你是 CEO，请记住你最终是要负责任的，你应该要相信自己的直觉，但不要忘记，即使是最著名的 CEO ，也有他们定期咨询的导师和顾问。要相信你的勇气，但也要寻找聪明、有见地的人来挑战你，让你得到提升。
与 CEO 的角色一样，CTO 的角色也会随着时间的推移而变化。在年轻的初创公司中，CTO 通常是 CEO 的技术联合创始人，并且是非常有远见的人。他们往往没有资格在更大的公司担任这一职位，因此他们希望随着公司的发展而成长。初创公司的 CTO 会发现他们更喜欢的是技术工程角色，并重新回归其他角色，比如首席工程师、工程副总裁或首席架构师等。
在许多组织中，成熟的 CTO 角色是面向外界的。他们参加业务发展会议，经常帮助达成大型合作或销售协议。他们中许多人都参加了会议，花了很多时间将本组织的发展活动宣传到更广泛的世界：分享公司的创新，发现符合公司核心竞争力的市场机遇。CTO 经常与产品团队在产品战略上密切合作，并且在工程方面经常有一个面向内部的对应人员，例如工程副总裁。
CTO 也经常制定工程团队的愿景及团队工作的目标。
首席创新官（CIO）就像 CTO，但一般受雇于通常不会被视为“科技公司”的公司。CIO 的目标是将公司重塑为消费者认为精通技术和创新的公司：向世界展示行业的未来，无论该行业是什么。例如，一家家居改造超市连锁店可能会有一名 CIO 负责与科技公司合作，构建一款混合现实应用程序，向购物者展示他们在客厅中特定的沙发或墙壁颜色，或者使用区块链和加密货币来提高供应链物流的安全性和效率。
不要与首席信息官（CIO）混淆，后者通常用于那些更与技术脱节的公司，他们对其核心业务感兴趣。与首席创新官不同的是，首席信息官更有可能领导技术集成和数据迁移项目，而不是构建新的应用程序，并试图弄清楚一家公司如何从内部瓦解自己。首席信息官的行为更像首席创新官，但在我看来，他们应该使用适当的头街。
大多数技术原生公司（应用程序开发人员等）都没有任何一种 CIO。相反，这些职责属于首席技术官和工程副总裁。
虽然 CTO 经常面向外界，但工程副总裁往往面向内部。工程副总裁经常要负责工程文化和运营。CTO 可能会告诉工程团队在大范围内需要做什么。比如：“成为人机相互作用的领先创新者”。工程副总裁帮助培养管理“如何”（how）的文化。最好的工程副总裁最初是作为帮助团队高效工作的人，然后他们就几乎消失了。团队中的开发人员协作良好，互相指导，有效沟通。他们认为：“嘿，我们是一个伟大的团队。我们在一起工作很棒！”也许他们都认为这都是一个幸运的意外。
事实是，这种情况几乎从来都不是偶然发生的。之所以出现这种情况，是因为工程副总裁会不断监控团队的进度、流程、文化和沟通的基调。他们鼓励开发人员使用某些工具，在特定的时间召开特定的会议，以促进更好的协作，减少中断。无论是功能失调的团队还是功能强大的团队中，最好的工程副总裁都是工程师。他们了解有效软件开发工作流程的模式和反模式。
他们与产品负责人和产品经理合作，以确保有一个良好的产品发现过程（他们并不会领导或者负责，只是确保有人在这个过程中进行工作并且做得很好），并且在实施移交之前，产品和设计可交付成果能够得到工程师的充分审查。
很多初创公司由于规模太小，无法聘请全职工程副总裁，但是，尽早建立正确的工程文化仍然非常重要。
在小型组织中，首席架构师可以是一个技术联合创始人，具有自我意识，意识到随着公司的发展，他们不希望承担 CTO 的职责。也许他们不喜欢出外推销，或者只是对软件设计更感兴趣，而不是那些渗透到许多 CTO 生活中的各种会议、业务开发和销售电话。首席架构师可能会负责技术堆栈的选择、设计计算系统之间的协作和接口，评估计算服务提供产品（如 AWS、Azure、ZEIT Now 等），等等。首席架构师可以评估各种行业产品，并提供预先批准或赞成的建议，以便与特定供应商进行谈判合作。
随着公司的成熟，首席架构师可能还需要与 CTO（有时是合作组织）密切合作来来发服务之间的集成。在许多公司中，CTO 也担任首席架构师的角色。
软件架构师服务于首席架构师的许多目标，但通常负责较小功能的各个部分。架构师通常会与首席架构师合作，实现他们在更大的架构愿景。软件架构师通常为特定的应用程序或特性做出技术堆栈的选择，而不是公司范围的决策。
工程项目经理（也称为“工程经理”或简称“项目经理”）负责管理工程团队的工作流程。一些较大的公司既有工程经理也有项目经理。在这种情况下，工程经理通常在本地团队范围内充当工程副总裁的角色，而项目经理则承担上面所描述的职责。
项目经理通常与产品负责人和工程负责人（如工程副总裁、CTO 或中层经理）进行交流，以培养和清理工作积压，跟踪工作单的进度，详细的进度报告（里程碑燃尽图、已完成和未完成的工作单、每月进度报告等）。你可以把这些想象成制造流水线上的车间经理，他们观察工作现场，确保流水线运行平稳，工作产品不会堆积在瓶颈前面的地板上。
最好的项目经理也会花很多时间对问题和 bug 进行分类，以便分析每个特征点的错误密度，导致最多 bug 的原因（设计错误、规范错误、逻辑错误、语法错误、类型错误等）的指标，诸如此类。这些指标可用于衡量各种计划的有效性，并指出工程过程中可以改进的地方。
工程经理倾向于充分了解各个团队成员的优势，并善于为相应的责任方分配工作单，尽管这应该是一项协作性的工作，在项目范围内，从各个开发人员得到他们对职业目标的反馈，以及他们想关注的是什么。
如果存在时间压力或工作积压，项目经理应与工程和产品负责人合作，找出根本原因并尽快纠正功能障碍。
在可能的情况下，项目经理应该是唯一直接将任务委派给个别工程师的经理，以避免出现多个上司的问题。工程师应该清楚地知晓他们直接向谁汇报以及谁负责委派给他们工作。如果你是一名不同类型的工程负责人，并且你有直接委派给工程师的责任，那么与负责你所委派的工程经理（向你汇报的工程经理）进行协调，并通过他们进行委托可能是一个好主意，这样工作可以得到正确的、协调的优先级，并且工程经理知道每个工程师在任何特定时刻都在积极工作。
在非常小的组织中，工程经理通常也是 CTO 和工程副总裁（有或者没有相应的头街）。如果你是这情况，不用担心上一段说的那些内容。
一个常见的功能障碍是，工程经理可能开始认为，由于产品交付给工程实施，而工程经理与产品团队紧密合作，因此工程经理会向产品经理汇报。在我所见过的所有情况下，这都是一个错误的做法。
技术主管或团队负责人通常是少数开发人员的领导。他们通常是高级工程师，充当团队其他成员的导师、榜样和向导。通常，工程师向项目经理或工程经理汇报，但技术主管可能负责团队的代码质量度量，例如确保进行充分的代码审查，以及维护团队的技术标准（如 TDD）。
一般来说，工程师可以选择以下两条职业道路之一：进入管理层或者继续当码农。但管理职位毕竟并非适合所有人。很多工程师更喜欢走技术路线。这种发展可以有很多方向、并且充满迂回曲折。但看起来可能像下面这样：
实习生 → 初级软件工程师 → 软件开发人员 / 工程师→高级软件工程师 → 首席软件工程师 → 软件架构师 → 高级软件架构师 → 首席架构师 → CTO → 工程研究员。
或者，对于那些对员工领导角色感兴趣的工程师来说，发展路径可能是下面这样的：
实习生 → 初级软件工程师 → 软件开发人员 / 工程师→团队负责人 / 技术主管 → 工程经理 / 项目经理 → 高级工程经理 → 工程总监 → 工程副总裁。
在我看来，工程副总裁、CTO、产品副总裁和市场营销副总裁都应该直接向 CEO 汇报。对外的 CTO 不应该有直接的汇报（如果他们这样做的话，通常意味着他们同时担任 CTO 和工程副总裁的角色）。相反，工程主管向工程副总裁汇报工作。这是为了避免出现两个上司的功能障碍，也是因为这些角色从根本上是不同的：一个侧重于客户和组织如何适应更广阔的世界，另一个侧重于内部的日常运作。他们就是两种截然不同的技能组合，在优先权上有时候存在相互竞争的现象。
我在工程主管中目睹了太多的功能障碍，之所以出现这样的状况，是因为人们不清楚工程主管应该对什么负责，而这往往带来了灾难。无论什么对你的组织来说是正确的，都要确保职责和权力链足够清晰，以避免工程师在两个或三个不同的“老板”之间感到左右为难。
同样，在规模足够大的组织中，产品和工程需要两个独立领导的团队。我的意思是，产品经理应该拥有产品路线图。他们应该成为用户的布道师，真正地融入到用户中，经常与用户全方位接触，并深入了解用户的工作流程和痛点。他们应该是市场需求的专家，并且应该非常熟悉公司满足这些需求的优势和能力。
也就是说，工程副总裁（或者任何担任这一角色的人）需要负责交付和生产进度。虽然产品经理也应该拥有路线图，但工程经理需要负责制定路线图的优先级，将其与工程能力相匹配，并报告时间安排。产品和营销团队对产品何时交付会有很强的意见，但只有工程管理层才能根据路线图的要求很好地判断这些交付时间表是否可行。工程团队需要的权力不仅仅是推迟时间，而是在大多数情况下，要有完全掌握时间的权力。与 CEO、产品和营销团队合作，确定优先级，了解公司的战略需求，然后帮助形成一种开发节奏，既能满足这些需求，又不会强加最终截止时间，因为这样最终会损害公司以可靠的速度交付高质量产品的能力。
我参与过的表现最好的团队，都支持无截止日期的方法。我们在不提前宣布的情况下就能创造出伟大的产品，然后让营销团队推广已完成的工作。或者，当你在公众视野下工作时，透明度就是一个很好的解决方案。不要为了满足一个任意划定的截止日期而死扛，而是要积极地分享你的进度，用 ticket 燃尽图清晰地显示剩余的工作、进度、速度和剩余的范围，以及随时间的推移可能显示范围渐变的变化。当你分享正取得进展的详细信息，分享我们不能承诺交付日期的理念，但是我们可以与你分享我们所知的关于进展的一切，公众可以亲眼目睹我们的工作和进度。
由于目标不同，往往出现相互竞争，产品、营销和工程都是各自独立的角色，直接向 CEO 汇报，没有人能够相互发号施令。如果你的团队感到加班时间的压力，或者在某个截止日期前紧张地拿出一些关键的可交付成果，那么就表明，这里存在一个功能障碍。工程经理要么向错误的人汇报，要么团队缺乏强有力的工程主管，他们了解软件评估的无用性，以及工程和产品之间进行协作的需要，以确保发货的经缩减的最小化可行产品以达到交付目标的灵活性。
产品应该拥有持续的发现过程。工程应拥有持续的交付过程。市场营销应与产品团队携手合作，确保向更广阔的世界传达产品信息是合适宜的。整个事情应该像管道一样连接在一起，创造一个流畅的、积极的反馈循环。像流水线一样，流水线中最慢的瓶颈必须为流程的其余部分设定步伐，否则，会导致积压不断增加，当积压项目变得过时，而积压管理将会成为一项全职工作。
如果产品团队觉得工程设计没有跟上进度，那么他们应该关注工程交付成果的质量。我们是否进行了足够的设计评审？工程师是否有机会提供建设性的反馈？80% 的软件 bug 是由规范或用户体验设计错误引起的，其中许多错误可以在工作移交给工程团队之前就被发现。一旦你对这个过程进行了微调，请扪心自问，你是否真的充分探索了产品设计领域？你是构建了一个用户体验并称其已完成，还是尝试了多种变体呢？构建和测试用户工作流程的变体是产品团队可以做出的最有价值的贡献之一。你是否有一组可信任的用户或客户可以与你一起运行 A/B 原型测试？
软件团队中最大的功能障碍之一是产品团队正在生产低于标准的可交付成果（有时只是一些匆忙交付的、有缺陷的模型），并且在交付之前，客户或工程师都没有运行过其中的任何一个。这种功能障碍会导致大量的重复工作和工程积压，这往往要归咎于工程团队。
确保责任的委派是有意义的，不给工程施加不必要的时间压力，并且有一个优秀的产品团队参与协作产品发现过程中，与真正的用户合作，以构建出最好的产品。
工程经理，我是不会放你一马的。如果你的团队存在这些功能障碍，那么，你就有责任通过产品、营销和业务领导来解决这些问题，并带头提出工程交接的要求。保护团队的生产进度也是你的责任，如果你的团队面临生产超过你目前能力所能承受的压力，那么就去争取额外的资源，清楚地报告工作进度和积压情况，以及演示已完成的工作，并确保你的团队因正为完整出色的工作而获得应有的荣誉。
不要责备你的团队，但要证明你的团队做得很好。