T-Shape или Т-образные специалисты

Главное

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

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

Дополнительно

Другие буквы

• I-навык = хорошо развитая основная компетенция.
• П-образные навыки = глубокий функциональный/предметный опыт + общие управленческие навыки.
• М-образные, Ш-образные = T-shape с несколькими глубоко развитыми компетенциями. Эти спецы хороши на среднем уровне во многих темах, а в нескольких – мастера.

Смежные термины

• Full-stack developer – в терминах выше это М-shaped, но в части разработки и тестирования. Не всегда это означает наличие продуктовых и дизайнерских навыков.
• Bus/truck factor – минимальное количество членов команды, при внезапном исчезновении которых из проекта, приводящее к остановке проекта из-за нехватки знаний или компетенций.
• Кросс-функциональная команда – команда, обладающая всеми компетенциями, чтобы реализовать проекта от идеи до результата. При этом каждый участник команды может быть и I-shaped, однако в этом случае очень низкий "фактор автобуса", скорость команды может быть нестабильной, а прогнозы готовности неточными.
• Матрица компетенций или Star map – инструмент для диагностики команды с целью повышения фактора автобуса и эффективности команды.

Эти темы мы подробнее обсуждаем с группой на курсе "Основы Agile и Scrum".

Преимущества развития смежных навыков

Для команды

1. У команды в целом больше компетенций => команда может выполнять приоритетные задачи, а не то, на что хватает компетенций.
2. Равномернее загрузка и, опять же, на приоритетные задачи, а не "поделаю пока что вот это, пока моя коллега завершит свою часть задачи".
3. Повышается понимание задач друг друга => участники больше вовлекаются на планировании и синхронизациях => разносторонне выявляются риски => сокращается количество неожиданных происшествий.
4. Повышается взаимовыручка и поддержка между участниками команды, сокращаются претензии, улучшается климат, растет командный дух.
5. Больше возможностей у команды, выше самостоятельность = "можем сделать" => выше внутренняя ответственность.
6. Повышается bus factor = меньше ограничений внутренних и зависимостей друг от друга. Взаимозаменяемость.
7. Меньше просадок по компетенциям => скорость производства cтабильнее => предсказания-оценки точнее => доверия команде больше.
8. Скорость выше.
9. Чаще готовый инкремент в конце каждой итерации.
10. Снижается микроменеджмент.

Плюсы для сотрудника

1. В одиночку можете вытянуть мини-проект от и до.
2. Работа разнообразнее, меньше устаёт от однообразия, мотивация выше. Можно выбирать, что интереснее, менять направление внутри команды.
3. Шире выбор вакансий.
4. При желании проще стать Team lead или архитектором.

Ограничения развития T-shaping

1. Нежелание напрягаться ради изучения нового.
2. Нежелание развиваться в опаске стать крайним: "Если я буду многостаночником, то на меня будут больше взваливать, я если откажу или не успею, будут недовольны."
3. Уверенность в том, что быть мастером в нескольких дисциплинах одновременно — сложно или даже невозможно, и опаска стать "недоспециалистом" (мнение участников команд) влекут желание быть мастером в каком-то одном деле, а это приводит к нежеланию развиваться в смежных областях.
4. Страх заменяемости => желание быть незаменимым и этим повышать свою стоимость в компании.
5. Бывает, что в команде такой один, а другие участники отвечают за свои стаканы задач.
6. И тогда такого сотрудника трудно заменить => становится тем незаменимым, но не по одной компетенции, а по нескольким, и по всем сложным задачам (снижается bus factor).
7. И тогда не вся команда отвечает за весь продукт, а в большей степени именно он.

Возможные минусы для сотрудника

1. Многостаночник в каждой отдельной области хуже, чем узкий-глубокий специалист.
2. Он не успевает за всеми тенденциями, потому что технологии обновляются очень быстро, а изучать одновременно и вглубь, в вширь — трудно.
3. При использовании командой для создания нескольких языков/технологий приходится чаще подглядывать в мануалы => снижается производительность сотрудника.
4. Такой сотрудник всегда нарасхват, постоянно загружен работой.
5. И поэтому окружающие беспокоят его на выходных и в отпуске.
6. И поэтому его самообучение и изучение смежных дисциплин глубже идёт всё медленнее.
7. И если он работает над одним продуктом, то выше вероятность перегрузки.
8. И ему могут прилетать неинтересные legacy задачи, "а кому же еще – ты же это знаешь, тебе ведь не сложно".
9. И ему могут прилетать сложные дефекты чаще, чем другим.
10. Узкий специалист по самому дорогому навыку зарабатывает больше. (Но хотите ли заниматься только одним этим?)
11. По ключевым словам в резюме могут звать на случайные нерелевантные вакансии.
12. Непросто найти место с тем же full stack. С одной стороны, плохо, что при смене работы часть стека будет другой. С другой стороны, хорошо, что выше вероятность пересечения технологий текущего стека и перечисленных в вакансии.
13. Если написать в резюме много-много всего, то рекрутеры не поверят. Решение: адаптируйте резюме под каждую вакансию, удаляя лишнее, выделяя релевантное.

Эти темы мы разбираем с группой на курсе "Основы Agile и Scrum".

Альтернативные точки зрения

1. "Фулстеки — это вечные мидлы. Не идите по этому пути, если не хотите страдать" habr.com/ru/post/429612/
2. "Чем плохо быть full stack разработчиком" habr.com/ru/post/278467/