Привет Хабр! Меня зовут Николай Малышков, я 15 лет в ИТ, был тестировщиком, аналитиком, frontend-разработчиком. Однажды я понял, что мне очень нравится строить процессы и организовывать команды. Последние лет 10 я занимал различные руководящие позиции. Сейчас работаю ведущим менеджером проектов в Т1 и готов делиться своим опытом с комьюнити.

В последние годы всё чаще можно услышать: «Нам нужен T-shape специалист!», а потом ищут мифического full-stack, потому что путают эти понятия чаще, чем зумеры меняют работу. Разберёмся, в чём разница и почему в больших технологических системах T-shape — это не модный ярлык, а ответ на реальную сложность.

Начнём с определения:

T-shape — это специалист с глубокой экспертизой в одной узкой области (вертикальная линия буквы T) и широкими знаниями в смежных областях (горизонтальная линия буквы T).

Именно сочетание глубины и широты позволяет накладывать на свою экспертизу ширину взглядов для поиска более качественного понимания.

T-shape — не просто метафора, а модель, подтверждённая академическими исследованиями, в которой сочетание глубины и широты навыков служит основой для эффективной командной работы и инноваций.

T‑shape и Full‑stack — это разное 

Full-stack — это про набор технологий. Обычно предполагается, что этот человек способен закрыть фронтенд, бэкенд, базу данных, CI/CD, дизайн — то есть весь производственный процесс (при этом писать он будет идеально, так что тестирование не нужно).

То есть Full-stack — это про ширину в профессиональных навыках.

А T-shape — это про когнитивную модель мышления. Про сочетание глубины в одной области и понимания смежных контекстов.

Если упростить:

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

Чаще смотрят немного у̒же, предполагая, что, например, сеньор-T-shape-back-разработчик сможет не просто спроектировать фичу, но и подумать:

• как с ней будет работать фронтенд;

• как сделать её надёжной и предсказуемой для тестирования;

• как вводить в эксплуатацию быстро и безопасно;

• как это повлияет на сопровождение и дальнейшее развитие.

T-shape совсем не обязан уметь всё реализовывать самостоятельно. Это история не про «я всё напишу сам», а про «я понимаю, как это должно работать и какие решения будут оптимальными».

Я часто говорю, что читать справочник по C# нужно не для того, чтобы всё выучить, а для того, чтобы в нужный момент знать, что есть какой-то инструмент, который может помочь тебе в решении твоей проблемы. Тут похожая ситуация.

Почему вообще появился тренд на T-shape

Мне кажется, причина не в самом T-shape, а в другом, более общем тренде «думаем о клиенте». Чтобы это перестало быть лозунгом, а стало реальной практикой, на каждом этапе производства люди должны понимать:

• кто будет пользоваться результатом;

• как и в каких условиях;

• что пойдёт дальше после их части работы.

И вот тут узкие роли начинают давать сбой.

Я бы выделил несколько причин, почему компании всё чаще смотрят в сторону T-shape.

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

  Кросс-функциональные команды работают быстрее, когда говорят на одном языке. В ИТ-холдинге Т1 мы уверены, что работа над комплексными решениями сильно ускоряется, если ты понимаешь, что было до тебя, что будет после и какие ограничения есть у смежных ролей. Это не про «я всё умею», а про «я понимаю последствия решений». Именно здесь T-shape даёт максимальный эффект.

  А ещё команды с разнообразной экспертизой демонстрируют более оригинальные и действенные в долгосрочной перспективе результаты по сравнению с однородными командами.

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

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

  Да, потребуется адаптация. Но такая команда быстрее восстанавливает продуктивность, чем набор узких специалистов без общего понимания.

В итоге T-shape — это не про моду. Это про:

• сложность систем;

• фокус на клиенте;

• необходимость думать шире своей роли.     

Появление агентов меняет правило игры

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

• какую задачу нужно решить;

• какой результат будет приемлемым;

• какие ограничения есть у создаваемого решения;

• как проверить качество полученного результата;

• и какие ещё сферы (агентов) может затронуть это решение.

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

T-shape профиль позволяет нам перейти от просто использования генератора к построению цепочек принятия решений. И получается, что развитие ИИ агентов увеличивает цену T-shape специалистов.

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

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

Главная проблема — «переводчики»

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

Но хуже другое — в отсутствие переводчика:

• делают не то, что нужно;

• реализуют не так;

• релиз останавливается из-за недопонимания;

• инциденты появляются уже в эксплуатации.

Каждый такой «перевод» — это семантическая потеря информации. Чем больше свободных интерпретаций, тем выше вероятность системной ошибки. Культура T-shape снижает эти потери.

Когда человек понимает, кто будет пользоваться результатом, что произойдёт после его этапа и какие ограничения есть у соседних ролей, то качество решений растёт.

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

Один T-shape — это плохо

Есть важный момент: если в команде всего один T-shape, который «спасает проект», то это не зрелость. Это зависимость. Это точка отказа. Это bottleneck. Это операционный риск. Зрелость начинается тогда, когда T-shape становится культурой, а не героизмом одного человека. Когда не нужны переводчики, каждый понимает последствия своих решений, а обсуждения проходят на одном языке.

Как T-shape меняет управленческую роль

Для меня лично развитие в сторону T-shape повлияло на управление. Я стал быстрее принимать решения, точнее оценивать последствия, заранее видеть потенциальные проблемы на разных этапах создания ценности и проще договариваться с экспертами в смежных областях.

Понимание контекста снижает количество эскалаций и упрощает коммуникацию. Это не про контроль всего, а про понимание системы целиком.

Когда T-shape не нужен

При этом очень важно не превращать T-shape в идеологию. Я выделяю две стороны, когда это НЕ нужно бизнесу и когда это НЕ нужно человеку. T-shape — это не цель и не универсальный стандарт. Это всего лишь профиль, а для компании — один из инструментов.

Когда T-shape специалист не нужен компании

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

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

Когда система простая и роли легко формализуются. Если система несложная, зоны ответственности чётко разделены и взаимодействие между ролями минимально, то T-shape просто не даёт ощутимой добавочной ценности.

Когда T-shape не нужен человеку

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

Когда широта начинает перегружать. Тут работает старая поговорка: за двумя зайцами погонишься — ни одного не поймаешь. Постоянное переключение контекста требует много энергии, подходит не всем, и при неправильном балансе может приводить к выгоранию.

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

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

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

Как распознать T-shape специалиста?

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

На собеседовании в первую очередь проверяем «I-глубину». Тут всё по стандарту: примеры из опыта, задания, технические примеры, проверка понимания фундаментальных принципов или правил.

А дальше переходим к горизонтали. Тут у всех разные способы, сначала расскажу про то, с чем я столкнулся на собеседовании в одной крупной девелоперской компании. У менеджера был огромный список из разных слов, он просил каждое из них прокомментировать. В огромном темпе я давал определения, говорил, как это применял или для чего это в целом. Набор был примерно такой: BPMN, Agile, Git, асинхронное взаимодействие, тестирование чёрного ящика, User Story, ООП…

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

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

Я с другом поразгонял эту тему, и мы придумали забавный синтетический вопрос: «Почему гладиус короткий?» При ответе на него вероятный T-shape специалист проявит такие положительные признаки:

• Знает, что такое гладиус, или примерно знает.

• Представляет эпоху.

• Может порассуждать, когда короткий меч хорош, а в каких случая нет.

• Может рассказать, в каких условиях он применялся.

• Может прикинуть технологии производства.

• Может оценить массовость изделия.

• Может предположить скорость обучения владением.

• Может пояснить плюсы применение в плотных построениях.

И ещё много всего. Тут нет погони за истиной, а важна разносторонность взгляда и построение цепочки предположения до объяснения.

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

Как развить в себе T-shape и не обмануть себя

Сначала — I. Самое важное, без чего дальше ничего не получится — это та самая глубокая экспертиза в одной из областей, на основе которой вы будете выращивать свою широту. Я убеждён, что достаточно много людей не имеют хорошей I в принципе, нахватаются по верхам всякой информации из какой-то сферы, а потом говорят, что они просто T-shape, поэтому «тут не могут дать какую-то экспертную оценку», и вообще нигде не могут её дать. Важно хорошенько прочувствовать: «Здесь я точно понимаю глубину. Я знаю ограничения. Я знаю цену ошибки».

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

И тут нужно сразу сказать, что эта самая I — это не диплом, не первый стек, с которым вы работали, и не количество лет в профессии.

Глубина рождается сама, когда вы найдёте что-то, что вас зажигает. Когда вы в какой-то момент понимаете, что делаете уже что-то настолько сложное, что точно можете сказать, что вы в этом эксперт. Когда вы отвечали за последствия, видели, как ваши решения эксплуатируются, сталкивались с отказами, инцидентами и ограничениями.

В больших технологических системах иллюзия глубины быстро вскрывается. Сложность не прощает поверхностности.

Я долго искал свою I, начинал с тестирования и аналитики, потом казалось, что нащупал свою I во фронтенд-разработке. Но в итоге я уже 8 лет в менеджменте, и, похоже, это у нас по любви.

Перейдём к —. Сначала то, что рядом. Когда у вы определились с I и понимаете, что вам этого мало, начните изучать смежные дисциплины. Именно от знания того, что происходит рядом, будет наибольшая польза.

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

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

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

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

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

Страшно представить сколько всего хорошего, но бесполезного мы бы сделали в продукте, если бы не начали проводить интервью с клиентами.

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

Мышление. И последнее из важного на мой взгляд — развивать навыки философа. Переходить от общего к частному и обратно. Находить абстракции и общие черты у событий, процессов и понятий в разных областях. Это то, что позволяет быстро осваивать новые контексты без ощущения хаоса. По сути, это и есть интеллектуальная горизонталь.

Я долгозаставлял себя задавать вопросы. Кажется, у меня до сих пор остаётся страх, показаться глупым, но хорошо, что этот страх с лихвой окупается пониманием и уверенностью в том, что происходит. А ещё бонусом достаются новые знания, ведь порой не знаешь, к чему приведёт тебя простой вопрос: «А как это используется?», или «Пять почему».

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

Что можно сделать уже сейчас:

1. Честно ответить себе: в чём моя I?

2. Довести это до состояния экспертности.

3. Начать изучать ближайшие зоны вокруг неё.

4. Разобраться в бизнес-смыслах.

5. Тренировать мышление, а не только накапливать факты.

Не нужно читать историю Римской империи, чтобы стать T-shape. Любознательность — это хорошо. Но широта кругозора ≠ широта мышления. Широта без глубины — это не T-shape, это иллюзия компетентности. А иллюзии в сложных системах долго не живут.

Итог

T-shape — это не про умение делать всё. Это про умение понимать систему целиком и принимать решения, осознавая их последствия. T-shape структуры признаются и индустриальными отчётами, такими как отчёт CFA Institute, где T-shape команды рассматриваются как ключевой фактор успеха в сложных цифровых проектах. Потому что это способ снизить системные потери и повысить эффективность на стыках, в коммуникациях, интерпретациях и релизах.

И самое главное — это не тренд. Это ответ на растущую сложность технологических систем.

А вы сталкивались с тем, что T-shape подменяют full-stack’ом? Или, может, у вас есть свой «гладиус» — вопрос, который вы задаёте на собеседованиях? Делитесь в комментариях, интересно обсудить

PS: эта статья — результат соединения ряда серии постов про T-shape, которые я публиковал в своём канале t.me/sorryetotaknerabotaet и сетке set.ki/7NTK2xD.