弹性盒子flex:1_建立团队弹性：共同努力（第1部分）

弹性盒子flex:1

我一直在与环境脆弱的客户合作。 它们的脆性不会一直出现。 当一切都好时，他们就能完成工作并交付。

但是，有人签入了破坏“那边”内容的代码。 或者，有人被派去处理生产支持问题，并且几个星期后团队再也没有了。 或者，他们有天气事件，而人们无法上班。

经理最初认为这些都是可恢复的。 球队可以康复。 但是，它们无法快速恢复。

团队几乎没有弹性。

团队一次需要数周才能恢复。 经理们认为这“太长了”。 我同意。 经理们没有意识到他们的决定会造成这些问题。

定义弹性

当我谈论弹性时，我指的是尝试替代方法的能力。 有时，该实验只是一小步（如图所示）。 有时，这是一个带有假设的整个实验，等等。

（如果您想更深入地研究弹性，请参阅我的其他博客上的弹性和适应性之间的区别是什么 。）

团队可以通过多种方式建立抵御能力。 我将仅讨论以下三个问题以提高团队的弹性：

• 团队不是团队合作，而是个人合作。
• 团队的反馈周期很长。
• 团队没有“在任何地方”工作的能力，当然也没有“在任何时间”工作的能力。

这篇文章是关于人们何时作为个人工作的问题。

个人而非基于团队的工作

甲公司正在努力进行其第十多个“敏捷转型”。 我将其用引号引起来，因为经理们希望团队进行变更。 实际上，管理人员需要首先进行更改。

最大的问题之一是管理者认为敏捷方法将使他们更快地交付。 是的，而且这种交付源于快速的反馈周期-快速的学习。

软件产品开发首先要学习 。 我们学习得越快，我们就能越快地交付有用的东西。

当我们不一起学习时，我们就会运送垃圾。 或者，我们不发货，那是垃圾。 我不知道哪一种情况更糟-垃圾运输还是不运输。

A公司经理不相信流程的效率 。 经理给人们个人目标。 而且，经理们希望人们交付“他们的”东西，达到这些目标。

所谓的Scrum Master（在我看来他们是老式的指挥与控制项目经理，而不是协调员）向人们询问“他们的”工作何时完成。

对个人工作的强调意味着A公司的团队将在可能的情况下进行合作。 团队不合作。

合作不等于合作

这些团队主要通过代码审查进行合作。 他们在进行代码审查时做得很好。

但是，他们进行代码审查的方式至少存在以下问题：

• 他们并不总是进行代码审查，因为开发人员“迟到”。 （通常是因为代码比他或她预期的难得多。是的，这恰恰是开发人员需要更多审查的时候。）
• 我要求团队衡量他们的周期时间 。 那时，团队意识到他们有时需要等待几天才能进行代码审查。 这些拖延没有人能够实现他们的目标。

团队成员尝试合作。 但是，个人目标会阻碍每个人进行协作。

（我建议在进行配对，蜂拥而至和围攻之前，以帮助减少周期时间并增加协作。）

为什么要强调个人工作？

当我解释资源和流程效率的概念时，经理们点了点头。 他们明白了。

是什么阻止他们使用流量效率？ 绩效管理系统和人力资源。 另外，软件大写问题。 （人们越快地运送东西，他们就越能利用资本。）

管理者需要改变他们的工作方式。 管理者需要解决这些障碍。

我问管理者哪个目标对管理者更重要：

1. 衡量个人的工作。
2. 运输工作产品以获取更多收入。

不，我没有提供“三个规则”中的第三个选项。 我们还没有解决问题的模式。 我们处于问题识别模式。

经过大量讨论，他们同意运输产品比衡量单个人的贡献的能力更重要。

！

现在，我们可以研究替代单独工作的替代方案，以提高团队的应变能力。 接下来，我们攻击了反馈回路问题。

该系列（我将在发布时添加链接）：

• 建立团队弹性：共同努力（第1部分）
• 建立团队弹性：缩短反馈循环（第2部分）
• 建立团队韧性：“随时随地”和“随时随地”工作（第3部分）
• 建立团队复原力摘要（第4部分）

翻译自: https://www.javacodegeeks.com/2020/03/build-team-resilience-work-together-part-1.html

弹性盒子flex:1