Что такое T-shaped подход и зачем он ИТ-командам
Во-первых: чтобы повысить мотивацию (но это не всё)
T-shaped — современная HR-концепция. Такой сотрудник обладает как отраслевыми hard skills (вертикальная полоса «Т»), так и знаниями и опытом на минимальном уровне в других областях (горизонтальная полоса «Т»). Пример: бэкенд-разработчик понимает, как делать UX/UI, а фронтенд может развернуть приложение в облаке. Такой подход активно применяется в QIWI в продуктовой разработке — о его преимуществах для бизнеса и разработчиков и поговорим.
«T» для бизнеса
Многофункциональные сотрудники — залог гибкости и производительности бизнеса. Особенно такие кадры привлекательны для стартапов с ограниченными ресурсами и большой долей неопределенности. T-эксперты важны и для больших компаний, где есть не только платформенные, но и продуктовые команды, которые разрабатывают для пользователей фичи на стыке направлений.
На практике T-shaped-подход дает бизнесу следующие преимущества.
- Высокую скорость: команда может решить задачу за двухнедельный спринт. Отдельно департаменты (бэкенда, фронтенда, QA) решают ее больше месяца. Результат: можно быстрее собирать MVP, тестировать больше бизнес-гипотез, сократить time-to-market продукта.
- Эффективность взаимодействия: разработчики, которые понимают специфику смежных платформ, быстрее договариваются друг с другом.
- Кадровую гибкость: в базовых задачах T-специалист может подменить коллегу, который ушел в отпуск или взял больничный. Работа над проектом не останавливается, команда и бизнес перестают быть заложниками bus factor.
- Целостное видение: при расширении знаний технологий, помимо собственного стека, разработчики могут подойти к задаче комплексно и найти оптимальные решения.
Стабильность и адаптивность: разнообразие скиллов у команды делает бизнес более устойчивым к изменениям запросов среды. Специалист с многовекторными навыками способен погрузиться в тему и решить несложные задачи без привлечения экспертов. Когда в отделе работают в основном I-shaped-айтишники, клиентские запросы приходится подстраивать под возможности команды.
«T» для сотрудников
- T-shaped-подход объединяет команду, она становится сильнее. Появляется единый фокус на цели спринта: нет своих и чужих задач — все они общие.
- Выравнивается нагрузка участников команды. При стандартной схеме нередко бывает, что часть команды уже выполнила свои задачи по спринту, а другая вынуждена перерабатывать. Это демотивирует, так как свободный человек фактически выпадает из общей работы и не помогает команде приблизиться к цели.
- Прокачивается адаптивность и эмпатия: во время шаринга знаний, сессий парного программирования и пр.
- Идет профилактика выгорания от однообразных задач.
- Растут креативность, способность мыслить нестандартно и технический кругозор, это позволяет разработчику быть более эффективным, проецируя техники и подходы, которые используют на других платформах, на свой стек.
Как развивать T-практики в компании
Сложно схантить подходящего T-shaped-специалиста — его проще вырастить. В QIWI для этого используют star map, или матрицу компетенций: по вертикали прописывают умения, которые нужны команде, по горизонтали — список сотрудников. Таблица позволяет увидеть, по каким навыкам есть пробелы и кто в какой сфере хочет развиваться.
Разработчики сами выбирают интересные направления, а компания помогает погрузиться в них. Для этого разработана система менторства. Обучение состоит из практики парного программирования и домашних заданий.
Как еще можно помочь прокачивать T-компетенции:
- составлять инструкции и списки литературы для T-шейперов;
- устраивать внутрикомандные воркшопы;
- декомпозировать задачи и привлекать для решения простых новичков-энтузиастов.
Важно не только обучать отдельных программистов, стоит донести до всех сотрудников, в чем заключается польза от передачи опыта и знаний. В идеале все должны чему-то учиться друг у друга. Разработчикам нужно понимать, за что отвечают коллеги и какие их функции они могут подхватить при необходимости.
С какими трудностями можно столкнуться при развитии T-шейперства
- По началу может упасть скорость работы команды — много времени уходит на изучение нового. Также на смену подходу «одна задача — один человек» приходит одна общая командная цель, в достижение которой каждый вносит свой вклад. Это временно, пока тишейперы не получат знания минимального уровня в смежных областях.
- У специалиста может возникнуть «синдром самозванца»: человеку хочется попробовать себя в смежной области, но есть опасение подвести команду. Важно донести: в изучении нового нет ничего страшного.
- Есть риск сильно увлечься T-shaped-практиками и потерять экспертизу в основной специализации. Сбалансировать это — задача менеджмента.
- Кто-то из команды не поддерживает T-идеологию: далеко не все айтишники способны и готовы развиваться в таком формате. Кому-то больше подходит развитие до уровня Senior в одной конкретной технологии. Навязывать T-shaped-принципы не стоит.
Инвестировать в T-shaped-подход — значит повышать общую эффективность команды. Чтобы это сработало, важно не принуждать людей, а создавать соответствующую культуру и возможности в компании. При этом нужно сопоставлять T-практики с реальными задачами бизнеса, которому могут быть больше нужны платформенные команды, максимально погруженные в одну технологию.
T-shaped.... На стройке у нас это называлось: "Принеси. Подай. Пошел на хуй, не мешай".
Комментарий недоступен
Такой сотрудник обладает как отраслевыми hard skills (вертикальная полоса «Т»), так и знаниями и опытом на минимальном уровне в других областях
обладать то ладно, а как Вы обязанности и обязательства раскидываете ? Типа обязан по ДИ разворачивать сервер сисадмин, но может и бухгалтер. Кто будет разворачивать сервер?
бэкенд-разработчик понимает, как делать UX/UIно тщательно это скрывает, чтобы не припахали
Я не из киви, но попробую прокомментировать исходя из своего понимания.
"сисадмин, но может и бухгалтер" - ну не настолько 😂 Скорее про то, что разработчик может и в nginx конфиг поправить при необходимости, и существующий код на фронте немного поправить, и аналитику структурировать.
"скрывает, чтобы не припахали" - ну тут уже возникает логичный вопрос "а в чём таки мой профит от Т-shaped? Ответ: карьера в техническом менеджменте и деньги. Я бы не взял на работу СТО, который если жизнь припрет не сможет разобраться как допилить фронт, бэк и настроить пайп самостоятельно, поскольку технически он является последней линией обороны проекта:)
И разумеется оплачиваться такой специалист должен соответственно - иначе нафига за те же деньги тишейпить когда можно просто в своём стеке до архитектора расти если не хочется команды раздавать)
Комментарий недоступен
Комментарий недоступен
А по простому это старый добрый fullstack программер)) Всё возвращается на круги своя