开发人员不应该向项目经理汇报

[注：本文中，我将使用“PM”作为“管理程序员的非技术人员”的统称。PM 可以是项目经理，也可以是产品经理，还可以是 Scrum Master，甚至可能是没有直接编程知识的开发经理。我知道这些不是（或者不应该是）相同的角色——但在某些组织中，这些头衔经常互换使用。因此，在本文的其余部分，我将统称为“PM”。]

也许这只是一个轶事，但我感觉越来越多的公司在组织开发团队时，程序员会直接向非技术人员汇报。具体来说，我注意到开发人员会发现自己被一个对开发人员实际工作方式几乎一无所知的人管理。

需要明确的是，这种情况并不一定“糟糕”或“错误”。我见过这种情况发生，或许你也见过。但我见识过越多，就越确信它就是组织结构图中的代码异味。

我为什么这么说？？？

平衡

我发现，在我最优秀的一些团队里，项目经理和开发者之间存在着一种健康、互相尊重的……紧张关系。这听起来可能有点对抗性。所以我称之为“平衡”。

希望我们都朝着相同的长期目标和可交付成果努力。但在实现这些目标的过程中，产品经理（主要关注日期/里程碑/演示等）和开发人员（主要关注技术债务/架构/遗留错误等）之间有时会出现一些推拉。请考虑以下假设（但现实）的对话：

产品经理：客户决定这个任务现在需要在这个冲刺之前完成。你能安排吗？
我：我现在时间很紧。我可以在这个冲刺中推出哪些任务来腾出时间？
产品经理：嗯……嗯，离上线这么近，能做的不多了。但是他们升级的任务估算得相当高。有没有什么办法可以做得更快？
我：那个估算是基于我需要构建一个新的端点来动态查询代码中所需的值。但这些值大约每六个月才会更改一次。如果我使用硬编码值进行编程，我可以更快地完成它，并将其融入到当前的冲刺中。
产品经理：那太好了。
我：但是如果我将这些值硬编码，我将创建一个新的工单来构建服务。你得向我保证，一旦我们上线，这将是首要任务。
产品经理：成交！

你在这次对话中感受到任何紧张感了吗？很微妙，但确实存在。在我的职业生涯中，我经历过数百次这样的对话。

我和项目经理之间通常保持着高度的尊重，而且从总体上看，我们都在朝着同一个目标努力。但是，当项目经理试图处理客户/项目日常的琐事时，他们有时会提出一些危及项目长期健康的问题。这没关系——只要沟通顺畅，并且如果我认为对方提出的要求不合理，我可以毫不犹豫地予以拒绝。

在上面的例子中，我们完成了一次基本的谈判。我通过提出一个次优方案，满足了产品经理的需求（一个额外的可交付成果，可以添加到本次冲刺中）。但我这样做只是因为我知道这不会立即产生任何副作用，而且我得到了保证，一旦发布日期过去，我们就能“以正确的方式”完成。（当然，如果我们彼此不信任，这样的保证就毫无意义，但为了本文的目的，我们姑且假设每个人都是“好演员”。）

上述机制之所以“有效”，是因为虽然我和项目经理在团队中拥有不同的权力/职责，但我们彼此之间并不互相汇报。具体来说，如果我直接向项目经理汇报，那么当项目进入紧张阶段时，这种互动就更有可能……出现问题。

当我和产品经理在组织结构图上真正平等时，每当我被要求做一些可能导致短期或长期问题的事情时，我就能更容易地以专业的方式提出反对意见。在极少数情况下，如果我的“专业反对”不够有力，而我又觉得必须坚持自己的立场，我可以通过向经理反映来升级问题。

但如果项目经理是我的经理，这种专业的沟通就……更加棘手了。如果项目经理水平不够，他们可能会在项目进行到最后关头因为这种阻力而慌乱不已。最糟糕的情况是，他们可能会直接命令我按照他们的方式（或者客户的方式）去做，即使我所有的反对意见仍然有效。

不用说，这肯定会造成一些非常尴尬的情况。比如，如果我被要求硬编码某个我知道很快就会出问题的程序，我该如何保护自己呢？因为我也发现，试图向产品经理以外的人发出警报，本身就会带来一系列麻烦。（话说回来，不发出警报也同样令人头疼。发出了也该死，不发出也该死……）

倡导

我坚信，经理的首要职责之一，应该始终是在适当的时候维护下属的利益。这适用于公司任何部门、任何团队。

有时，这种“倡导”意味着保护员工免受领导层不合时宜的指令的干扰。有时，当客户极力推动某项实际上会破坏客户项目的事情时，它需要站在员工的“一边” 。有时，它需要了解哪些新成员最适合团队——或者，也许，哪些团队成员需要离开。根据我的经验，项目经理在这方面通常非常糟糕。

这很少是产品经理的错！怎么会这样呢？当你不真正了解员工的工作时，要为他们“辩护”就难多了。

此外，在很多组织中，项目经理花费大量时间直接与客户/利益相关者沟通，以至于他们几乎成了客户的代言人。事实上，虽然我不喜欢没完没了的会议，但我偶尔也会告诉我的项目经理，他们应该让我直接参加会议。因为如果我让他们去做“项目经理的事情”，而我坐在那里写代码，他们最终会试图把电话会议里讨论的内容一字不差地告诉我。

这是我见过技术经理和非技术经理之间最显著差异的一个领域。当开发人员告诉技术经理——他们大概至少对代码有深入的理解——他们给出的方法真的很糟糕时……他们往往会听取。这并不意味着开发人员总能如愿以偿。但一个技术型经理很少会无视那些真正在做事的人的担忧。

我见过太多项目经理（总是很快地）就用老掉牙的套路说：客户想要这样，我们就这样。在屋顶上装个马桶？谁在乎这有多荒唐？这可是客户想要的！墙是用泡沫塑料做的？谁在乎一年后会不会全部坏掉？这可是客户在规格说明书里写的！

技术文盲

我完全理解，管理我或我负责的项目的人不应该是编程大师。但过去五年左右，我遇到过一些相当奇怪的情况，有些情况甚至令人沮丧。

在软件开发中，移动页面上的按钮有时会比最终用户想象的要耗时得多。当最终用户对此感到困惑时，我并不会感到恼火。但当我向产品经理汇报时，我确实会有点恼火——因为我不得不（反复）向他们解释这一点。

当我担任团队主管/资深人员，并向项目经理汇报时，年度评审的情况总是有点奇怪。有些项目经理在为其他开发人员撰写评审时根本不让我参与。说实话，我有点喜欢这样，因为写年度评审实在太烂了。但如果非技术型项目经理为其他开发人员撰写评审，甚至都不问我（或任何其他人）该开发人员实际编写的代码呢？嗯……我有点困惑，他们怎么能得出这么准确的评估结果。

在其他团队，项目经理会非常依赖我，让我帮忙撰写——或者完全负责——团队其他开发人员的评审意见。虽然我理解他们要求背后的逻辑，但我还是忍不住想问：既然这些人自己都不愿意写评审意见，那他们为什么要管理他们呢？

我遇到过一些项目经理，他们试图做“正确”的事情，不让我和团队其他成员参加无休止的会议，却告诉我，他们刚刚与所有利益相关者进行了一次大型讨论，决定采取一项可能带来灾难性的行动。我平静地告诉项目经理，我们可能需要尽快再召开一次会议，由我和之前的团队参加，以便我可以解释一下这个新方向可能带来的一些严重后果。

通常情况下，如果我和产品经理以及其他技术人员开了一个小时的会，会后我得花20到30分钟跟产品经理进行一次跟进电话会议。我必须这样做，因为产品经理并不真正理解讨论的内容。而且，我必须在最初的会议结束后进行一次冗长的汇报，用外行人能理解的语言，向大家解释清楚每个人的提议。

直言不讳

这或许更多是出于个人喜好。但当我们真正努力寻找最佳技术解决方案时，我发现，坦诚、坦率、直言不讳的沟通不仅仅是“锦上添花”。有时，它甚至至关重要。

[注：不！！！不是艾米莉·布朗特。到底是谁编辑了这篇文章？？？]

我想，开发人员的名声是出了名的……有点太直率了。我理解。真的，我理解。但我发现，那些非技术型的项目经理们，总是过分地谈论政治话题。他们自己滔滔不绝地说，还指望着别人反驳。

我完全理解，当我们与客户/利益相关者/高管交谈时，我们不能告诉他们：“哇。这个想法完全是垃圾。” 但是，当开发人员坐在房间里，试图集思广益，讨论如何解决最新问题时，如果有人突然提出一个糟糕透顶的想法，我会告诉他们：“哇。这个想法完全是垃圾。”

我有幸加入过的最优秀的开发团队，都拥有友好竞争和坦诚评估的氛围。我们不会无缘无故地互相诋毁，也不会粉饰任何细节。只要房间里只有我们，我们就有充分的自由在白板上发表意见——而且，当我们的想法被证明，嗯……不够好的时候，我们也会遭到一些嘲笑。

当我向技术人员汇报时，这种沟通方式从未让我遇到过任何问题。他们知道我不会在客户或董事会面前滔滔不绝。但只要我们身处各自独立的环境中，就能畅所欲言。

这种自由在两名或两名以上团队成员对我们应该如何推进项目持有激烈且截然相反的观点时，才能真正发挥作用。这种情况并不常见。但当这种情况发生时，我见过开发人员为了热烈地拥护各自选择的解决方案，几乎要互相大声争吵。

我见过有人脸红，还有些唾沫横飞。但你知道吗？团队最终会做出集体决定。即使我的决定被否决，会议结束后，血压也会下降，笑容也会重现，我们就会开始执行上述方法。

再说一次，当我向技术人员汇报时，这种沟通方式从未出现过问题。但当我向非技术型的项目经理汇报时呢？嗯……我见过这种“充满激情”的会议最终导致正式的书面报告。

在这种情况下，“问题”在于，项目经理的工作和运作几乎无时无刻不在本质上与政治息息相关。根据我的经验，大多数开发团队几乎完全不关心政治。因此，项目经理很难理解这些会议期间发生的那些良性（但在旁观者看来却颇具挑衅性）的争论。他们会把这些言论当成针对个人的。他们开始把这场受保护的技术会议当成公司董事会会议。而当这种情况发生时，典型的开发者风度就大打折扣了。

结论

我知道这听起来可能像是在长篇大论地解释为什么项目经理很差劲。相信我，这并非我的本意。我遇到过的一些最好的同事都是非技术型的项目经理。我甚至有过（一些）直接向这些人汇报的积极经历。项目经理和程序员真的没有理由不能“友好相处”。

但最近，我开始回顾过去20多年的经验，注意到一个普遍的趋势。当我直接自己写代码，并且向一个完全不懂代码的人汇报时，会遇到更多需要克服的障碍。而当我向一个至少了解基本编程原理的人汇报时，很多障碍（当然不是全部）似乎都消失了。

显然，这些普遍的看法并非绝对。我完全清楚，在某些情况下，对于某些项目经理来说，让他们管理程序员完全没问题。同样，我也意识到，仅仅拥有编程知识并不能使任何人成为优秀的管理者（无论是对程序员还是对其他人而言）。只是在我看来，当程序员管理程序员时，沟通不畅的可能性会更小。

我真的很好奇，我的观点是否仅限于我？或者其他人在他们的职业生涯中也得出了类似的结论？