T-Shaped специалист: эволюция или ловушка современного IT?

Привет, Хабр! Меня зовут Александр, я работаю в IT с 2006 года, последние годы занимаюсь системным анализом и управлением командами аналитики.

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

Для кого-то T-Shaped — это специалист, который понимает систему шире своей основной области и умеет эффективно взаимодействовать со смежными ролями. Для кого-то — тот, кто должен «уметь всё понемногу». А иногда под этим термином вообще начинают подразумевать сотрудника, который фактически совмещает несколько ролей одновременно. Короче говоря, с T-Shaped все далеко не так однозначно.

Почему рынок вообще пришел к T-Shaped

Если посмотреть на разработку десяти- или пятнадцатилетней давности, роли внутри команд были значительно более изолированы друг от друга. Разработчик писал код, тестировщик тестировал, аналитик занимался требованиями, администратор отвечал за инфраструктуру. Между ролями существовали достаточно жесткие границы, а сами системы были заметно проще как технически, так и организационно.

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

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

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

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

Но когда вокруг десятки сервисов, интеграций, внешних API, очередей, распределенные команды, CI/CD, Kafka, облачная инфраструктура и постоянные изменения, изолированность начинает стоить слишком дорого. Например, если аналитик вообще не понимает, как устроены API или асинхронное взаимодействие сервисов, команда начинает тратить огромное количество времени на дополнительные согласования, уточнения и пересборку решений уже по ходу реализации. Возникают коммуникационные потери, которые начинают заметно влиять на скорость и качество разработки.

Сложность систем начала требовать от специалистов лучшего понимания друг друга. Со временем индустрия словно услышала только вторую часть концепции — «понимай все вокруг» — и постепенно начала забывать про первую: «оставайся сильным специалистом в своей основной области». 

Когда T-Shaped мешает системе

Человек-оркестр. В одной из наших команд был аналитик, которого долгое время воспринимали как практически незаменимого человека. Он был буквально везде. Архитектурные обсуждения? Он там. Инфраструктурные вопросы? Тоже там. Споры про frontend, процессы разработки, тестирование, CI/CD, организация работы команды — он участвовал практически во всем.

Такие специалисты обычно действительно очень заметны. Они постоянно находятся в коммуникации, участвуют в огромном количестве обсуждений. Со стороны он выглядел как очень сильный T-Shaped-специалист. Казалось, что человек глубоко вовлечен во все происходящее и буквально «держит систему». Но со временем начала проявляться обратная сторона. Чем больше специалист распылялся между разными направлениями, тем сильнее страдала его основная вертикаль. Документация все чаще задерживалась, требования становились менее проработанными, задачи зависали, а значительная часть времени уходила не на выполнение своей основной роли, а на постоянное участие во всем вокруг.

В какой-то момент внутри команды становилось все сложнее объяснить, где именно находится его основная ценность как аналитика. Когда он сообщил об увольнении, первая реакция у многих была почти панической: «Сейчас все рухнет». Через месяц после ухода выяснилось, что процессы не развалились. Более того, часть коммуникации стали проще, а зоны ответственности внутри команды понятнее.

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

И, наверное, здесь проходит тонкая грань между зрелым специалистом и специалистом, который просто постоянно находится везде одновременно.

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

Человек начинает читать про архитектуру, DevOps, базы данных, frontend, backend, AI, пытается сразу охватить все вокруг, но в итоге не успевает нормально выстроить собственную базу. Появляется ощущение широкого кругозора, но при этом не появляется глубины. Для аналитика на junior-этапе гораздо важнее сначала сформировать прочную вертикаль: научиться работать с требованиями, декомпозировать задачи, структурировать информацию. 

Перегруженный специалист. В компаниях, где высокая вовлеченность начинает восприниматься как главный показатель ценности сотрудника, специалисты начинают одновременно быть аналитиками, архитекторами, проектными менеджерами и частично разработчиками, частично DevOps-инженерами.

Снаружи это может выглядеть как высокий профессионализм, но внутри скрывается хроническая перегрузка и размытая ответственность и постепенное выгорание. Иногда складывается ощущение, что под T-Shaped некоторые компании на самом деле начинают продавать идею «делать больше меньшим количеством людей». Зрелая система должна быть устроена наоборот, она не должна держаться на одном «герое».

Когда T-Shaped усиливает системный анализ

Middle-уровень, на мой взгляд, становится тем самым этапом, где T-Shaped начинает давать максимальный эффект. К этому моменту специалист уже достаточно уверенно чувствует себя внутри своей основной роли. У него появляется понимание процессов разработки, опыт взаимодействия с командой и способность видеть систему немного шире собственного набора задач.

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

В моей практике чаще всего наибольшую отдачу дают четыре направления:

• архитектура приложений;

• интеграции и API;

• базы данных и SQL;

• инфраструктура и процессы поставки изменений.

Конечно, аналитик не должен стать архитектором, разработчиком или DevOps-инженером. Но именно эти области чаще всего влияют на качество принимаемых аналитиком решений.

В одной из наших команд аналитик довольно глубоко погрузился в интеграционные процессы и особенности работы Kafka. При этом он не пытался «стать разработчиком»  и не лез в реализацию там, где это было не нужно. Но благодаря пониманию архитектурных ограничений он начал гораздо точнее описывать сценарии взаимодействия сервисов, раньше замечать потенциальные проблемы и задавать правильные вопросы еще на этапе проектирования.

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

В таких командах аналитики, которые разбираются в API, умеют читать технические логи и понимают базовые архитектурные принципы, обычно начинают быстрее находить причины проблем и эффективнее взаимодействовать с разработчиками.При этом они не перестают быть аналитиками.Наоборот, дополнительная экспертиза начинает усиливать их основную профессию.

На практике это быстро стало заметно: количество возвратов задач на доработку снизилось, обсуждения между аналитикой и разработкой стали занимать меньше времени, а часть проблем начала выявляться ещё до этапа реализации. 

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

Но здесь появляется еще одна важная мысль. Настоящий senior обычно отличается не тем, что «умеет все лучше всех». Скорее наоборот. Часто зрелый senior хорошо понимает границы своей экспертизы. И, как показывает практика, способность вовремя сказать «Это уже не моя зона ответственности» иногда оказывается не менее важным навыком, чем умение быстро погружаться в новые области.

Как расширять экспертизу без потери глубины

Если посмотреть на специалистов, которым действительно удалось расширить свою экспертизу без потери основной квалификации, то почти всегда можно заметить несколько общих закономерностей.

1. Не стоит строить горизонталь раньше вертикали.

В моей практике попытки слишком рано стать «универсальным солдатом» почти всегда приводили к одинаковому результату. Человек начинал понемногу изучать архитектуру, базы данных, DevOps, frontend, backend и другие направления, но при этом не успевал сформировать прочную основу в собственной профессии. Широкий кругозор без глубокой экспертизы редко приносит реальную пользу.

2.  Изучайте смежные области лучше через реальные рабочие задачи.

Гораздо полезнее разобраться в устройстве API на конкретном проекте, чем прочитать несколько книг про интеграции и никогда не применять знания на практике. То же самое касается архитектуры, баз данных и инфраструктуры. Практический контекст обычно ускоряет обучение в несколько раз.

3. Каждая новая компетенция должна усиливать основную профессию.

Для системного аналитика это, пожалуй, самый важный критерий.Если новые знания помогают лучше собирать требования, быстрее находить проблемы, эффективнее взаимодействовать с командой и принимать более качественные решения, значит расширение экспертизы движется в правильном направлении.