注:没有特别声明,文中的“我”都指原作者 Camille Fournier

管理项目经历

回到我第一次担任技术负责人的时候,我的团队正在执行一项非常复杂的任务:分布式系统迁移。我们一个现成的系统在单机已经到达了它的理论极限。在倾尽所学优化它之后,我们决定是时候弄清楚如何在多台机器上运行它了。

这还是分布式系统萌芽的初期,当时大多数软件开发人员对构建它们的最佳实践知之甚少。但我们有一支优秀的聪明的团队,我们有信心解决这个问题。

我们确实搞定它了,虽然缓慢但毋庸置疑。我们花了很长时间思考、设计和拆分计算。当跨多台机器计算时,这个过程是非常重要的。然后有一天,我的老板迈克把我拉到他的办公室,告诉我:需要制定一个项目计划。

糟糕的体验

这是有史以来最糟糕的经历之一。

我不得不接受这项极其复杂的任务,并试图找出哪些任务依赖于其他任务。我不得不考虑各种依赖关系。我们如何让它在我们复杂的测试框架中运行,我们将如何部署它,我们什么时候采购硬件来测试它,集成测试需要多长时间?问题不断涌来。

我走进迈克的办公室,坐在他对面的大木桌旁。我们会讨论任务细节、时间节点和意外情况。他会帮我解决部分问题,然后把更多的工作分发给我。

这不是我喜欢做的事情。我必须克服不确定性和对犯错误的恐惧,对遗漏的恐惧,以便制定一个能够通过迈克的计划。接着又得进行一轮繁琐的工作,将其整理成某种容易理解的形式,我们可以呈现给领导团队,以便他们认可。

重要的学习经历

敏捷开发不是摆脱了对项目管理的需求吗?

不。敏捷开发是一种拆解工作的好方法,因为它迫使你专注于将任务分解成更小的块,规划这些更小的块,并以增量方式交付而不是一次性交付。

这并不意味着你无需了解如何进行项目管理。

你会有一些项目,无论出于何种原因都无法在一个迭代中完成,甚至无法在两个小迭代中完成。你需要为你的管理团队估算项目时长,并详细说明为什么你认为事情会花费那么长时间。

有一些项目,例如基础设施、平台或系统等,需要架构或重要的高层次规划。当面对这种包含许多未知数和相对严格的截止日期的项目时,你会发现它不太适合标准的敏捷流程。

随着你的职业发展,你需要了解如何分解复杂的工作。这些工作可能超出了你作为个人的能力范围。一个长期运行的、基于团队的项目的管理并不是那么有趣。

为什么项目管理很难

我想写代码并获得直接反馈,而不是考虑如何分解非常模糊的项目实施细节。

我担心我会被追究责任,并且我可能会在这个过程中错过一些重要的事情,这将使项目失败。

项目管理并不等同于每一项工作都被详细计划,它的作用在某些组织中被过度夸大。

我甚至不喜欢招聘项目经理,因为他们经常阻碍工程师,而非思考他们将要做的工作,并就他们在做什么以及为什么要做提出真正的问题。他们的存在意味着你有更多瀑布式项目而不是敏捷过程。

尽管如此,项目管理仍然必须进行,作为技术负责人,你应该在需要时进行管理,尤其是对于技术性很强的项目。

项目管理价值

归根结底,计划的价值不在于你完美地执行计划、事先抓住每一个细节,准确预测未来;而是在项目动手之前,深度思考项目:稍微看远一些,在你能预测和计划的地方找到参考系。计划本身并没有行动重要,无论结果表明计划是多么准确。

回到我的第一个项目管理。

项目是否按计划完美运行?当然不是。有bug、意料之外的延期以及我们没有注意的事情。然而,我们仍然接近约定的时间交付了该项目,并且没有通宵赶版本。

我们设法将这个复杂系统迁移到分布式系统,40名开发人员一起针对主代码分支进行了自己的分支更改。所有这一切都是可能的,因为我们有一支很棒的团队。我们制定了计划。我们已经考虑过成功是什么样子,并确定了一些可能导致失败的风险。

自从与迈克的那次令人沮丧的会议之后,我举行了一系列项目规划会议。我坐在迈克的位置上,而我对面是卡罗、艾丽西亚或蒂姆。他们每个人都感到了计划缺乏细节的挫败感。他们每个人都有去做一些令自己不舒服的工作,去思考那些不是代码、无法完美预测的事情。

由于这项工作,他们每个人都带领复杂的项目取得了成功,并且现在他们了解分解项目的真正含义,从而更有能力构建更大的系统和领导更大的团队。

花时间澄清

取得博士学位的最后一步是答辩。在这个阶段,作为博士候选人,经过多年的研究,你需要在所处领域的专家小组面前展示你的工作结果。他们将判断你的成果是否值得获得博士学位。

多年前,我有幸获得了美国最负盛名的应用数学方向的数学博士学位。小组中的一位评委是数值分析领域的著名数学家。在我(成功地)答辩之后,他对我说的话在我整个工作生涯中伴随着我。他说:“你的论文是我多年来读过的最清晰、最清晰的论文之一。谢谢!”

我当然很欣慰,但也对他的话感到非常惊讶。我原以为他是世界一流的数学家,他会“无所不知”,只用“观察”就知道我的论文质量如何。事实上,正如他所解释的,他能够做到这一点,只是因为我不厌其烦地解释了问题空间的基本思想以及我想法背后的动机。

我一直没有忘记这个教训。从那时起,在软件和大型组织工作多年后,我更加牢记了澄清的重要性。

软件工程中的澄清

我们认为我们的管理层“理解到了“我们作为技术人员所做的事情。只需“阅读代码,伙计!”。我们每天编写的软件对任何从事技术工作的人来说都应该是显而易见的,对吧?但事实并非如此。技术经理雇用最好的人,寄希望于他们能够解决难题。但经理们并没有完全“理解”这一切。

当我能够以一种不具威胁性和不居高临下的方式向他们解释一些非常基本的现代思想(例如,这些 NoSQL 的内容是什么,我为什么要关心?)时,高级技术经理很是开心。

最近,一位高级业务经理私下问我为什么要将传统部署的客户端架构迁移到托管平台。他承受着很大的内部压力来推动这项工作,但他不知道为什么这是必要的。他也可能太不好意思公开询问了。我花了两个非常有成效的小时来解释。

我现在从不犹豫,借此机会向高级或初级成员解释基本知识和动机。它在不让他们感到渺小的情况下帮助了他们,他们学会相信我的判断和建议,我们带来改变。

花时间解释是非常重要的。

管理项目101

项目管理是:将复杂的最终目标分解成更小的部分,将这些部分大致按最有效的顺序排列,确定哪些部分可以并行完成,哪些必须按顺序完成,并尝试梳理找出可能导致项目放缓或完全失败的项目的未知因素

你正在解决不确定性,试图找到未知数,并认识到尽管你尽了最大努力,你还是会在此过程中犯错误并错过一些未知的东西。

这里有一些指导方针:

  1. 分解工作。拿出电子表格、甘特图或任何对你有用的东西,开始把你的大可交付成果(比如,重写你的计费系统)分解成任务。

    从最大的部分开始,然后将大的部分分解成更小的部分,然后再将它们分解成更小的部分。

    你实际上不必自己做这一切。如果系统的某些部分你不太了解,请向了解的人寻求帮助。

    把大事分解一些,然后把注意力转移到工作的顺序上。

    什么可以立即开始?将这些任务交给能够真正将它们转化为简单任务的人。

  2. 推进细节和未知数。项目管理的诀窍是当你感到有点卡住或厌倦时不要停下来。

    正如我之前所说,这很累很乏味。这可能不是你擅长的事情。因此,继续努力克服那些刺激、无聊和痛苦的点。

    一个好的经理会和你坐在一起,告诉你哪里不够好,提出问题来提示你,甚至和你一起解决一些问题。

    我们也不喜欢它,但它是教学练习的一部分。解决未知数,直到你真的觉得花时间在它们上面没有任何价值。

  3. 运行项目并随时调整计划。一个好的计划过程的价值在于,它可以帮助你大致了解项目已经进行了多远,以及距离完成还有多远。

    随着事情的进展(他们总是如此),让每个人都了解状态。但是现在,你不必猜测你必须走多远,而是可以清楚地指出已达到的里程碑并概述预期的剩余工作。

  4. 使用在规划过程中获得的洞察来管理需求变更

    在给定原始需求集的情况下,通过分解项目,你学到了很多东西。

    如果需求在中途发生变化,请知悉这些变更并将计划进行调整。

    如果变更给项目增加了重大风险,需要进行大量新的规划,或者只是需要额外的工作量,请清楚这些成本。

    如果截止日期严格,粗略地了解所需的工作将帮助你确定优先级、削减和简化工作,以在功能、质量和交付日期之间取得最佳折中。

  5. 接近完成时重新审视细节

    是时候真正关注整理细节了。什么东西少了?什么需要测试?什么需要验证?

    进行事前分析,在此练习中,你可以了解在启动这个大项目时可能会失败的所有事情。

    确定“足够好”的界限在哪里,和团队成员一起做决定并确定标准。减少低于“足够好”标准的工作,将团队重点放在最重要的细节上。

    确定发布日期;制定兜底方案。最后,别忘了庆祝!


对话 CTO:我不确定我是否想成为技术负责人

Q:

​ 我的经理一直催促我考虑成为技术负责人。

​ 她要我做一个大项目。我知道如果我担任这个角色,我编写代码的时间就会少得多,因为我必须参加很多会议并处理大量协调问题。我不认为我想要这个,但我该如何决定?

A:

​ 我对推动人们担任管理角色有一个直接了当的看法:不应该这样做。如果你还没有准备好承担管理类型的责任,请不要承担。深入研究技术并没有错,特别是如果你觉得在成为专家之前你还有很多东西要学。

​ 优秀的管理者正在寻找可以担任更大领导角色的人才,但有时这会导致他们在人们准备好之前将他们推离编码。这种做法可能对你的职业生涯产生非常负面的影响,因为在更高级别上,被认为“技术不够”的人会发现很难晋升到承担更多责任的管理职位。保持专注的技术路线角色并学习你需要学习的内容,这比尝试学习所有这些技能同时学习管理技能要容易得多。

​ 在某些时候,为了在你的职业生涯中取得进步,你可能需要担任技术负责人工作,即使你有兴趣留在技术路线(非管理)职业道路上。这并不意味着你现在需要这样做。如果你觉得你的团队有很多纯粹的技术学习需要你做,并且你更愿意与其他人一起在这个项目上单独工作,不要担任技术领导角色。另一方面,如果你认为个人工作不会在技术上挑战你,也许是时候推动自己学习一些新技能了——技术负责人的职责是很好的尝试。

关于译者