Основной тезис модуля
Команда — это не просто несколько разработчиков, которых поместили в один чат, добавили на одни и те же встречи и назначили им общего руководителя.
Команда — это система, которая должна обладать собственной функцией, границей ответственности, необходимыми компетенциями, распределённым знанием, механизмами принятия решений, связями с другими командами и способностью сохранять действие при изменении условий.
Набор людей:
каждый выполняет порученную ему работу.
Команда:
существует общий контур ответственности,
внутри которого люди способны совместно производить результат.
Поэтому лид отвечает не только за отдельных людей и не только за список задач. Он отвечает за то, чтобы команда в целом была способна выполнять свою функцию.
Это другой уровень наблюдения.
Можно собрать сильных инженеров и получить слабую команду. Один человек будет знать production, второй — бизнес-логику, третий — инфраструктуру, но между ними не возникнет общего контура действия. Каждый локально компетентен, однако система в целом зависит от ручной координации, внешних решений и нескольких незаменимых людей.
Можно получить и обратную ситуацию: команда состоит не из самых сильных специалистов на рынке, но точно понимает свою функцию, владеет системой, умеет принимать решения, распределяет знания и не разваливается при первой неопределённости. Такая команда как система может оказаться значительно сильнее набора индивидуальных звёзд.
Главный вопрос этого модуля:
Способна ли данная конфигурация людей, знаний, полномочий и связей устойчиво выполнять свою функцию?
Зачем лиду системная модель команды
Без системной модели проблемы команды почти неизбежно сводятся к свойствам отдельных людей:
Разработчики медленные.
Middle недостаточно самостоятельный.
Senior слишком конфликтный.
QA опять задерживает выпуск.
DevOps не помогает.
Product приносит плохие требования.
Команда не проявляет ownership.
Каждое такое утверждение может содержать часть наблюдаемой реальности. Но само по себе оно ещё ничего не объясняет. Оно локализует проблему в человеке раньше, чем исследована система, внутри которой человек действует.
Middle может выглядеть несамостоятельным, потому что право принимать решения фактически принадлежит только лиду. QA может постоянно задерживать выпуск, потому что тестирование отделено от разработки и начинается лишь после завершения всей фичи. Senior может захватывать каждое обсуждение, потому что только у него есть знание о критической части системы. Product может приносить требования в последний момент, потому что у команды вообще нет устойчивого способа включаться в продуктовый discovery.
Системный взгляд не отменяет личную ответственность и не объявляет любое поведение следствием процесса. Он позволяет сначала установить причинность:
Что создаёт наблюдаемое поведение?
Недостаток компетенции?
Неясная ответственность?
Отсутствие полномочий?
Монополия на знание?
Конфликт целей?
Избыточная когнитивная нагрузка?
Плохая граница команды?
Внешняя зависимость?
Или сознательный отказ человека выполнять принятую ответственность?
Только после такого различения лид понимает, что именно нужно менять: человека, распределение знаний, границу ответственности, способ взаимодействия, состав команды, архитектуру решений или внешнюю организационную конструкцию.
Важно и другое: назвать команду системой — не значит превратить людей в шестерёнки. Машинная модель предполагает взаимозаменяемые детали, которые исполняют заданную извне функцию. Инженерная команда состоит из субъектов: они интерпретируют ситуацию, создают решения, спорят, обучаются, принимают ответственность и меняют саму систему. Поэтому задача лида — не механически управлять ресурсами, а создавать такой контур, внутри которого субъектность людей может складываться в совместное действие.
1. Функция команды
У системы должна быть функция. Если невозможно точно сказать, за какой результат отвечает команда, то перед нами, скорее всего, административная группа, а не самостоятельная производственная единица.
Формулировка функции не должна сводиться к перечню технологий или операций:
Слабая формулировка:
"Мы backend-команда. Пишем Java-сервисы и обрабатываем задачи из Jira".
Более точная формулировка:
"Команда отвечает за жизненный цикл заказа:
от создания и проверки доступности
до подтверждения, отмены и передачи статуса другим системам".
В первом случае команда описывает, что её участники делают. Во втором — какую часть работающей реальности она удерживает.
Функция команды должна позволять ответить на вопросы:
- какой пользовательский или бизнесовый результат принадлежит команде;
- какой участок продукта или платформы находится в её ответственности;
- что команда обязана поддерживать в рабочем состоянии;
- какие изменения она должна быть способна проводить;
- по каким признакам можно определить, что команда выполняет свою функцию;
- что перестанет происходить, если команда исчезнет.
Последний вопрос особенно полезен. Если после мысленного исчезновения команды остаётся только очередь неразобранных технических задач, функция команды не определена. Если становится ясно, какой продуктовый сценарий, сервис или организационная способность перестанет существовать, граница начинает проявляться.
2. Граница ответственности
Ответственность существует только тогда, когда определена её граница.
Команда должна понимать:
Что принадлежит нам?
Что не принадлежит нам?
Какие решения мы принимаем сами?
Какие решения требуют согласования?
За какой результат с нас можно спрашивать?
На что мы не можем реально повлиять?
Размытая граница создаёт два противоположных режима.
В первом команда считает своей ответственностью только написание кода:
Требования дал Product.
Архитектуру определил архитектор.
Инфраструктуру сделал DevOps.
Проверил QA.
В production выпустил Release Manager.
Если пользовательский сценарий не работает — это проблема между подразделениями.
Формально каждый выполнил свою операцию. Системного владельца результата нет.
Во втором режиме на команду возлагают ответственность за всё, но не дают соответствующих полномочий:
Команда отвечает за срок,
но не управляет приоритетами.
Команда отвечает за production,
но не имеет доступа к наблюдаемости и deployment.
Команда отвечает за архитектуру,
но каждое решение утверждается внешним комитетом.
Команда отвечает за качество требований,
но подключается после того, как решение уже продано заказчику.
Это не ответственность, а назначение виновного за результат, который команда не контролирует.
Поэтому лид должен сопоставлять три вещи:
ответственность
↔ полномочия
↔ доступные средства действия
Если команда отвечает за результат, она должна иметь достаточное право изменять способы его достижения. Если право принципиально находится снаружи, зависимость должна быть явно названа, а ответственность — разделена, а не фиктивно замкнута на команду.
3. Командная способность, а не сумма индивидуальных навыков
Наличие нужного специалиста ещё не означает наличия способности у команды.
Например, в команде может быть один человек, который умеет:
- разбираться с production-инцидентами;
- изменять CI/CD pipeline;
- диагностировать Kafka;
- согласовывать архитектурные решения;
- объяснять предметную область;
- выпускать релиз.
В отчёте о составе команды все компетенции присутствуют. В реальности они принадлежат одному человеку. Следовательно, команда не обладает этими способностями устойчиво — она арендует их у конкретного участника.
Нужно различать:
В команде есть человек, который это умеет.
Команда как система способна это делать.
Командная способность предполагает, что:
- знание не существует только в одной голове;
- действие не заблокировано отсутствием одного человека;
- другие участники понимают хотя бы основные принципы и ограничения;
- существуют способы передать и восстановить знание;
- право на действие не монополизировано без необходимости;
- команда способна воспроизвести результат в изменившихся условиях.
Для анализа можно составить карту способностей:
| Способность | Кто умеет | Кто может подменить | Где зафиксировано знание | Риск потери |
|---|---|---|---|---|
| Диагностика production | Анна | Игорь частично | Runbook отсутствует | Высокий |
| Изменение бизнес-правил | Сергей, Мария | Анна | ADR и domain guide | Низкий |
| Работа с deployment | Павел | Никто | Pipeline описан частично | Критический |
| Общение с внешним API | Мария | Сергей | Contract tests | Средний |
Такая карта показывает не seniority отдельных людей, а устойчивость способности команды действовать.
4. Архитектура принятия решений
Команда определяется не только тем, кто выполняет работу, но и тем, где принимаются решения.
Во многих командах декларируется автономность, но реальный механизм выглядит так:
Разработчик обнаруживает проблему.
Middle идёт к senior.
Senior идёт к лиду.
Лид идёт к архитектору.
Архитектор идёт к Product.
После нескольких встреч решение возвращается разработчику.
Внешне никто не бездействовал. Однако команда не способна преобразовать наблюдение в решение без длинной цепочки разрешений.
Лиду необходимо сделать видимой архитектуру решений:
- какие решения может принимать любой инженер;
- какие решения принадлежат владельцу конкретного компонента;
- какие решения требуют командного обсуждения;
- какие затрагивают другие команды;
- какие требуют продуктового или бизнесового выбора;
- какие действительно должны эскалироваться;
- кто имеет право остановить опасное изменение;
- кто принимает окончательное решение, если согласие не достигнуто.
Проблема не решается декларацией «проявляйте больше ownership». Если человек не понимает область допустимого решения или уже получал наказание за самостоятельность, он будет возвращать решение наверх.
Нормальная архитектура решений уменьшает ненужные согласования, но не уничтожает границы. Автономность не означает, что каждый решает всё. Она означает, что право решения находится настолько близко к знанию и последствиям, насколько это позволяет масштаб решения.
Локальное обратимое решение
→ принимается локально.
Решение, меняющее контракт нескольких команд
→ принимается совместно владельцами затронутых границ.
Решение, меняющее бизнесовый смысл продукта
→ включает Product и соответствующего владельца результата.
5. Распределение знания
Команда действует через знание. Поэтому распределение знания является частью её архитектуры.
Нужно видеть как минимум четыре вида знания:
- Предметное знание — как устроен пользовательский сценарий, бизнесовые правила и ограничения.
- Техническое знание — как устроен код, данные, интеграции и инфраструктура.
- Операционное знание — как система ведёт себя в production, как её диагностировать и восстанавливать.
- Историческое знание — почему были приняты существующие решения и какие альтернативы уже проверялись.
Если предметное знание находится только у Product Owner, команда превращается в исполнительный интерфейс. Если техническое знание находится только у лида, он становится обязательным посредником для каждого решения. Если операционное знание находится только у отдельной SRE-группы, разработчики не видят последствий собственного кода. Если историческое знание нигде не закреплено, команда будет циклически возвращаться к уже отвергнутым вариантам.
Распределение знания не означает, что все обязаны знать всё одинаково глубоко. Это создало бы невозможную нагрузку. Нужна осмысленная избыточность:
У области есть основной владелец.
Есть как минимум ещё один человек, способный продолжить действие.
Команда понимает границы и ключевые решения области.
Критическое знание имеет внешнюю опору: ADR, runbook, схема, contract test или рабочий пример.
Задача лида — не стать главным хранилищем знания. Если знание существует только в голове лида, команда выглядит сильной лишь до тех пор, пока лид лично присутствует во всех процессах.
6. Когнитивная нагрузка
Команда может быть формально укомплектована и при этом не справляться с системой, потому что объём удерживаемой сложности превышает её способность понимать происходящее.
Когнитивная нагрузка возникает не только из количества задач. Её создают:
- слишком большое число доменов;
- множество технологий без единой логики;
- нестабильные внешние зависимости;
- сложная инфраструктура;
- неявные бизнесовые правила;
- необходимость постоянно переключаться между контекстами;
- ручные процедуры;
- отсутствие понятных границ компонентов;
- десятки способов выполнить одно и то же действие;
- ответственность за системы, которые команда фактически не понимает.
Признаки избыточной когнитивной нагрузки:
Ни один человек не может объяснить систему целиком хотя бы на уровне основных контуров.
Любое изменение требует участия нескольких узких специалистов.
Команда постоянно забывает неочевидные ограничения.
После переключения на другую область требуется несколько дней, чтобы восстановить контекст.
Документация не помогает, потому что сама отражает сложность, а не разрезает её.
Инженеры знают операции, но перестают понимать причинность системы.
В Team Topologies когнитивная нагрузка является одним из оснований для проектирования командных границ: команда должна владеть таким участком системы, который она реально способна понимать и изменять. Подход связывает типы команд, способы их взаимодействия, закон Конвея и ограничение когнитивной нагрузки с организацией быстрого потока изменений. (Team Topologies: Fast Flow)
Ответом на перегрузку не всегда является найм ещё одного разработчика. Иногда необходимо:
- уменьшить границу ответственности;
- выделить сложную подсистему;
- убрать технологическую вариативность;
- создать платформенную возможность;
- передать команде недостающее знание;
- автоматизировать повторяющиеся операции;
- изменить архитектуру продукта;
- прекратить поддерживать часть ненужной сложности.
7. Автономность команды
Автономность — это не отсутствие руководителя и не право игнорировать другие команды. Это способность принимать достаточный класс решений и доводить собственную функцию до результата без постоянного внешнего ручного управления.
Для автономности команде необходимы:
- ясная функция;
- понятная граница ответственности;
- доступ к необходимой информации;
- компетенции для работы внутри границы;
- право принимать решения соответствующего масштаба;
- доступ к инструментам и средам;
- обратная связь от production и пользователей;
- известные способы взаимодействия с внешними владельцами.
Ложная автономность выглядит так:
"Вы автономная команда, поэтому разбирайтесь сами",
но при этом:
- приоритеты меняются снаружи;
- архитектурные решения принимаются снаружи;
- production закрыт;
- бюджет и инструменты недоступны;
- внешние команды не обязаны отвечать;
- за сроки всё равно отвечает команда.
Это не автономность, а изоляция при сохранённой ответственности.
Есть и противоположная подмена: команда получает полномочия, но возвращает каждое решение лиду. Тогда лид становится центральным процессором, а остальные участники — периферией исполнения.
Зрелость команды проявляется не в том, что лид исчезает, а в том, что его участие перестаёт быть техническим условием каждого действия. Он удерживает систему ответственности, сложные границы и направление, но не подменяет собой распределённое мышление команды.
8. Внутренняя связность и качество коммуникации
Коммуникация важна не как требование быть приятными друг к другу, а как механизм передачи реальности внутри системы.
Команда теряет связность, когда:
- проблема известна одному участнику, но не становится знанием команды;
- несогласие скрывается до момента реализации;
- решения принимаются в личных переписках и не возвращаются в общий контур;
- человек сообщает о действиях, но не сообщает о рисках и неизвестности;
- технический язык не переводится в последствия для продукта;
- Product, QA и разработка удерживают разные версии того, что строится;
- конфликт интерпретируется только как личная несовместимость, хотя стороны защищают разные ответственности;
- встречи существуют, но не создают решений.
Качество коммуникации можно проверять не количеством сообщений и встреч, а тем, насколько точно команда способна совместно ответить:
За что мы отвечаем?
Что сейчас является главным изменением?
Какие ограничения нельзя нарушить?
Где находится неизвестность?
Какие решения уже приняты?
Кто должен действовать дальше?
Где требуется помощь или эскалация?
Если ответы участников принципиально различаются, коммуникация не выполнила системную функцию, даже если календарь заполнен встречами.
9. Внешние зависимости и способы взаимодействия
Команда никогда не существует полностью изолированно. Она зависит от продукта, платформы, инфраструктуры, безопасности, внешних сервисов, других доменов и организационных решений.
Наличие зависимости само по себе не является дефектом. Проблема возникает, когда зависимость:
- не названа;
- не имеет владельца;
- не имеет понятного способа взаимодействия;
- требует постоянных персональных договорённостей;
- блокирует команду на неопределённый срок;
- заставляет обе стороны удерживать лишнюю сложность;
- выдаётся за автономность одной из команд.
Для каждой значимой зависимости лид должен понимать:
| Вопрос | Содержание |
|---|---|
| От кого зависит команда? | Конкретная команда или владелец, а не абстрактный отдел |
| Что именно требуется? | Решение, сервис, данные, консультация, доступ или изменение |
| Кто владеет результатом? | Где находится окончательная ответственность |
| Каков режим взаимодействия? | Совместное исследование, потребление сервиса или временная помощь |
| Как завершается взаимодействие? | Условие выхода, стабильный контракт или переданная способность |
| Что происходит при сбое? | Эскалация, fallback, ограничение функции или остановка |
Team Topologies как язык командной архитектуры
Team Topologies предлагает не универсальную схему организационной структуры, а язык для различения типов команд и способов их взаимодействия. В модели выделяются четыре фундаментальных типа команд: stream-aligned team, platform team, enabling team и complicated-subsystem team. (Team Topologies: Key Concepts)
Stream-aligned team
Команда выровнена по потоку ценности: пользовательскому сценарию, продукту, домену или другой целостной области изменений. Её смысл не в технологии, а в способности проводить изменения в своей области без постоянной передачи работы между функциональными подразделениями.
Platform team
Платформенная команда создаёт внутренний продукт, который уменьшает нагрузку на stream-aligned teams и даёт им возможность самостоятельно использовать инфраструктурные или технические возможности. Платформа не должна становиться ещё одним центром заявок и ручных разрешений.
Enabling team
Enabling team временно помогает другим командам освоить недостающую способность, технологию или способ работы. Её результат — не постоянная зависимость, а возросшая самостоятельность принимающей команды.
Complicated-subsystem team
Команда владеет подсистемой, требующей специализированного знания, которое было бы чрезмерной нагрузкой для stream-aligned team: например, сложный алгоритмический, математический или технический контур.
Кроме типов команд Team Topologies различает три режима взаимодействия: Collaboration, X-as-a-Service и Facilitating. (Team Interaction Modeling)
Collaboration
Две команды временно работают вместе, когда необходимо исследование, обучение или совместное обнаружение новой границы. Постоянная «коллаборация» без срока и условия завершения обычно означает, что ответственность так и не была разделена.
X-as-a-Service
Одна команда предоставляет другой понятную и пригодную к самостоятельному использованию возможность. Это не просто наличие API: необходимы ясный контракт, документация, предсказуемость и нормальный опыт потребления.
Facilitating
Одна команда временно помогает другой приобрести способность или устранить препятствие. Взаимодействие должно уменьшать зависимость, а не закреплять роль постоянного посредника.
Лиду не требуется механически перекрашивать существующие отделы в четыре типа. Ценность модели появляется, когда она позволяет задать точные вопросы:
Почему эти люди находятся в одной команде?
По какому потоку ценности проведена её граница?
Какую когнитивную нагрузку она удерживает?
Какая зависимость между командами необходима?
Какой режим взаимодействия существует фактически?
Когда временное взаимодействие должно закончиться?
Не выдаём ли мы постоянную неясность за Collaboration?
Не называем ли мы платформой отдел ручного обслуживания заявок?
Не создаёт ли enabling-команда вечную зависимость от своих экспертов?
10. Способность команды восстанавливаться
В этом модуле речь идёт не о восстановлении технического сервиса после production-инцидента — это отдельная тема reliability. Здесь рассматривается устойчивость самой команды как действующей системы.
Команда должна сохранять способность действовать, если:
- ключевой человек временно недоступен;
- один из участников ушёл;
- изменились приоритеты;
- появилась новая внешняя зависимость;
- произошла реорганизация;
- обнаружилось, что прежнее решение неверно;
- объём работы резко вырос;
- команда получила новую область ответственности.
Устойчивость не означает, что любое изменение проходит без потерь. Она означает, что команда умеет обнаружить потерю способности, перестроить знания, перераспределить ответственность и восстановить управляемое действие.
Признаки хрупкой команды:
Без лида никто не принимает решения.
Без одного senior нельзя выпускать изменения.
После ухода Product Owner исчезает знание о смысле продукта.
Новая технология автоматически отдаётся единственному человеку, который её уже знает.
Любая срочность уничтожает существующий порядок работы.
После ошибки команда ищет виновного, но не меняет механизм, который воспроизводит ошибку.
Лид увеличивает устойчивость через распределение знания, ясные границы, резервирование критических способностей, документацию решений, постепенную передачу полномочий и регулярную проверку командной архитектуры.
Системные дисфункции команды
1. Группа вокруг героя
Один сильный инженер понимает систему, принимает решения, делает сложные задачи и исправляет ошибки остальных. Команда выглядит производительной, пока герой доступен. Остальные постепенно теряют способность действовать самостоятельно, потому что быстрее спросить или передать задачу ему.
Проблема не только в перегрузке героя. Сама команда не возникает как субъект.
2. Лид как центральный маршрутизатор
Любая информация, договорённость и решение проходят через лида. Он соединяет Product с разработчиками, backend с frontend, команду с инфраструктурой, senior с middle.
Такой лид может быть чрезвычайно занят и одновременно оставаться главным ограничением системы. Его исчезновение обрывает связи, которые не были построены напрямую.
3. Команда без собственной функции
Людей объединяет технология или административная принадлежность, но не общий результат. Сегодня они помогают одному продукту, завтра другому, послезавтра закрывают срочные задачи третьего подразделения.
У команды нет устойчивой предметной области, памяти решений и возможности отвечать за последствия изменений.
4. Ответственность без полномочий
Команда отвечает за результат, но не управляет решениями, доступами, зависимостями или приоритетами. От неё требуют ownership, сохраняя все значимые права снаружи.
5. Все отвечают за всё
Формально провозглашено коллективное владение, но конкретный владелец решения отсутствует. Работа перемещается к тому, кто первым отреагировал или не смог отказаться. В критический момент каждый считает, что действовать должен кто-то другой.
Коллективная ответственность не исключает явного владельца действия.
6. Функциональный конвейер
Аналитики анализируют, разработчики пишут код, QA тестирует, DevOps выпускает. Каждый оптимизирует свою операцию, но никто не владеет целостной способностью произвести работающий пользовательский результат.
7. Ручное управление под названием Agile
У команды есть daily, planning и retro, но реальные решения принимает лид или внешний менеджер. Участники отчитываются о действиях, ожидают назначения следующей задачи и не управляют собственной областью ответственности.
Проблема здесь не в неправильном проведении церемоний. Церемонии скрывают отсутствие командной субъектности.
8. Неопределённое взаимодействие между командами
Две команды постоянно «работают вместе», но никто не может сказать, где заканчивается ответственность одной и начинается ответственность другой. Каждое изменение требует новых переговоров, а временная координация превращается в постоянную организационную зависимость.
Диагностика команды как системы
Лид может проводить диагностику в следующей последовательности.
Шаг 1. Определить функцию
Какой результат производит команда?
Какую часть реальности продукта она удерживает?
Что перестанет работать, если команды не станет?
Шаг 2. Провести границу ответственности
Что принадлежит команде?
Что находится снаружи?
Где ответственность не совпадает с полномочиями?
Шаг 3. Построить карту способностей
Что команда должна уметь, чтобы выполнять функцию?
Какие способности существуют только у отдельных людей?
Каких способностей внутри команды вообще нет?
Шаг 4. Сделать видимой архитектуру решений
Кто принимает какие решения?
Какие решения без необходимости уходят наружу или наверх?
Где решение блокируется отсутствием одного человека?
Шаг 5. Нанести распределение знания
Где находится предметное, техническое, операционное и историческое знание?
Какое знание невозможно восстановить?
Где нужна осмысленная избыточность?
Шаг 6. Проверить когнитивную нагрузку
Способна ли команда понимать принадлежащую ей область?
Какая сложность является необходимой?
Какая сложность создана плохими границами и инструментами?
Шаг 7. Описать внешние зависимости
От кого зависит команда?
Какой режим взаимодействия используется?
Кто владеет зависимостью?
Есть ли условие завершения временного взаимодействия?
Шаг 8. Проверить устойчивость
Что произойдёт при выпадении ключевого человека?
Какая способность исчезнет первой?
Как команда обнаружит и восстановит потерю?
Практический разбор
Исходная ситуация
Есть команда из шести человек:
- Tech Lead;
- два senior backend-разработчика;
- два middle backend-разработчика;
- QA-инженер.
Команда называется командой заказов. При этом:
- смысл бизнесовых правил знает Product Owner;
- архитектурные решения утверждает внешний архитектор;
- deployment выполняет отдельный DevOps;
- только Tech Lead имеет доступ к production-логам;
- один senior знает интеграцию с платёжной системой;
- QA подключается после завершения разработки;
- изменения схемы данных согласуются с отдельной DBA-группой;
- при отсутствии лида разработчики откладывают спорные решения.
На уровне списка сотрудников команда выглядит укомплектованной. На уровне системной способности она не владеет целостным контуром заказов.
Системный разбор
Функция: заявлено владение заказами, но фактически команда владеет только написанием части backend-кода.
Граница: ответственность за результат пересекает несколько внешних центров решений.
Способности: production, deployment, предметное моделирование и изменение данных не принадлежат команде полностью.
Архитектура решений: лид и внешний архитектор образуют обязательную цепочку согласования.
Знание: платёжная интеграция и production монополизированы отдельными людьми.
Автономность: команда зависит от внешних людей не только при редких исключениях, но и в обычном изменении системы.
Устойчивость: отсутствие лида или senior по платежам останавливает существенную часть действий.
Возможные изменения
Задача лида не сводится к требованию «работать самостоятельнее». Он может последовательно изменить конструкцию:
- Уточнить вместе с Product границу функции команды и зафиксировать, какой результат заказного контура ей принадлежит.
- Передать команде доступ к наблюдаемости production в пределах её ответственности.
- Разделить архитектурные решения на локальные и межкомандные, убрав внешнее согласование локальных обратимых решений.
- Создать второго владельца платёжной интеграции через совместную работу, разбор решений и contract tests.
- Подключить QA к пониманию сценариев и рисков до завершения реализации.
- Определить стабильный способ взаимодействия с платформой и DBA вместо персональных запросов.
- Передавать middle-разработчикам ограниченные классы решений с понятной границей последствий.
- Зафиксировать критические знания в ADR, runbook и схеме домена.
После этого команда не обязательно станет полностью независимой. Но её зависимости будут осознанными, а внутри собственной границы появится реальная способность действовать.
Практическое задание: Team System Map
Участник выбирает текущую или прошлую команду и описывает её не через оргструктуру, а как действующую систему.
1. Назначение команды
Название команды:
Функция:
Пользовательский или бизнесовый результат:
Часть продукта или платформы, которой владеет команда:
Что перестанет происходить, если команда исчезнет:
2. Граница ответственности
Команда отвечает за:
Команда не отвечает за:
Команда может решать самостоятельно:
Команда должна согласовывать:
Ответственность без достаточных полномочий:
3. Карта способностей
Какие способности необходимы команде:
Какими способностями команда владеет устойчиво:
Какие способности принадлежат одному человеку:
Каких способностей внутри команды нет:
Какие способности необходимо передать или создать:
4. Карта знаний
Предметное знание:
Техническое знание:
Операционное знание:
Историческое знание:
Критические точки монополии знания:
5. Архитектура решений
Решения отдельного инженера:
Решения владельца компонента:
Командные решения:
Межкомандные решения:
Продуктовые решения:
Решения, которые сейчас без необходимости уходят наверх:
6. Внешние зависимости
Зависимость:
Владелец:
Что получает команда:
Режим взаимодействия:
Условие завершения или стабильный контракт:
Риск:
7. Когнитивная нагрузка
Какие домены удерживает команда:
Какие технологии обязана понимать:
Где происходит постоянное переключение контекста:
Какая сложность необходима:
Какую сложность можно удалить, передать или скрыть платформой:
8. Устойчивость
Критические люди:
Способности, исчезающие при их отсутствии:
Механизмы передачи знания:
Сценарий восстановления:
9. Итоговый диагноз
Три главных системных ограничения команды:
1.
2.
3.
Изменение с наибольшим системным эффектом:
Что должен перестать делать лид лично:
Что команда должна научиться удерживать сама:
Критерии выполненного задания
Team System Map считается выполненной, если:
- функция команды описана через результат, а не через технологию или набор операций;
- граница ответственности отделена от внешних зависимостей;
- ответственность сопоставлена с полномочиями;
- индивидуальные навыки отделены от устойчивых командных способностей;
- показано реальное, а не официальное место принятия решений;
- найдены точки монополии знания;
- внешние зависимости названы конкретно;
- оценена когнитивная нагрузка;
- описан хотя бы один сценарий выпадения критического участника;
- предложено не абстрактное «улучшение коммуникации», а изменение командной конструкции.
Что лид должен унести из этого модуля
Лид должен перестать смотреть на команду только как на сумму сотрудников и начать видеть:
функцию;
границу ответственности;
способности;
распределение знания;
архитектуру решений;
когнитивную нагрузку;
автономность;
внешние зависимости;
режимы взаимодействия;
устойчивость.
Главное различение модуля:
Если результат существует только благодаря постоянному личному вмешательству лида,
лид пока не построил командную систему.
Он сам временно заменяет её собой.
Смысл leadership здесь не в устранении лида и не в создании команды, которой никто не нужен. Смысл в том, чтобы лид перестал быть единственным местом, где соединяются знание, решение, ответственность и действие. Эти связи должны стать свойствами самой команды.
Граница со следующим модулем
Этот модуль отвечает на вопрос:
Как устроена команда, которая должна производить результат?
Следующий модуль — «Delivery: как доводить работу до результата» — отвечает на другой вопрос:
Как конкретная работа проходит через эту систему от требования до работающего изменения?
Поэтому здесь рассматриваются функция команды, её границы, знания, полномочия, когнитивная нагрузка, автономность и зависимости.
А в модуле delivery будут рассматриваться:
- путь задачи;
- очереди и WIP;
- декомпозиция и slicing;
- MVP;
- Definition of Ready и Definition of Done;
- блокеры конкретной поставки;
- управление прогрессом;
- flow-метрики;
- DORA-метрики;
- превращение работы в поставленный результат.
Команда как система и delivery как поток связаны причинно, но не совпадают:
Устройство команды создаёт условия delivery.
Delivery делает последствия этого устройства наблюдаемыми.
