Все записи

Кто такой T-shaped специалист?

Людей, развивающихся в рамках одной специальности, называют I-shaped специалисты. Они отработали 10 000 часов в своем направлении и стали профессионалами. Но как быть с теми, кто выбрал работу на стыке дисциплин?

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

Для такого альтернативного подхода к развитию также есть название — T-shaped. 

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

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

Как развить в себе T-shaped навыки?

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

Например, в Уральском федеральном университете несколько лет назад ввели систему майноров. Благодаря ей студенты могут взять курс по предмету, который выходит за рамки специальности. Так будущие разработчики могут дополнительно обучаться экономике технических решений, психологии управления и многим другим.



Похожие новости

Когда задача считается выполненной

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

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

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

Разбираем фичи по кусочкам: атомарные коммиты как внутренняя дисциплина

Дима руководит группой прикладной разработки в Naumen и много лет работает с командами, которые делают не одноразовые фичи, а долгоживущие системы — те, что развиваются годами, переживают смену людей, требований и контекста.

В статье он рассказывает о декомпозиции: зачем она на самом деле нужна в разработке и какую неожиданную роль в этом играют атомарные коммиты.

Как развивать документацию и продвигать техписателей

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

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

Все новости