Предисловие
Идея этой статьи родилась из обсуждения в чате канала «UI фэйл» (https://t.me/uifail), который ведёт мой коллега и друг Денис Пушкарь. В процессе сборки материала я обращался к коллегам из других команд и направлений (в том числе разработки, тестирования и аналитики), чтобы подтвердить или опровергнуть свои умозаключения, так как тема весьма обширная, а пишет статью по ней человек из сферы дизайна.
Во многом я буду ссылаться и на свой собственный опыт, и на наши устоявшиеся процессы в компании. Надеюсь, дорогой читатель, что ты найдёшь эту статью полезной, а также почерпнёшь для себя некоторую пищу на подумать.
Также сразу оговорюсь, что далее по тексту буду использовать привычную терминологию уровней специалиста (джун, миддл, сеньор, ведущий, тимлид), однако эта оценка весьма условна и, на мой взгляд, требует существенного пересмотра. Например, у нас в дизайн-студии Ростелекома используется градация из 12 уровней каждого навыка, в которой мы умышленно отказались от стандартных ярлыков. Для простоты изложения в этой статье я к ним вернусь.
Ниже по тексту я распишу трудности, с которыми сталкивается специалист в IT на всём протяжении своего роста, и о которых очень мало говорят.
Немного контекста
В чате канала «UI фэйл» в один из ноябрьских вечеров случилась крайне интересная дискуссия, в которой мне посчастливилось принять участие. Один пользователь вкинул тему с созданием некой программы менторства для начинающих специалистов с ростом до уровня джуна. Я стал задавать классические вопросы: «а в чём ценность твоего предложения?» и «тот же Skillbox предлагает курсы гораздо дешевле, какой смысл начинающему идти именно к тебе?»
У меня возникла довольно интересная мысль: почему из каждого чайника нам трубят о том, как дорасти до уровня джуна с нуля, но практически никто не предлагает услуг по дальнейшему развитию? А ведь, на самом деле, именно ступенька от джуна до миддла является самой сложной в развитии специалиста!
«Ловушка» джуна
«Почему именно эта ступень?» — спросишь ты. Тут мне придётся копнуть в психологию.
Как мы знаем, рост навыков — довольно понятная вещь. Не говорю, что простая; именно понятная. Ты работаешь, получаешь опыт, изучаешь литературу и проходишь курсы. Но что такого особенного происходит между уровнем джуна и миддла? Ответ простой: личностный рост.
Как раз развитие себя как личности — наиболее сложная штука. Те, кто занимался с психотерапевтом или пытался копаться в себе самостоятельно, используя практики, могут подтвердить, насколько трудно даются некоторые инсайты, принятие их и умение ими пользоваться.
И вот у нас есть джун. Он прошёл курсы, начал делать какие-то проекты, появились первые успехи. Не важно, фрилансер или сотрудник компании — у него уже есть некоторый набор инструментальных навыков, которые позволяют ему делать работу на базовом уровне и получать некий доход. И дальше наш юный падаван попадает в огромную ловушку: первые успехи вскружили голову; он думает, что может всё; заказчики довольны, радуется руководитель. И это наркотик, который только укрепляет огромную самоуверенность начинающего специалиста.
У Google на образовательном ресурсе Coursera есть очень крутой курс для получения сертификата Google UX Professional. В рамках курса в блоке про исследования рассматривается интересная штука — предрассудки дизайнера. Это как раз те аспекты, которые не дают взглянуть на задачу комплексно. То есть мы сами строим себе туннельное зрение за счёт каких-то базовых для нас понятий. И тут происходит тот же самый эффект — начинающий специалист абсолютно верит в то, что он очень крут. Возникает эффект необъективного восприятия собственного уровня навыков.
В такой ситуации джун начинает неадекватно анализировать действительность, думать, что он делает очень круто — лучше просто некуда. Вот только по факту результат не улучшается, нет развития. И это становится проблемой как для заказчиков, так и для непосредственных руководителей (при их наличии).
«Институт» тимлидства
Даже от некоторых тимлидов из крупных компаний я не раз слышал фразы «Я знаю о дизайне всё!» и «У меня гораздо больше знаний, чем у всех вас!»
Это тоже «джуновое» мышление. Так происходит, когда тимлид оказывается не готов к своей роли по софтскиллам. Он ещё не прошёл фазу личностного роста, не научился адекватно воспринимать свой уровень навыков. Соответственно, такой тимлид никогда не сможет нормально помочь вырасти своему джуну.
У нас в студии есть некий набор требований к тимлиду. Ниже привожу список задач по блоку «Развитие компетенций дизайнеров» (это всего лишь один из 4 блоков по задачам тимлида), необходимых для этой позиции:
Планирование развития каждого дизайнера в соответствии с планом развития команды;
Задание вектора для постановки профессиональных целей;
Контроль выполнения проф. целей, помощь в их достижении;
Аттестация дизайнеров в соответствии с матрицей компетенций;
Обзор 360;
Мероприятия для развития скиллов (софт и хард);
Мотивация персонально каждого члена команды.
То есть идёт речь о полноценном менторстве каждого сотрудника. В том числе посредством сбора обзора 360 — помощь специалисту в объективной оценке его навыков.
Дорогой читатель, все ли из этих пунктов есть у тебя в работе? Есть ли у тебя наставник, который помогает расти, или же ты собираешь грабли лицом самостоятельно?
Мой опыт показывает, что в большинстве случаев в IT-компаниях так или иначе упускаются эти моменты. Где-то частично, а где-то вообще полностью. Чуть дальше по тексту я расскажу о разнице между ведущим дизайнером и тимлидом, но здесь без показательного примера не обойтись.
Задача для лида
Предлагаю тебе решить задачку, которую даём на собеседовании на позицию тимлида. Только честно: сначала реши так, как тебе кажется, а затем иди смотреть ответ.
Дизайнер постоянно косячит. Это создаёт проблемы на проекте — страдает уровень качества, что неприемлемо для компании и заказчика. Но это важный для тебя специалист, который действительно работал на высоком уровне. Ты не хочешь его увольнять, так как это ценный сотрудник. Как ты решишь такую ситуацию?
Вставлю мем с котиком, чтобы ты не подглядывал раньше времени)
Решил задачку? Тогда давай разберём подход.
Как думает ведущий специалист: «Я составлю чек-лист для проверки каждого макета дизайнером. Буду требовать присылать мне макеты на ревью только после прохождения всего чек-листа. Рано или поздно у дизайнера такой процесс войдёт в привычку, и качество вернётся на прежний уровень».
Неплохой ответ, правда? В целом всё логично. Ты же не можешь постоянно контролировать каждый чих специалиста, так что даёшь ему некий фреймворк по проверке своей работы.
Вот только после такого ответа мы обычно спрашиваем: «Окей, ты составил чек-лист. Но проблема никуда не ушла, дизайнер продолжает косячить. Что будешь делать?»
И тут в большинстве случаев ведущий специалист начинает предлагать эскалацию на руководство и т.д.
А вот, как думает тимлид: «Я проведу встречу один-на-один с сотрудником. Постараюсь выяснить, что с ним происходит: быть может, у него трудности в личной жизни или какой-нибудь личностный кризис. Погружусь в проблему и постараюсь дать совет или поддержать по возможности, дать ему больше времени и пространства для решения личных вопросов, снизить поток задач на него и подключить дополнительные ресурсы. Если вдруг у него всё хорошо, то посмотрю на количество задач на специалисте: может быть, он сильно перегружен и из-за этого допускает ошибки. В таком случае я подключу к нему в помощь дополнительные ресурсы или подниму вопрос с руководством об открытии дополнительной вакансии, если таких ресурсов сейчас нет. Если же и с перегрузкой всё окей, то поставлю в помощь более опытного коллегу, который сможет менторить и ревьювить его работу. В случае выявления проблемы из-за невнимательности составлю чек-лист для проверки макетов»
Сравни, насколько более комплексный подход у тимлида. Он сначала соберёт весь контекст, постарается погрузиться в причину проблемы, а только потом предложит решение.
Вот только далеко не каждый «тимлид по должности» это понимает и использует в своей работе.
И снова про джуна
Поэтому возникают истории с полным выгоранием джунов, резкими увольнениями, уходом в другую специальность и т.д.
Даже суперкрутому психологу нужен свой психолог. Тут тот же посыл. На всех этапах развития есть два пути: собрать лицом все грабли самостоятельно (долго, больно, подходит далеко не каждому) или получить помощь ментора в развитии. И вот как раз «институт» второго пути пока не очень сильно развит. Если в крупных компаниях джун как раз и должен в рамках своего роста получать от более старших товарищей менторство в развитии (но далеко не всегда получает), то фрилансеру тут труднее.
В остатке мы имеем, что переход от джуна до миддла означает: сильный личностный рост, объективное понимание своих навыков, стремление получать обратную связь и адекватно на неё реагировать. И вот как раз продукта по прокачке таких людей на рынке практически нет. Все говорят о том, как просто стать джуном, но никто не говорит, насколько трудно развиваться дальше. Из-за неграмотного менторства или вообще его полного отсутствия в компаниях джун выгорает и начинает скакать по местам работы. Или же (как и фрилансер) в какой-то момент замечает, что никак не может выйти на следующий уровень, а помочь ему никто в этом не может. Что тоже приводит к выгоранию (и большим очередям на запись к психотерапевту).
А дальше-то что?
А дальше уже вполне планомерный рост. От миддла до сеньора путь весьма очевидный (хоть и тоже непростой): качественный рост инструментальных навыков и знаний, увеличение зон ответственности и компетенций — главное, не перегореть и внимательно отслеживать свой прогресс. На этом шаге не буду подробно останавливаться (но от тебя, дорогой читатель, буду рад увидеть комментарии про трудности, с которыми ты столкнулся в рамках этого этапа).
Однако, следующая ступенька тоже заслуживает отдельного внимания: рост от сеньора до ведущего специалиста.
Уровень ответственности тут гораздо выше. Сотрудник уже начинает отвечать не только за свой результат работы, но и за вверенный ему кусок работы целиком, в том числе и за качество работы прикреплённых к ведущему сотрудников. Глубокие знания психологии тут пока не требуются, так как всё-таки ответственность за рост сотрудников находится именно на тимлиде. Ведущий же специалист отвечает именно за производственный процесс.
Тут нужно сделать небольшую ремарку: ведущий — это, скорее, роль, чем уровень. Ведущим может стать и миддл, который грамотно может оценивать работу и вести некий кусок продукта. Само собой, тимлиду при выборе ведущего специалиста стоит в первую очередь рассмотреть наиболее сильного по навыкам спеца из команды продукта.
Однако, я сталкивался с ситуацией, когда в команде может быть суперпуперсеньор, который просто не хочет брать на себя ответственность и коммуникации. Такие люди встречаются, и это абсолютно нормально. Не нужно ломать через колено такого сотрудника и заставлять его насильно вступать в ту роль, в которой он быть не хочет. К нему нужно максимально прислушиваться и ценить, а задачу по коммуникации и ответственности за результат можно поставить бойкому и инициативному миддлу, который уже, адекватно понимая свой уровень, будет так же учиться у сеньора и понимать, в какой момент нужно обратиться за советом.
Тимлид.
Поставил точку в конце заголовка для большей серьёзности.
В своё время я крайне хотел выйти на эту позицию и искренне не понимал, почему меня, ведущего специалиста, не делают лидом, хотя я выполняю (как мне казалось) все задачи лида. Однако, уже со временем пришло понимание, что эта роль гораздо глубже и сложнее, чем раньше мог себе представить.
Тимлид — это не рост вверх. Это рост в другую сторону. Для многих достижение уровня сеньора или ведущего кажется какой-то промежуточной планкой, но это не так. В зависимости от твоего менталитета и твоего желания ты можешь и дальше качать свои навыки — нет предела совершенству.
Считай, ты стал признанным экспертом в своей отрасли: дальше тебе нужно не терять свою актуальность и постоянно развиваться. Сеньор или ведущий — это не потолок развития. Это просто некий собирательный образ некого уровня. Как на беговой дорожке стадиона: есть старт, а есть финиш. Вот только за финишем стадион продолжается — мир огромен, как и поле для роста.
Тимлид же — совершенно другая история. Ты уходишь в руководство. И в первую очередь не руководство процессом производства (этим ты спокойно мог заниматься как ведущий), а в руководство людьми. Именно тебе приходится развивать этих ребят, менторить, консультировать, проверять и контролировать их психо-эмоциональное состояние.
Ты должен ощутить ответственность за состояние каждого твоего специалиста. Ты чётко должен понимать, что твоё негативное настроение скажется на настроении твоей команды. Будешь фатализировать и транслировать вечную борьбу с заказчиком — будет выгорать твоя команда. Ты должен любить своих ребят, ценить и грамотно вести через все задачи, с которыми вы сталкиваетесь.
Как-то многовато «ты» и «должен», не находишь?
К сожалению или к счастью, такова реальность. Ответственность — ключевой параметр тимлида. Умение встретить суровую действительность и принять решение, как с ней справиться. От тебя требуется постоянное принятие сложных решений, а также объяснение и трансляция этих решений (само собой, фильтруя, что и как транслировать). Без аргументов ты потеряешь любой авторитет, который мог получить как сильный специалист. НИКОГДА не бравируй своей «должностью» (фразы из разряда «Я тут тимлид, знаю лучше» вообще забудь навсегда). Учись аргументировать свою позицию и принимать тот факт, что ты всего знать не можешь. Слушай команду, слушай джунов, которые приносят что-то новое и интересное, и никогда не попадай в ловушку собственных предрассудков и туннельного зрения.
Фух. Много тяжелой информации, друг. Таков путь развития, и только тебе решать, в какую сторону и как идти. Ты справишься, верь в себя. А если уже справился — ты крут, не брезгуй новой информацией (или уже тебе известной). Само собой, это далеко не всё, что входит в обязанности тимлида, но из моего опыта эти тезисы являются одними из самых важных.
И какой итог?
Путь специалиста в IT весьма труден. Всякие «легко войти в IT» и получать «300к в секунду» — это фикция. Всем вышенаписанным текстом я хотел поднять проблему самых трудных переходов в росте, а также более детально расписать эффект Даннинга-Крюгера и роль тимлида/ментора в развитии каждого специалиста. У кого-то этот путь проходит чуть проще, а у кого-то чуть труднее. Всё индивидуально, как и каждый человек. Каждый способен достичь крупных успехов при грамотном подходе к собственному развитию, в том числе за счёт стремления получать обратную связь и адекватно на неё реагировать. Так что закончить сей спич хочу на мажорной ноте — дерзай, дорогой читатель! Тебе открыты все дороги, ты можешь всё! Но нужно постараться)
А, постой секунду. У меня к тебе есть один вопрос…
А насколько адекватно ты сам оцениваешь свой уровень?)
Материал подготовил:
Денисенко Никита (ТГ: @nikdenisenko), руководитель дизайн-команд направления импортозамещения дизайн-студии, РТК ИТ
Отдельные благодарности за ревью материала и подтверждение:
Игорю Готту — дизайн-директору дизайн-студии, РТК ИТ
Василине Усольцевой — арт-директору направления профинтерфейсов дизайн-студии, РТК ИТ
Андрею Новикову — тимлиду дизайн-команды профинтерфейсов дизайн-студии, РТК ИТ
Владиславу Пасечнику — директору, Точка отсчёта (0point)
Денису Пушкарю — владельцу дизайн-системы Атомаро, РТК ИТ
Татьяне Егоровой — тимлиду команды аналитиков, РТК ИТ
Алексею Гадияку — тимлиду команды тестирования, РТК ИТ
Михаилу Синякову — руководителю front-end направления, РТК ИТ
Юрию Плотникову — тимлиду back-end команды, РТК ИТ
Юрию Провоторову — тимлиду front-end команды, РТК ИТ
Максиму Корелину — тимлиду front-end команды, РТК ИТ
