T-Shaped модель в IT: реальная польза или скрытая ловушка

T-Shaped — не лицензия на «уметь всё»

В исходной трактовке T-Shaped — это не магический гибрид аналитика, разработчика, тестировщика и администратора в одном бейдже. Вертикаль — глубокая экспертиза в своей области. Горизонталь — понимание соседних зон, чтобы не общаться через стену из тикетов, уточнений и взаимного раздражения.

Автор на Хабре напоминает: концепция появилась не как способ заменить несколько ролей одним сотрудником, а как способ улучшить взаимодействие между ролями. Это важная разница. Потому что в реальном IT её часто теряют первой.

Нормальный T-Shaped-аналитик остаётся аналитиком, но понимает API, интеграции, асинхронное взаимодействие сервисов и технический контекст решений. Нормальный разработчик не становится бизнес-аналитиком на полставки, но хотя бы понимает, зачем вообще существует процесс, который он кодит. Нормальный тестировщик не обязан проектировать инфраструктуру, но должен понимать, где система может развалиться на стыках.

А вот когда T-Shaped начинают читать как «пусть один человек закроет несколько ролей одновременно», это уже не эволюция. Это экономия на спичках рядом с бензином.

Почему старая изоляция ролей больше не держится

В материале хорошо зафиксирована боль последних лет: раньше роли в командах были заметно более изолированы. Разработчик писал код, тестировщик тестировал, аналитик занимался требованиями, администратор отвечал за инфраструктуру. Системы были проще технически и организационно, поэтому такая модель ещё как-то жила.

Сейчас вокруг не один монолит «на несколько экранов», а набор сервисов, интеграции, внешние API, очереди, распределённые команды, CI/CD, Kafka, облачная инфраструктура и постоянные изменения. В такой среде специалист, который видит только свой кусок, становится не узким экспертом, а точкой задержки.

Типовой лог выглядит так:

analyst: требование готово
backend: тут не описан контракт API
qa: а что должно быть при повторной доставке события?
devops: сервис не поднимается без переменной окружения
business: почему опять перенос?

И дальше начинается классика: дополнительные согласования, пересборка решения уже по ходу реализации, патчи поверх патчей. Костыль на костыле, сверху бантик из «кросс-функциональности».

Здесь T-Shaped действительно полезен. Не потому, что все внезапно стали универсальными солдатами. А потому, что команда быстрее понимает ограничения соседей. Аналитик не рисует требования в вакууме. Разработчик раньше замечает конфликт с бизнес-логикой. Тестировщик лучше видит интеграционные риски. Инфра не узнаёт о релизе в пятницу вечером из чата.

Что проверить у себя, пока это не стало HR-мемом

Главная проблема, по версии автора Хабра, не в самой концепции, а в том, как её начали трактовать. Для веб-команд это особенно актуально: фронт, бэк, SEO, аналитика, дизайн, инфраструктура и продукт давно живут в одной цепочке поставки. Если одно звено делает вид, что соседних не существует, пользователь получает не «сложную систему», а битую форму, медленный релиз и странный трафик.

Проверка простая. Если у вас T-Shaped означает «разработчик должен ещё тестировать, писать требования, чинить деплой и отвечать за продуктовые метрики», это не развитие специалиста. Это маскировка нехватки людей.

Если же T-Shaped означает «бэкендер понимает контракт с фронтом, аналитик понимает ограничения API, QA понимает интеграции, а девопс не узнаёт о новой зависимости после падения пайплайна» — жить можно.

Минимальный чек для команды:

grep -R "не моя зона"./team-process
grep -R "пусть разберется один человек"./hiring
grep -R "потом уточним"./requirements
grep -R "на проде проверим"./release-plan

Если совпадений много — проблема не в букве T. Проблема в том, что вы используете красивый термин как костыль для плохой архитектуры команды.

T-Shaped работает, когда глубина остаётся глубиной, а горизонталь помогает стыковаться с соседями. Как только горизонталь превращается в обязанность закрывать чужие роли, это уже не инженерная зрелость. Это долг, который прод однажды взыщет. Бэкапы делайте заранее.