Команда отвечает за смену тарифа в личном кабинете. Для небольшой доработки ей приходится разбираться в расчётах, выпуске приложения, сертификатах и мониторинге. Формально все полномочия переданы. На практике работа держится на нескольких людях, каждый из которых помнит свой участок. Назвать такую команду автономной можно, но быстрее от этого она не станет.
Team Topologies предлагает проектировать состав обязанностей и взаимодействия между командами вместе. Это подход к организации работы, а не готовое штатное расписание. Он полезен, когда важно понять, какую сложность команда должна освоить сама, какую получать как услугу и где ей временно нужна помощь.
Полномочий достаточно, а внимания — нет
Когнитивная нагрузка здесь означает объём знаний и связей, которые приходится удерживать, чтобы безопасно работать с системой. Это не оценка интеллекта сотрудников. Если для обычного выпуска нужно вспомнить особенности нескольких чужих платформ, меньше внимания остаётся на последствия смены тарифа для клиента.
Авторы предлагают оценивать нагрузку при выборе границ команды. В нашем примере полезно отдельно обсудить правила продукта, сложности выбранных технологий и знания, которых пока недостаёт. Постоянная передача эксперта из проекта в проект может закрывать срочные задачи, но оставлять прежнюю зависимость.
Спросите команду о последнем затруднении: она не понимала правило тарифа, не умела диагностировать запрос или ждала разрешения на выпуск? Эти причины требуют разных решений. Курс по инфраструктуре не заменит право принимать решение, а новая роль руководителя не сделает непонятный расчёт проще.
Четыре типа команд — не четыре обязательных отдела
В модели Team Topologies stream-aligned команда отвечает за поток работы, enabling помогает освоить недостающую компетенцию, complicated-subsystem берёт специализированную сложность, а platform предоставляет внутренние возможности другим командам. Это разные назначения, а не ступени иерархии.
Для смены тарифа команда клиентского сценария должна понимать продуктовые ограничения. Платформа может предоставить поддерживаемый способ выпуска и диагностики. Специалист по наблюдаемости поможет научиться пользоваться им. Сложный расчёт, требующий отдельной экспертизы, иногда оправдывает собственную команду — но не каждый сервис расчётов автоматически становится сложной подсистемой.
У каждого выделения есть цена. Если ради простого поля приходится обращаться к новому владельцу, дополнительная команда могла увеличить зависимость. Сначала стоит проверить, достаточно ли улучшить интерфейс или передать знания. Маленькой организации необязательно создавать все четыре типа: иногда проблему решают общая инструкция и несколько совместных рабочих сессий.
Особенно осторожно стоит выделять подсистему, которую умеет поддерживать один человек. Новая граница не создаёт резервного специалиста. Потребителям всё равно нужны сроки реакции и возможность продолжить работу во время его отсутствия. Иногда выгоднее сначала обучить коллег и уменьшить сложность компонента. Иначе освобождение одной команды от нагрузки обернётся единственной очередью к эксперту для всей компании.
Договориться, как именно мы работаем вместе
Три режима взаимодействия в этой модели — collaboration, X-as-a-Service и facilitation. Совместная работа нужна для ограниченного периода поиска решения; услуга предполагает потребление готовой возможности; помощь направлена на освоение навыка. Подробности и переходы между режимами описаны в руководстве по моделированию взаимодействий.
Допустим, команды кабинета и расчётов вместе выясняют правила перехода на тариф посреди периода. Пока остаются неизвестные, тесная работа оправдана. Заранее полезно определить её результат: согласованные примеры, интерфейс и способ проверить исправление. После этого обычная доработка кабинета не должна каждый раз возобновлять общий проект.
Получение услуги означает больше, чем наличие API. Команде нужны понятные ограничения, диагностика и ответ на вопрос, куда обращаться при сбое. Если любой запуск всё равно выполняет сотрудник поставщика вручную, зависимость не исчезла. У неё просто появился аккуратный интерфейс заявок.
Обучающая помощь имеет другой критерий завершения. Эксперт по диагностике должен помочь команде самостоятельно найти причину задержки. Если он каждый раз расследует её вместо коллег, это уже постоянное сопровождение. Оно может быть необходимо, но тогда его надо планировать и обеспечивать ресурсами, а не считать временным обучением.
Ответственность за клиента не передаётся вместе с задачей
После изменения тарифа клиенту показали новую сумму, а расчёт ещё использует прежние условия. Нельзя разрешить спор словами «наша команда всё выполнила». Нужно определить, кто контролирует завершение сценария, какие промежуточные состояния допустимы и как восстанавливается согласованность.
Общий сервис может иметь свои приоритеты и ограничения мощности. Потребителям необходим предсказуемый способ договориться об изменении. Если все запросы равносильно срочные, конфликт должен разрешать владелец приоритетов, а не инженер, которому громче написали в чат. Тип команды такого механизма сам по себе не создаёт.
Важна и устойчивость состава. Если людей еженедельно перераспределяют, договорённости и знания приходится собирать заново. При этом закрепление команды не означает запрет на общение: прямой разговор о спорном расчёте полезнее пересылки неполного требования через несколько посредников.
Проверить один переход, прежде чем менять всю компанию
Выберите повторяющуюся зависимость и обозначьте её текущее состояние честно. Например, команда не может сама разбирать ошибки расчёта. Договоритесь о помощи, выделите время обеим сторонам и определите, что принимающая команда должна выполнить без эксперта. Не нужно выдавать желаемую схему за уже работающую.
Затем проведите очередное изменение тарифа и безопасное упражнение с ошибкой. Измерьте ожидание, повторную работу и число обязательных подключений соседей. DORA рассматривает самостоятельное тестирование и выпуск как признаки слабой связанности; количество новых названий команд ничего подобного не показывает.
Проверьте также нагрузку помощников. Если кабинет стал быстрее только потому, что платформенные инженеры незаметно работают вечерами, компания перенесла расходы, а не сократила их. Следующий шаг стоит выбирать по оставшейся зависимости: улучшить услугу, сузить ответственность или продолжить обучение. Перестраивать ради этого всю оргструктуру необязательно.