拍脑袋划分团队

 

我还是一个年轻的，天真的软件开发人员,我渴望结构和分析思维模式来设计最佳解决方案。

令我感到震惊的一件事是任意划分团队边界。

令人惊讶的是，我正在从从事设计业务的领域进行思考。我对这个领域中不断增长的动力感到非常兴奋。通过结合团队拓扑，映射，动态再分配和域驱动设计，我感到我们正在开始开发必要的工具，以有目的地，有效地设计现代技术组织。

总结一：将社会技术架构可视化为战略与投资

在核心领域上布置您的技术能力可以传达技术战略的各个方面。它显示了您认为哪些功能是实现业务目标的关键。

核心领域是关键战场，提供比竞争对手更具吸引力的产品至关重要。通用服务只是构成了一个平台，使核心领域的团队能够更频繁，更经济地交付价值。（banq注：平台团队和业务团队的区别）

通过发现核心、通用和支持领域就能表达对价值所在的信念。但是策略是需要做出选择的，是关于资源分配的，需要选择专注于某些事情而牺牲其他事情。

因此，团队管理的重点在于需要检查：我们所说的重要内容是否与我们实际投入时间和资源的方式保持一致？

首先。量化或可视化的第一步是为核心子域、通用和支持三个子域中的功能分配FTE（全职等效雇员），根据投入FTE数量来代表你的实际投入实际和资源，当然您也可以改用预算或其他承诺指标。

总结二：优化投资

当您重视了技术远景和投资时，就会出现许多问题和选择。你会发现：为什么我们要为支持子域分配FTE数量是核心域的两倍？”，也就是说，宝贵资源并没有投入到核心子域上。

追查原因时，我们可能会发现是因为意外的复杂性：这些都是我们的旧代码库，使用起来非常痛苦。如果代码更易于更改，并且需要的实时支持更少，那么我们只需要一半的人员。

通过减少这种意外的复杂性，FTE将被投放在核心域上工作。

下一步是降低意外复杂性的成本并衡量预期收益。我们知道数字并不能完全准确，但是我们可以做出更明智的风险/回报决策。

我们可以想象有无穷的战略作用。关键是我相信在可视化信念和承诺以及在可视化条件下可以协同模拟和评估策略性行为方面具有巨大优势。

根据我的经验，这个门槛太低了，以至于即使是这种简单的方法，对许多公司来说也是一个很大的进步。

总结三：分析团队之间的关系

无论我们多么努力，软件组件和管理它们的团队之间总会有依赖关系。大型企业级别的计划将导致跨多个团队的工作计划。

我们需要可视化团队之间的依存关系，并量化这将如何影响我们执行策略的能力：还是要将大部分精力投入到我们的核心领域。

我喜欢将团队拓扑交互模式用作描述团队之间关系类型的语言。如果您不熟悉，这里有一个简短的介绍：

X-as-a-service：X-as-a-Service：一个团队提供了一些技术功能，例如API，其他团队却在最少的支持和协作下就可以使用它们。

协作：多个团队紧密合作，以完成大量工作

促进：一个团队暂时在帮助另一个团队实现目标

在核心领域图表上显示这些关系会突出我们可能没有意识到的重大问题或机会。

总结四：定义团队边界

强调团队和软件边界之间的依赖性为更高级别的组织设计奠定了基础。了解软件中的哪些变化是确定团队组织方式的关键。

不幸的是，系统的共同变更是多维的。系统的不同部分将根据待办事项中的内容进行共同更改和不同时间。通过可视化这些依赖关系，我们可以针对要优化的哪种类型的合作变更做出战略决策-我们以最能使我们改善核心领域的方式组织团队。

组织团队还有另一个方面，那就是超越物理界限。这是团队根据他们正在发展的概念的演变而定的心态。

在高度未知的空间中具有很大的不可预测结果的大赌注核心领域需要发现心态。学习速度是关键，这意味着流程和技术实践会发生变化。

应该根据团队的实际联系或开发的产品的心态对团队进行分组（这就是Simon Wardley所说的“ 先驱者”，“定居者”和“城市规划者”）。

量化或可视化这些关系会迫使我们考虑由此产生的动态以及它们如何影响我们的战略选择。为了充分利用我们核心领域的机会，我们需要仔细，自觉地考虑社会技术架构的各个方面。