分而治之需要管理控制

最近有几个客户需要这些问题的帮助：

这些团队遭受了分而治之的问题。

当管理者按职能划分团队时，团队很少有机会学习和协作。

另外，管理人员需要越来越多的管理控制。这是因为共同的目标是高级经理，而不是任何较低级别的经理。

如果您是项目经理/ Scrum Master /类似组织中的其他人员，那么矩阵本身就不是问题。矩阵是问题的征兆。

分而治之会创建较小的目标，据说是为较大的目标服务。没有。分而治之创建的小目标可能根本不会导致更大的目标。

太多的管理者认为，将功能或体系结构层分开是有意义的。也许他们被教导有意义。也许他们从未见过替代方案。

按功能或体系结构层分开产品开发会创建不完整的部件，而不是通过体系结构生成功能。

问题是：顾客不买东西。他们不买建筑的一部分。他们不买线框。他们没有测试就不会购买开发。这些都是碎片。

但是各种各样的作品并不是一个单一的功能。作品创造了进步的幻觉。

在团队生产出完整的功能之前，客户无法购买任何东西。贯穿整个体系结构不仅仅是思考故事外观的一种好方法。这实际上是完成工作并将其资本化的一种方式。

当我们考虑流程效率时，我们会为团队进行优化以提供完整的功能。当管理者以分而治之的方式思考时，他们会优化资源效率。

管理人员不会为完成功能或进行协作学习而进行优化。而且，他们优化支出而不是资本化—正是他们所不想要的。

管理人员必须创建控制点以了解工作流程和进度。

在我解释软件（或其他知识）工作团队实际工作之前，这对某些经理来说似乎违反直觉。团队共同学习以创建产品。（请参阅产品组织转型系列。）小的反馈循环（开发和测试，开发/测试/ PO）越快越快，团队发布功能的速度就越快。

团队发布功能的速度越快，管理人员就可以更快地利用工作资金。

事实证明，并非只有技术团队需要一起学习。当管理人员一起学习时，他们减少了管理决策的等待时间。

分而治之以控制的形式创造了更多的管理工作。

我客户的问题是真实的。其中太多源于资源效率思维，而不是流程效率思维。

早在1975年，弗雷德·布鲁克斯（Fred Brooks）在《神话的月刊》中说：“无论分配多少妇女，生育一个孩子都要花9个月的时间。” （我的书在家里。我认为那是报价。）

当您不希望协作（例如战争，或两个孩子互相大喊大叫），或者确实想要交接时（例如在工厂中，工作从一台机器转移到另一台机器），分而治之即起作用。

知识工作的分而治之会产生太多WIP（进行中的工作）。管理人员需要创建控制机制以使工作重归于一体。

相反，请考虑流动效率。然后，经理可以团队协作，可以为团队提供服务并管理项目组合。此外，他们可以每天或隔天使用该软件。

翻译自: https://www.javacodegeeks.com/2018/11/divide-conquer-need-management-control.html