Как построить команду ИТ-проекта: модель Такмана и топологии команд
«Мы взяли лучших специалистов. Почему они не работают как команда?»
Вы наняли суперзвёзд: лучшего бэкенд-разработчика, топового фронтендера, гениального архитектора. А через три месяца проект проваливается, команда не сработалась. Проблема не в людях — проблема в том, что вы взяли лучших специалистов и просто посадили их в одну комнату. Команда не появляется автоматически, её нужно строить.
Пять стадий по Такману — почему нельзя перескочить ни одну
Брюс Такман описал пять стадий развития команды, каждая требует разного стиля управления.
Формирование (Forming). Люди вежливы, но насторожены, процессы отсутствуют, все ждут, кто будет лидером. Эмоции — воодушевление, смешанное с тревогой. Что делать руководителю: чётко ставить цели, определять роли, давать структуру. Пример: первая встреча команды, все говорят о себе, никто не говорит о проблемах.
Шторм (Storming). Появляются конфликты, команда проверяет границы, кто-то доминирует, кто-то уходит в тень. Эмоции — разочарование, конфликты, борьба за влияние. Что делать руководителю: не избегать конфликта, направлять в конструктивное русло. Подробнее — в статье Конфликты в ИТ-команде. Пример: разработчик и тестировщик ссорятся, аналитик не согласен с требованиями, команда раскалывается.
Нормирование (Norming). Конфликты утихают, появляются общие нормы, доверие, команда начинает работать как единое целое. Эмоции — спокойствие, уверенность, принятие. Что делать руководителю: делегировать, поощрять самостоятельность, давать больше автономии. Пример: команда сама распределяет задачи в спринте, ретроспективы проходят конструктивно.
Работа (Performing). Команда автономна, мотивирована, работает как единый организм, решения принимаются быстро и эффективно. Эмоции — удовлетворение, гордость, вовлечённость. Что делать руководителю: стать «щитом» для команды, ставить амбициозные цели, убирать внешние блокеры. Пример: команда сама управляет спринтами, решает сложные технические задачи и выдаёт результаты выше ожидаемых.
Расформирование (Adjourning). Проект завершён, команда расформировывается. Эмоции — ностальгия, грусть, иногда облегчение. Что делать руководителю: провести ретроспективу (извлечь уроки), помочь с переходом в другие проекты. Пример: финальная ретроспектива, прощание, переход на другие проекты.
Почему это важно в ИТ
Нельзя перескочить стадию — попытка сразу делегировать на стадии «Формирование» приведёт к хаосу. Возможно возвращение на предыдущие стадии при смене состава — пришёл новый разработчик — команда может откатиться на стадию «Шторм». Удалённые команды могут дольше находиться на стадии «Формирование» — без личного контакта доверие строится медленнее. Регулярно оценивайте стадию и корректируйте свой стиль управления под текущую стадию.
Топологии команд — модель Скелтона и Пайса
Модель описывает четыре типа команд в ИТ-организации.
Потоковая команда (Stream-aligned). Основная команда, отвечающая за сквозную доставку ценности. Разрабатывает и поддерживает продукт от начала до конца. Пример: команда разработки платёжного сервиса, включает аналитика, разработчиков, тестировщиков, DevOps. Размер 5–9 человек. Принцип: команда может самостоятельно доставить ценность без внешних зависимостей.
Обучающая команда (Enabling). Помогает потоковым командам осваивать новые технологии. Задача — обучение, консультации, внедрение новых практик. Пример: группа внедрения DevOps, помогает командам настраивать CI/CD, но не делает это за них. Размер 2–5 человек. Принцип: не делают за команду, а учат её делать.
Команда сложной подсистемы (Complicated-subsystem). Создаёт и поддерживает компоненты, требующие глубокой экспертизы. Пример: команда ядра базы данных, требует глубоких знаний, которых нет у потоковых команд. Размер 3–6 человек. Принцип: глубокая экспертиза в узкой области.
Платформенная команда (Platform). Предоставляет внутренние сервисы для потоковых команд. Разрабатывает и поддерживает платформу (инфраструктура, CI/CD, облачные сервисы). Пример: команда CI/CD, облачной инфраструктуры. Размер 3–7 человек. Принцип: делают так, чтобы потоковые команды могли не думать об инфраструктуре.
Правила взаимодействия: сотрудничество — тесная синхронизация между командами (платформенная команда и потоковая вместе проектируют новый сервис); услуга — минимальное взаимодействие, формальный запрос (потоковая команда отправляет заявку на CI/CD); облегчение — обучение, без исполнения (обучающая команда проводит воркшоп, но не пишет код).
Что в понедельник утром
Определите стадию вашей команды по Такману — если не знаете, спросите анонимно. Скорректируйте стиль управления под стадию. Подумайте, какого типа ваша команда по топологии. Создайте устав команды (правила взаимодействия, общие цели). Подробнее — в статье Устав ИТ-проекта. Проверьте психологическую безопасность — статья Психологическая безопасность в ИТ-команде.
Заключение
Лучшие специалисты не становятся командой автоматически. Модель Такмана показывает стадии развития команды и нужный стиль управления. Топологии команд помогают понять структуру. И главное: психологическая безопасность — фундамент всего.
На воркшопах курса «Мастер управления IT-проектами» мы определяем стадию вашей команды и выбираем правильные действия для каждой. Подробнее о курсе →