Всем привет. Меня зовут Ильмир, я QA Manual Engineer в inDriver. В статье расскажу о своем опыте менторства. Я занимаюсь этим уже больше 2 лет и хочу поговорить про этапы, которые могу выделить как основные.
В статье будут затронуты не проблемы методик и инструментов для обучения, а скорее эмоциональная составляющая. Все это актуально для случая, когда менторить нужно человека без опыта (практически, вчерашнего студента).
По сути, это аккумуляция моего личного опыта, которым я решил поделиться с вами. Статья в большей степени предназначена для тестировщиков, так как в ней много QA-based-нюансов. Погнали!
Содержание
Первый день
Не первый день
Свободное плавание
Первый день
Менторство — процесс, в котором новичку назначается наставник. Он обучает его, вводит в профессию и помогает освоиться. Ментор (иногда говорят бадди) — это человек, который обучает и наставляет новичка. Важным аспектом является умение расположить к себе человека.
Ментор особенно важен для новичков в IT. Расскажу про своего первого бадди, который сделал мне шоковую терапию, когда я пришел в IT. До него наставничество осуществлялось следующим образом: ты что-то спрашиваешь, а над тобой практически обязательно усмехнутся или посмеются, а уже далее кратко объяснят, что и как нужно делать.
Мой первый настоящий ментор сделал следующее: когда я ему задал вопрос о том, как завести баг, он подошел ко мне и присел на корточки, после чего стал подробно это объяснять. Будучи на тот момент интровертом с низкими коммуникативными навыками и сформировавшейся боязнью спросить что-то — я, мягко говоря, был шокирован. Это моментально убрало все страхи и чувство, когда у тебя «над душой стоят».
Но это лирическое отступление. Для начала хочу поговорить про волнение новичка в первый день. Ниже вы видите сотрудника, который только приходит в компанию, в профессию. Глаза испуганные, в них видно волнение, он не знает, что и как делать.
Первый день — всегда стресс. Новичок волнуется и не знает, с чем ему придется столкнуться. Задача ментора — помочь ему освоиться и сделать так, чтобы он не попал в неудобную для него ситуацию. В качестве примера могу привести следующее:
Как-то раз, работая в одной компании, меня закинули на проект. А я не знал абсолютно ничего. Единственные вводные — это Bitrix24, там нужно что-то протестить. Меня добавили в чат, и я начал искать информацию. Информацию не нашел и задал вопрос в чате.
Но помощь не пришла. Я уже хотел написать одному из коллег: «Леха, ты можешь мне помочь?». Как впоследствии оказалось, Леха был основателем и директором компании. Было бы немного неловко, если бы так ему написал. А в задачу ментора как раз и входит объяснить, кто есть кто.
Что же нужно сделать в первую очередь?
Познакомиться. Ментор должен написать новичку первым.
Озаботиться тем, что у новичка есть все доступы и нужные чаты.
А еще обязательно пригласить новичка на чай. В первые дни все занимаются тем, что подписывают документы, получают доступы. Обычно это занимает от 2 до 4 часов. После такого у новичка уже не будет энергии и мотивации, поэтому немного расслабиться за кружечкой чая — хорошее решение.
А если вы идете на обед группой — знакомство новичка со всеми в нерабочей обстановке пройдет легче, чем когда придется что-то спрашивать в рабочее время.
Не первый день
Теперь поговорим про переживание и ознакомление с проектом — иными словами, вещами, которые происходят не в первый день. Когда информация поступает в больших объемах, мы начинаем выглядеть примерно так:
Глаза смотрят в разные стороны, не знаешь, за что взяться. На данном этапе неважно, как новичок справится с этим: это могут быть тестовые run-ы или вообще вход на бой.
И ментор сталкивается с проблемами ниже:
1. Страх простых вопросов. К чему это может привести? Мы можем получить ситуацию, когда он столкнется с не вполне ясной логикой и поймет ее по-своему. А вопрос не задан, так как он думал, что время ментора того не стоит. Так легко и баг пропустить.
К чему может привести пропущенный баг? Если человек недавно в IT, то даже самый простой пропущенный баг, который он не завел, может привести к излишне сильной реакции. Страх, что за один баг на проде его уволят (даже не крит) — частое явление. Чтобы это преодолеть, можно задавать новичку вопросы в течение определенного периода — раз в неделю, два раза в неделю, раз в день: «Привет. Как дела? Все ли хорошо? Есть ли какие-то вопросы?».
2. «Я работаю хуже всех» — приходя на работу и выполняя задачи, невольно сравниваешь себя с другими. Для новичков проблема стоит более резко — часто они сравнивают себя с опытными спецами, которые имеют более высокий скилл и опыт в проекте. Для решения этого лучше всего отмечать успехи, что было сделано хорошо. Не отметить успех нельзя — от ментора ожидается хоть какая-то реакция на него. В идеале — давать фидбэк по истечении определенного времени.
Выводы:
Не оставляем новичка одного.
Постоянно выходим с ним на связь, помогаем ему, активно вовлекаем в разговоры.
Помогаем влиться в коллектив и даем фидбэк, отмечаем успехи и говорим в проблемных ситуациях.
Стараемся прийти к легкости в общении, потому что потом, когда вы уже перестанете быть его ментором, вы можете сталкиваться по задачам. Возможно, ему будет нужна ваша помощь. Или наоборот, вам его помощь.
Свободное плавание
Этот этап идет в связке с предыдущим, потому что новичок на нем учится все делать сам. В свободном плавании мы будем переходить от ответов на вопросы новичка к его перенаправлению на других специалистов и команды.
Что нам это дает? Налаживание связи и ориентирование по зонам ответственности команд. Он будет знать, к кому относится эта фича, кто что знает в команде, к кому можно обратиться с определенным вопросом.
Мы прокачиваем умение завести разговор и убираем стеснительность. Это довольно важный момент, потому что статья больше направлена на новичков в IT. Обычно это люди, которые знают об IT следующее — это много кэша, это весело, ни с кем не нужно особо разговаривать. Отчасти это так, но не все. Например, оказалось, что в IT надо много общаться. Это было не самым приятным для меня моментом, так что пришлось развивать свои soft skills.
В свободном плавании необходимо постепенно переходить от ответов на каждый вопрос на перенаправление его к другим командам, советовать искать инфу в документации или просто гуглить. В противном случае, не делая этого, мы получим сотрудника, который всегда будет идти к вам, не пытаясь решить проблему самостоятельно. Иногда это может приводить к моментам, когда замученный ментор будет едва ли не огрызаться и грубо отвечать на адресованный ему вопрос.
На этом этапе выделю проблемы, с которыми могут столкнуться и ментор, и новичок:
Первое — это преодоление себя. Вы стесняетесь, не хотите общаться, однако информация вам нужна. Поэтому придется однозначно себя перебарывать.
Не все коллеги вас любят и хотят общаться. Ситуация, когда вы пишете огромную портянку и просите помочь, а вам в ответ приходит пара слов, и вы понимаете чуть больше, чем ничего. С таким приходится работать и принимать.
Направлять с вопросами к другим тестерам и командам — нормально. Это нужно делать, чтобы элементарно вас не засыпали своими вопросами. Представьте ситуацию: у вас есть один лид, у него в команде 10 новичков, и каждый новичок ходит к нему раз в 15 минут и спрашивает: «Это баг?», «А это баг?», «Это так или не так?». Примерно через 2 недельки он перестанет отвечать. А через 4 уволится.
Людская молва про злого человека — не всегда правда. Как-то раз мне пришлось завести один баг, который по итогу просто-напросто отменили. Меня это взбесило. Я написал об этом в чате — мол, ребята, почему так? На это мне был один ответ: «Успокойся, он всегда так делает. Ему бесполезно писать, он тебя не будет слушать и даже не прочтет сообщение, и баг не восстановят». Я ему написал и через пару сообщений переписки он сказал: «Окей, восстанавливай, мы это поправим». Неважно, что про него говорили. Оказалось, что он адекватен. Отсюда вывод — не бойтесь задавать вопросы и не верьте тому, что говорят о человеке. Лучше узнать все самому.
В итоге хочется сказать, что от вашего отношения к стажеру зависит, как пройдет для него вхождение в компанию, а в отдельных случаях и в профессию. Будет это легко, без лишнего стресса или же наоборот. Если вы будете далее работать в одной команде и над одним проектом — еще и ваш собственный комфорт. Каждому приятнее заниматься своими задачами с людьми, которые близки ему по духу.
Спасибо, что дочитали статью до конца. Делитесь вашим опытом взаимодействия с новичками в комментариях, буду рад обратной связи.
