公司以团队延误工期为由辞退

想象一下，您有一个大型计划，其中有多个团队为一项业务交付品的成功做出了贡献。 你们都在努力争取一个特定的发布日期。

一个团队遇到了麻烦。 也许这是他们第一次错过的交付成果。 也许这是他们的第二次。 也许他们一直都无法满足他们的可交付成果-他们已经“交付”了，但可交付成果却行不通。

现在，假设您正处于所需的编程时间的一半。 您作为程序管理员可以看到此程序有麻烦。 那一支球队不会成功。 你是做什么？

在这里，您开始与人交谈并了解一切的价值 。

1. 该计划是否需要该团队积压的一切？
2. 该计划是否需要其他团队积压的一切？
3. 程序产品所有者是否了解延迟的成本？
4. 该计划的赞助商如何？ 他们知道发生了什么吗？

延误成本，餐巾纸背面

拿出您餐巾纸计算的背面，然后将其显示给任何愿意听的人。

正如我们在第1部分中讨论的那样，团队是否了解延迟问题？ 他们可能。 他们可能会为自己所做的技术难题感到不知所措。 也许他们的故事很大。 也许他们并不那么敏捷。 也许他们没有以敏捷的方式工作。 有1001个此问题的原因。 如果您是任何部门的经理，程序经理，开发经理（无论如何），则您有责任首先了解而不是大喊大叫。 （我经常看到高级开发经理，VP工程部遇到这种情况，但没有意识到他们是这种情况下的程序经理。）

程序产品所有者真的需要他们积压的一切吗？ 现在是时候考虑该团队可以做些什么，同时仍然可以提供有价值的东西了。 或者，是时候考虑其他团队所做的工作很少并且仍然可以带来有价值的东西了。 或者，是时候重新确定谁在做什么。 否则，您将在收入流的中间赔钱。

团队是否按层，前端，中间件，后端工作，而不是通过体系结构工作？

该程序必须进行某些更改。 您将不会做出期望的日期。 此问题是不按时发货问题的一个较大案例，但不仅仅是一个团队。 它涉及更多的团队。 而且，通过一个程序，它涉及更多的钱。 几乎总是更大的赌注。

这是您要开始考虑功能延迟成本的时候。 是的，不仅针对发行版，还针对功能。

在特定时间交付每个功能都具有价值。 在某个时间之前，它可能具有或多或少的价值。 一定时间后，它的价值会降低。

谁知道那是什么时候？ 谁可以在您的组织中做出这些决定。 有时，此人称为产品所有者，产品经理或喘着粗气的客户。 有时，这个人被称为市场经理或董事，甚至首席执行官。 很少有人称为开发人员或测试人员，甚至是开发经理或测试经理或工程经理或CIO或工程副总裁。 有时产品开发方知道。 产品开发团队几乎从来都不了解自己。

如果您是跨职能团队，产品开发和市场营销方面的决策者，那么您将两全其美。 您可以了解技术风险，尤其是在团队遇到技术问题时。 您可以了解延迟风险的成本，尤其是从客户角度来看，这是很好的。 现在，您可以决定为了该程序的好处该做什么。

您必须优化程序的吞吐量，而不是任何一个团队的吞吐量。

在我的世界中，您与团队合作：他们是否想在一起？ 他们是否在一起工作良好，并且在技术上度过了艰难的时光？ 如果是这样，团队有很多选择：

• 团队可以向另一个团队寻求技术帮助（让建筑师/设计师与该团队一起工作）
• 团队可以将他们的积压工作分配给其他几个团队，从而为他们提供战斗机会。
• 如果团队不能很好地合作（他们会告诉您是否还在进攻），请给他们提供分裂的机会。 或者，您可以促进更好的工作关系，以便他们可以一起良好地工作。

如果您不问团队，那您就不知道出了什么问题。

这种延迟成本的问题在于，讨论起来很棘手，估计起来很棘手，修复起来也很棘手。 它是真实的。 我敢打赌你已经看过了。

我会拿出餐巾纸，并提醒团队他们的延误将花费整个计划。 我想帮助他们消除这种延迟。

如果您对程序使用瀑布式方法，则在进行测试之前，直到程序结束，这种延迟的成本才可见。 为什么？ 因为那是您开始看到功能出现的时候。

如果您使用的是敏捷方法或至少是递增的生命周期，那么您将很快看到这种情况，并且您可以对此做一些事情。

到目前为止，本系列文章包括：

1. 由于未按时发货而导致的延迟成本，第1部分
2. 多任务处理导致的延迟成本，第2部分
3. 由于犹豫不决而造成的延误成本，第3部分
4. 技术债务造成的延误成本，第4部分

翻译自: https://www.javacodegeeks.com/2014/03/cost-of-delay-due-to-other-teams-delay-part-5.html

公司以团队延误工期为由辞退