Привет Хабр! Меня зовут Николай Малышков, я 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 — это про когнитивную модель мышления. Про сочетание глубины в одной области и понимания смежных контекстов.
Если упростить:
Параметр | 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-разработчиком, и у меня была хорошая насмотренность и знание основных паттернов. Но, прочитав книгу, я всё равно нашёл для себя что-то новое из создания визиток и буклетов.
Что можно сделать уже сейчас:
Честно ответить себе: в чём моя I?
Довести это до состояния экспертности.
Начать изучать ближайшие зоны вокруг неё.
Разобраться в бизнес-смыслах.
Тренировать мышление, а не только накапливать факты.
Не нужно читать историю Римской империи, чтобы стать 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.