我最常举的一个功能失调和官僚主义组织的例子是我曾在一家金融公司中看到的……

我之前多次见过这种情况。管理层责备优秀的工作，因为这项工作的某种外部因素出现在他们必须在每周会议上讨论的图表上。甚至不需要让图表看起来变差，只要突出显示就行。

我作为高级产品经理正在处理这个问题，向高管们解释，并为工程师们辩护，当他们开始引入指标时，其中一个关键指标是“计划点数完成”。 我的团队会接收并优先处理所有升级的bug。 对于这个团队来说，这种指标是不准确、不公平且士气低落的，因为他们被标记为“红色”，因为指标显示的是：“计划的点数：30。计划点数完成：5。”而他们实际上完成了20-30个未计划点数的bug修复。 “如果他们必须做这些工作，他们就应该得到认可，无论是否是计划内的。你不能让一些必要的工作在KPI中没有任何价值。” 关于需要多少未计划工作的问题是一个独立且有效的讨论，但不在“工程节奏/速度”的范围内。

> 当然不是，我们把票数翻了一倍，在一半的票上填写了“占位符”，然后在需要的时候使用它们，最后在冲刺结束时关闭了所有票，大家都为我们出色的估算能力表示祝贺。 你确定这是一个负面例子吗？你甚至找到了一个解决方法，让所有人都满意。 这并不是一个功能失调的组织的样子。

这太棒了。我曾与一家（不同的？）金融公司合作，他们也做了同样的事情——每个团队都根据他们的燃尽图来评判。 据我所见，这并没有带来任何好处。团队根本不用票来跟踪工作。如果一个故事跨越了多个冲刺，它的“票”会在一个冲刺结束时关闭，然后在下一个冲刺开启一个新的票。如果在冲刺中出现了一个优先级高的bug，我们只是直接处理它，而没有创建票。

> 每个人都应该为这个发展感到高兴！但我们有一次冲刺评审会，有个“高级项目经理”其实并不真正参与我们的项目，而是更高层的某个经理，他对我们冲刺中打开新票并关闭旧票的行为很生气，认为这破坏了组织层面的燃尽图和交付预期。 他们为什么应该为你们采用看板方式却声称做其他事情而破坏燃尽图感到高兴呢？

我也在一家大型金融机构工作，经历过很多类似的情况。幸运的是，我是负责人（某种意义上的团队领导），我对这种“高层”的胡说八道有一个相当标准的回应： “你无法准确跟踪我们团队每周或每月的绩效，这不是我的问题。” 每个“项目”都有计划、交付物和截止日期，这些才是衡量团队绩效的最终标准。不是每周或每月的统计数据！无论我们开启10个或10000个工单，都毫无区别。这完全是随意的，只有对相关团队才有意义（而不是高层管理）。 像某些高层经理/项目经理，他们其实并不参与我们的项目，只是高层的某个管理者，却因为看到每周Jira工单统计数据而对我们在冲刺期间开启新工单并关闭它们感到愤怒。这会破坏组织层面的燃尽图和预期交付。 这让我想起了我曾经工作过的一家公司（虽然时间很短）。 不知为何，他们决定计划准确性是软件组织最重要的指标。这是他们在高管会议上谈论的主要指标，也是项目管理人员奖金结构的主要依据。 因此，公司里的一切都围绕着计划准确性展开。在冲刺期间开启新工单是被强烈反对的。进行下一冲刺的工作是被强烈反对的。尝试在冲刺期间承担大型项目也是被强烈反对的，因为如果你…

我们有一次冲刺回顾会议，有个所谓的“高级项目经理”，其实和我们的项目没有直接关系，只是高层的某个管理者，他很生气，因为我们在冲刺期间开启新工单并关闭它们，破坏了组织层面的燃尽图和预期交付。 这让我想起了以前在一家公司工作的经历（虽然时间很短）。 不知为何，他们决定计划准确性是软件组织最重要的指标。这是他们在高管会议上谈论的主要指标，也是项目管理人员奖金结构的主要依据。 因此，公司里的一切都围绕着计划准确性展开。在冲刺期间开启新工单是被强烈反对的。进行下一冲刺的工作是被强烈反对的。尝试在冲刺期间承担大型项目也是被强烈反对的，因为如果你…

我在几家大型五角大楼承包商和为美国国防部和情报界工作的较小SBIR承包商那里，多年来都经历过类似的情况。作为一名在20年前比普通开发人员对计算机和网络的实际运作方式有更好理解的人，并且在当时 juniors 无法离开他们的IDE就会彻底迷失的时代，我习惯于在命令行中工作，随着DevOps、SRE和平台工程逐渐成为一种趋势，我的职业生涯也逐渐朝这个方向发展。 在那样的团队中，问题总是相同的。你负责开发某种软件产品，但这些软件运行、测试或交付其他软件，甚至协调多个不同应用程序共享的整个环境的运作。这不可避免地意味着你大量的工作是经典的事件响应…