Поскольку все команды являются частью более широкой социотехнической системы, неизбежно, что команды будут зависеть друг от друга в какой-то момент времени. При применении принципов Team Topologies одной из целей является сокращение зависимостей между командами за счет увеличения или предоставления полного владения end-to-end системами или сервисами отдельным командам. Однако полностью искоренить все зависимости почти никогда не удается на 100%. Важно это признать.
Также важно признать, что существуют разные типы зависимостей. Есть блокирующие зависимости (они останавливают поток работы, вводя время ожидания) и неблокирующие, здоровые и нездоровые, частые и редкие и так далее. Поскольку зависимости никогда не могут быть полностью искоренены, важно отслеживать зависимости между командами и типы этих зависимостей в данный момент и с течением времени.
Например, что-то, что начинается как блокирующая зависимость, может превратиться в неблокирующую зависимость. Это хорошо, так как это должно привести к увеличению автономности зависимой команды. К сожалению, также возможно, что здоровые зависимости могут превратиться в нездоровые, что может начать замедлять зависимую команду слишком сильно.
На практике мы должны стремиться фиксировать зависимости, которые есть у команды, и определять, какие из них «под контролем» (по крайней мере, на данный момент) и какие являются проблемными и должны быть решены или даже удалены. Проблемные зависимости могут привести к значительным задержкам, ввести непредсказуемость и увеличить объем WIP (work in progress) для зависимой команды.
При отслеживании зависимостей важно не документирование само по себе, а то, что трекер может быть использован для оценки того, как должны измениться зависимости. Нас устраивает блокирующая зависимость от этой команды? Что мы могли бы изменить, чтобы избежать блокирующей зависимости? Возможно ли коллаборировать с другой командой какое-то время, чтобы сделать зависимость неблокирующей или хотя бы менее частой?
Делая зависимости видимыми, каждая команда может визуализировать разные зависимости, что позволяет им работать над сокращением тех, которые негативно влияют на поток работы.
Конечно, существуют разные способы отслеживания зависимостей между командами, такие как доски зависимостей или теги зависимостей, как это показано в книге «Making Work Visible» Доминики ДеГрандис.
Один из примеров ДеГрандис — это Физическая матрица зависимостей (представлена ниже). Эта матрица помогает командам организовывать и визуализировать зависимости и легко может быть воссоздана с помощью онлайн-инструмента для удаленных команд.
Physical Dependency Matrix Source: Dominica DeGrandis, Making Work Visible: Exposing Time Theft to Optimize Work & Flow (Portland, OR: IT Revolution, 2017), 79.
Она также показывает, как команды могут использовать простые канбан-доски для визуализации зависимостей (два примера приведены ниже). С множеством инструментов, доступных для онлайн-канбан-досок, это может быть отличным вариантом для удаленных команд.
Dependency Swimlane Board Source: Dominica DeGrandis, Making Work Visible: Exposing Time Theft to Optimize Work & Flow (Portland, OR: IT Revolution, 2017), 81.
Dependency Tags on Kanban Cards Source: Dominica DeGrandis, Making Work Visible: Exposing Time Theft to Optimize Work & Flow (Portland, OR: IT Revolution, 2017), 81.
Многие из примеров в книге «Making Work Visible» могут быть легко адаптированы для удаленных команд, использующих такие инструменты, как Mural, Miro, Trello и другие.
Ниже приведен пример трекера зависимостей команды. В этом примере команда работает над контентом для сервиса потоковой передачи музыки. Их работа также требует взаимодействия с многими другими командами по всей цепочке создания ценности, такими как Operations, Storage, Recommendations и Data Admin.
<aside> <img src="/icons/arrow-northeast_purple.svg" alt="/icons/arrow-northeast_purple.svg" width="40px" /> Скачайте пустой трекер зависимостей команды для использования с вашими командами здесь: GitHub.com/TeamTopologies/Team-Dependencies-Tracking.
| Team name/focus | Depends on team | Type (blocking/ slowing/ ok) | Short description of dependency (artefacts, approvals, other) |
|---|---|---|---|
| Music Content | Ops | Slowing | Need machines, connections, help to set up things. Generally works well, but a times the workload on Ops causes the lead times to grow and slow us down. |
| Music Content | Storage | No problem | Storage. Not big, mostly information/ communication needs to happen. |
| Music Content | Recommendations | No problem | Recommendations service integration when there’s a new type of content. |
| Music Content | Data Admin | Blocking | Waiting for necessary data dumps for our analytics. |
Используя приведенный выше пример в качестве отправной точки, подумайте о некоторых командах в вашей организации. Как они взаимодействуют в настоящее время? Какие зависимости между ними существуют? Замедляют ли они или блокируют другую команду от выполнения работы? Какова причина зависимости? Заполните трекер зависимостей для каждой из команд, чтобы у вас была четкая запись, которую можно использовать для мониторинга этих зависимостей со временем.
В известной «Spotify Model» Spotify отслеживал зависимости между командами с течением времени с помощью простой таблицы. Они спрашивали все свои команды, от каких других команд они зависят и в какой степени эти зависимости их блокируют или замедляют.