什么是技术项目经理？

什么是技术项目经理 (TPM)？ 经验丰富的 IT 顾问和业务运营专家安迪布莱克威尔说，答案取决于你问谁。 作为 Toptal 的项目和产品管理首席总监，Blackwell 领导的团队负责将 Toptal 的自由职业者网络中的高技能项目经理与为特定计划寻求顶尖人才的组织进行匹配。 近年来，她看到对 TPM 的需求激增。

“整个科技行业对于这个词的实际含义肯定存在一些争论，”布莱克威尔说。 “有很多人称自己为技术项目经理，因为他们与工程团队密切合作，或者从项目管理的角度领导技术团队，但这不是我们想要的。”

Toptal 的定义更为具体。 Toptal 网络中的所有项目经理都是传统项目管理技能的专家，例如范围界定、预算和管理时间表，以及与迭代交付和持续改进相关的敏捷软件开发实践。 他们总是与工程师密切合作，如果需要，他们可以指导和指导 Scrum 团队。

然而，为了获得 TPM 的资格，除了管理敏捷流程和与开发人员合作之外，他们还必须具备额外的经验：他们自己必须是开发人员。

珍贵的组合

大大小小的组织对这种特殊的技能组合越来越感兴趣。 “大多数初创公司不能雇用一个只会做一件事的人，”布莱克威尔说，如果他们正在为一个工程项目招聘，较大的企业希望在候选人的个人资料中看到“开发人员”或“架构师”。

即使在客户没有特别要求具有技术背景的项目经理的情况下，选中“开发人员”框也是一个主要卖点。 可以计划和执行软件项目、实施和优化敏捷流程和代码的人？ 这是一个巨大的福音。

然而，实际上，TPM 并不期望编码——许多人已经多年没有编码了。 那么，为什么需要编程经验呢？

需要 TPM 来做出技术决策，Blackwell 说：“如果您至少没有一些相对较新的现代技术堆栈、SDK（软件开发工具包）、架构或测试自动化平台的实践经验，那么您”可能不会做出正确的决定。 你不会得到客户的信任，因为你以前没有使用过这些东西。”

与团队合作

向潜在客户展示可信度是确保参与的重要因素，但这只是第一个障碍。 一旦分配给一个项目，TPM 必须迅速赢得技术团队的信任和尊重。

Michael Poythress 十几岁时就开始编程。 16 岁时，他为与父亲一起创办的房地产广告业务建立了一个商业网站。 从那以后，他一直是多家初创公司的首席执行官和创始人。 2018 年，他作为 TPM 加入 Toptal 网络，现在与工程团队密切合作。 “如果我没有编码经验，程序员会接受的，”他说。 “他们不会直接对我开枪。 但如果我挑战他们并作为同龄人与他们交谈，就会有尊重和融洽的关系。”

技术经验比头衔更重要，加利福尼亚州奥兰治县 Toptal TPM 的 Allen Takatsuka 说：“据我所见，TPM 中的‘T’对工程师来说并没有任何意义。 他们认为只是另一个项目经理会安排他们的会议并要求他们填写电子表格。”

然而，一旦建立了共同点，“互动的味道就会大不相同。 这更像是与工程的合作，”他说。

高冢在其职业生涯的早期花费了数十年时间领导工程团队。 他认为这段经历提升了他的软技能。 “这是一种不同的同理心技能，”他说。 “你必须证明你会说这种语言。 你可以说，'我明白为什么你会根据正在发生的技术问题而面临这些挑战。'”

来自弗吉尼亚州维也纳的技术顾问 Dan Allen 将他的职业发展描述为“从小隔间程序员到技术主管，再到架构师、总监、副总裁、首席技术官、首席信息官”。 自 2019 年作为 TPM 加入 Toptal 网络以来，他一直很忙，参与了 14 次客户活动。

“我很少阅读代码。 我几乎从不写代码，”他说。 “但在某些情况下，开发人员会陷入困境。 他们可以引导我了解架构，我可以准确地看到他们想要做什么以及逻辑。”

他发现动态不仅在极端情况下有用，而且在更广泛的情况下有用。 “你的团队知道他们可以来找你谈话，而且你真的理解他们在说什么，”他说。 “你可以帮助他们考虑所有的复杂性，以防他们遗漏了什么。 你可以成为一个共鸣板并提供反馈。”

乘数效应

这种反馈和洞察力比建立关系更重要。 TPM 为组织提供了不同的价值主张。 它们较少用作信息的渠道，而更多地用作知识的来源。 是的，他们计划、协调和沟通，但他们也帮助客户和团队完成复杂的技术决策。

“你有能力在技术上固执己见，”高冢说。 “这为组织增加了价值，因为现在你有了更多的乘数效应，而不仅仅是组织和协作。”

Takatsuka 指出，TPM 必须跳过更少的环节来解决问题。 尤其是在较大的组织中，非技术项目或项目经理可能会通过识别相关参与者和利益相关者、提供背景、汇总信息，然后筛选结果来做出决定来应对技术挑战。 TPM 可以运用他们自己的知识。

“您可以更有效地应对风险，”东京 TPM 的 Oana Ciherean 说。 “而这些风险可能来自很多地方。 它们可能来自团队的错误估计。 所以你可以说，'好吧，我确信这段代码不会花一周时间来写'，因为它真的需要两天时间。 因此，您实际上可以取消阻止人们。 因为你已经发现他们被卡住了，这就是为什么他们需要五天的时间。 你知道这一点，因为你去过那里，你自己也被困住了。”

寻找平衡

Ciherean 的职业生涯始于开发人员，但出于参与大局的愿望，她很快进入了项目管理领域。 然而，在这些角色中，她发现自己错过了编码。 她说，技术项目管理提供了两全其美的优势：“它让我能够真正亲身体验技术，同时也能高水平地了解业务和客户以及他们想要的功能。”

Poythress 也觉得自己找到了最佳位置。 “我是一名翻译，或者是有远见的人与知道如何构建并实现它的技术人才之间的联络人，”他说。 “我能流利地说两种语言。 我说‘正常人’，我说‘技术语言’。”

迷你 CTO

为初创公司和小型企业工作的 TPM 在商业和技术的交叉点上占据着特别重要的位置。 在这些项目中，TPM 通常是项目开始时第一个加入的人。 然后，他或她负责评估产品的可行性，定义技术范围和要求，并帮助客户（有时是一个有想法的创始人）选择技术堆栈，评估供应商的服务交付，实施 DevOps 最佳实践，并组建合适的团队。

Takatsuka 将这些参与视为“迷你 CTO”角色，其中 TPM 将业务和技术领域联系起来，以使事情顺利进行。 一些客户对开发软件几乎一无所知，他说：“我如何开店？ 我读过关于敏捷的文章。 我怎么做？”

Poythress 认为这两个角色是重叠的，在某些情况下甚至无法区分。 “有很多异花授粉，”他说。 “小型组织的 CTO 可以很容易地进入大型组织的高级技术 PM 角色，并感到宾至如归。”

启用敏捷性

尽管几乎所有具有软件开发经验的项目经理都掌握敏捷的机制，但具有技术才能的人可以为管理流程带来更细致入微的视角。

Ciherean 发现本书从未严格实施敏捷方法。 它们必须针对团队和项目的特定需求进行定制、混合和调整。

“你必须确保你所设计的流程不会干扰开发人员的工作，并且实际上会提高效率或生产力，”她说。 “有时这意味着深入了解 GitHub 工作流程，例如，了解他们如何进行提交，了解他们如何为代码创建分支，以及了解您的流程是否适合他们的工作流程。 然后你要么纠正你的流程，要么纠正他们的工作流程。”

TPM 的专业知识还可以为特定的敏捷工件和实践提供信息，例如产品积压和相对大小估计。

“如果你了解技术，你就会知道待办事项的大致复杂性，”高冢说。 “否则，你只有这份清单，你很难知道第一件是不是比第二件大的 T 恤。 您可能认为一个更难，但您并不真正知道幕后是什么。 他说，一个“极端”的 TPM “可以自己调整大小，但需要注意的是，当团队加入时，他们将拥有自己的速度。”

Poythress 使用他对尺寸估计的理解作为衡量他为项目考虑的技术主管和工程师的标准。 如果他期望某件事是一项小任务，但其他人认为它是巨大的，那就是一个危险信号：“我会听取他们的意见，看看是否有我不知道的复杂性，但如果这不成立，我想，'好吧，好吧，那不合适。 我们需要一个非常了解这一点并且不会被应该是一个简单的功能吓倒的人。”

TPM 还有助于向客户介绍非功能性需求。 如何处理高可用性？ 您如何处理灾难恢复？ “没有技术上的理解，我不知道你们是怎么讨论的，”高冢说。 “你可能会停留在 Scrum 需求级别，直到技术人员出现为止。 好吧，那么你就有了这个巨大的鸿沟。”

保持最新

尽管他们在键盘上的时间在他们今天的工作中发挥着重要作用，但 TPM 不能依靠过去的经验来保持相关性。 鉴于技术变化和发展的速度，很容易落后。

Poythress 在加入 Toptal 之前的 5 年窗口期中学到了这一点，当时他完全专注于经营自己的公司。 “我肯定停滞不前，”他说。 “在那段时间里，出现了许多不同的语言并解决了我一无所知的问题，因为我们拥有我们的技术堆栈，而这正是我们所需要的。”

如今，他将多达 10% 的时间用于阅读文档、观看 YouTube 和沙盒，以“了解最新和最伟大的事物”。

“我几乎总是涉足一种新的语言或技术，这样我才能保持敏锐，”他说。 “因为如果我不这样做，这个行业就会继续发展。 我以前也有过这种情况。 而且，补习比保持最新要难得多。”

高冢还积极填补自己的知识空白：“如今，谷歌很棒。 YouTube 很棒。 你必须做你的功课。 但这项工作是建立在自身之上的。”

他还依靠广泛的顾问同事网络提供支持和知识共享。 “我遇到过客户想要使用 Google 的情况，但我碰巧更了解 AWS 平台，”他说。 “我可以打电话给朋友说，‘嘿，我们将使用 Firebase。 你有没有这样做的客户？ 可扩展性怎么样？

即使在企业工作了 30 多年并担任过多个高管级别的职务后，Dan Allen 也不怕弄脏自己的手。 在过去的三年里，他自学了在亚马逊和谷歌云上单枪匹马的部署。 “我这样做是为了理解它并帮助一个 Toptal 客户，”他说。 “他们没有技术团队。 他们只有我。 所以我去了 YouTube 大学并完成了它。”

自 1985 年 Allen 开始担任开发人员以来，情况发生了很大变化。但他乐于迎接每一个新机会带来的挑战。 “这是我热爱这份工作的一部分，”他说。 “总有一些你没有做过的事情，一些新的事情。 而且你总是带着额外的羽毛离开，你可以在下一次参与时加以利用。”