Специалист с опытом работы в IT с 2006 года поставил под сомнение один из самых модных карьерных ярлыков последних лет: T-Shaped специалист не всегда делает команду сильнее. По данным Habr / Карьера, проблема не в самой модели, а в том, как рынок превратил ее из способа лучше понимать соседние роли в удобное оправдание для перегрузки сотрудников. Для русскоязычного IT это история не про красивую теорию, а про повседневную практику найма, роста и выгорания.
Автор материала, системный аналитик и руководитель команд аналитики Александр, описывает довольно знакомую для отрасли эволюцию. Еще 10-15 лет назад роли в разработке были заметно жестче: разработчик писал код, тестировщик тестировал, аналитик работал с требованиями, администратор отвечал за инфраструктуру. При такой схеме можно было годами оставаться внутри своей функции и не терять эффективность. Но чем сложнее становились системы, тем дороже обходилась изолированность. Когда в проекте уже не один монолит, а десятки сервисов, внешние API, очереди, облака, CI/CD и распределенные команды, сотрудник, который понимает только свой кусок, начинает тормозить всю сборку. В этом смысле T-Shaped специалист появился не как карьерная мантра, а как ответ на усложнение разработки.
Изначальная идея этой модели вполне здравая. Вертикаль буквы T означает глубокую экспертизу в своей профессии, горизонталь — понимание смежных направлений и умение нормально разговаривать с соседями по команде. Для аналитика это означает не превращаться в архитектора, DevOps-инженера и тимлида одновременно, а понимать контекст: как устроены API, чем отличается синхронное взаимодействие от асинхронного, почему интеграции ломаются не только из-за «неполных требований». Такой кругозор снижает количество согласований, сокращает число переделок и делает коммуникацию менее мучительной. Проблема началась в тот момент, когда рынок услышал только горизонталь: мол, хороший специалист должен знать все вокруг. А вот про вертикаль, то есть про собственную сильную профессию, многие компании почему-то решили не вспоминать.
На этом месте статья попадает в нерв отрасли. Под вывеской T-Shaped в компаниях часто продается совсем другая конструкция: один сотрудник закрывает сразу несколько ролей, много участвует во всем подряд и выглядит незаменимым. Автор приводит пример аналитика, который постоянно был в архитектурных обсуждениях, спорил про frontend, участвовал в инфраструктурных вопросах, подключался к тестированию, процессам разработки и организации работы команды. Со стороны это выглядело как образцовый T-Shaped специалист, который «держит систему». На деле основной профиль начал проседать: документация задерживалась, требования прорабатывались хуже, задачи зависали, а время уходило на бесконечные встречи. Когда этот человек уволился, команда сначала испугалась, а потом выяснила неприятную, но полезную вещь: система не рухнула. Более того, местами стало даже проще, потому что зоны ответственности прояснились, а коммуникация очистилась от лишнего шума.
Здесь важный вывод для руководителей и HR. Высокая видимость сотрудника еще не равна высокой ценности для системы. Человек, который присутствует в каждом обсуждении, не обязательно усиливает команду; иногда он просто становится точкой концентрации хаоса. Зрелая организация строится не вокруг героев, а вокруг понятных ролей, процессов и распределенной экспертизы. Если под фразой «нам нужен T-Shaped специалист» на деле скрывается запрос «пусть один человек побудет аналитиком, архитектором, проектным менеджером и немного DevOps», это уже не развитие компетенций, а обычная экономия на штате. С красивым названием, что особенно удобно для вакансий и performance review.
Не менее жестко автор проходится по идее ранней универсальности. Попытка сделать T-Shaped модель стартовой точкой для junior-специалиста обычно заканчивается одинаково: человек читает про архитектуру, базы данных, frontend, backend, AI, DevOps и еще десяток тем, но в итоге не успевает выстроить базовую профессиональную опору. Появляется широкий кругозор без настоящей глубины. Для начинающего аналитика, пишет автор, важнее сначала собрать крепкую вертикаль: научиться работать с требованиями, декомпозировать задачи, структурировать информацию, видеть причинно-следственные связи. И только после этого расширяться в смежные области. Иначе рынок получает не универсального бойца, а специалиста, который может поддержать разговор обо всем, но не вытягивает сложную работу ни в одной зоне по-настоящему.
Самой полезной модель T-shaped, по мысли автора, становится на middle-уровне. Именно здесь специалист уже уверенно стоит на своей профессиональной базе и может расширять кругозор без потери качества. Для системного анализа это особенно заметно: аналитик, который понимает принципы интеграций, ограничения разработки и логику инфраструктуры, меньше генерирует нереалистичных требований и быстрее договаривается с командой. Для бизнеса эффект тоже вполне прикладной: меньше пересборок решений по ходу проекта, меньше лишних встреч, меньше зависимостей от одного «знающего всех и все» сотрудника. Для разработчиков это означает более адекватную постановку задач, для продактов — более честную оценку сложности, для IT-директоров — меньше риска, что ключевой процесс держится на одном перегруженном человеке.
На практике спор о T-Shaped модели уже перестал быть спором о терминах. Рынку придется решить, что именно он хочет поощрять: зрелую межфункциональность или старую добрую привычку перекладывать несколько ролей на одного заметного сотрудника. Пока одни команды ищут баланс между глубиной и шириной, другие продолжают нанимать «универсалов», а потом удивляются, почему вместе с ними уходит половина неформальной архитектуры процесса.