Призвание быть наставником
Привет, Хабр! Меня зовут Данила Гриднев. Я занимаю должность Software Engineering Manager, курирую бэкенд‑разработку различных проектов, созданных на базе блокчейн‑платформы компании Web3 Tech. Помимо этого, я уже не первый год занимаюсь онбордингом и менторством разработчиков, как начинающих, так и уже более опытных. В этом посте я постарался систематизировать свой опыт наставничества, описав его ключевые этапы и принципы. Содержание статьи по возможности абстрагировано от технических деталей, поэтому будет полезно широкому кругу читателей.
Я начинал с того, что был репетитором по математике, готовил школьников к ЕГЭ, вел также групповые курсы по подготовке к этому экзамену. Когда я попал в Web3 Tech, мою потребность передавать знания другим разглядел экс-руководитель отдела разработок и мой непосредственный наставник Степан Кашинцев. Мое желание совпало с задачами компании, и я использовал эту возможность по максимуму.
Чтобы после прочтения этой статьи в вашей голове не просто появились новые знания, но они были еще и разложены по полочкам, я описал погружение в тему наставничества в системном виде.
Содержание
Собеседование
Интервью — это первый, ключевой этап вашей работы, когда вы принимаете решение по поводу человека, над которым хотите взять наставничество.
Осознайте ожидания от кандидата. Чего вы сами хотите добиться в этом сотрудничестве? Для кого именно вы хотите быть наставником? Составьте четкий чек-лист критичных требований к кандидату, также обозначьте второстепенные требования и то, что в принципе для вас неважно.
Поймите ожидания от вас.Узнайте во время собеседования или, если возможно, до собеседования, что кандидат ожидает от вас как от наставника. Если не получается сделать это самостоятельно, привлеките HR-специалиста в качестве посредника. Поймите, чего хочет человек, как он видит свое пребывание в компании и вас как наставника. Быть может, вы или компания в принципе не смогут ему это дать.
Берите только в случае совпадения взаимных ожиданий.Если вас что-то категорически не устраивает в кандидате. Если вам просто некомфортно общаться с человеком, потому что он вас, например, перебивает. Если вы вдруг чувствуете себя так, будто это вы к нему пришли устраиваться на работу. Если человек не владеет какими-либо критичными для вас хард-скилами и не хочет их освоить. Если срабатывают другие личные критерии. Во всех этих случаях не стоит соглашаться на дальнейшую работу и идти на полумеры. Вы все равно расстанетесь с человеком, но при этом потратите впустую ресурсы. Либо вы оба выигрываете от этого сотрудничества, либо не начинаете его совсем.
Два с лишним года назад у нас в компании появился Михаил — перспективный джун-джавист и мой подопечный. Сейчас он уже руководит разработкой на одном из проектов в компании. Очень крутой рост. При подготовке к митапу я попросил Мишу написать отзыв о моей менторской работе, и Миша разделил его на три части.
По этапам, описанным Мишей, я бы разделил весь трек работы наставника в принципе.
1 этап. Помогите начать
Начальный этап очень важен и, к сожалению, многими недооценен. Именно здесь закладываются ключевые фундаментальные навыки, зарождаются жизненно необходимые привычки и формируются зачатки правильного проактивного мышления. Главное здесь — помочь подопечному встать на «Путь Истинный». Далее я опишу ключевые моменты 1-ого этапа в ракурсе четырех основных аспектов:
Development. Разработка в широком смысле этого слова. Работа над любыми повседневными задачами, которые стоят перед специалистом в его роли.
Code Review. Обратная связь. Конструктивная критика. Взгляд со стороны.
Problem Solving. Решение регулярно возникающих проблем.
Time Management. Управление своим рабочим временем.
Development
Призовите к ответственности за свою задачу. Донесите, что у вас взаимовыгодное сотрудничество: есть ваша роль как наставника и его роль как вашего подопечного. Ваша ответственность — призвать его к ответственности. Звучит как тавтология, но по факту — так оно и есть.
Сфокусируйте на самостоятельном ее выполнении. Не решайте задачу за подопечного, но донесите: если что, вы рядом и можете помочь.
Донесите смысл баланса цены/качества.На позиции лида разработки я постоянно задумываюсь: нужно ли что-то делать, дорого ли это. Чем раньше специалист начнет задаваться такими вопросами, тем проще ему будет впоследствии.
Code Review
Оценивайте код, а не человека. Не переходите на личности. Отдельно проговорите, что ваша критика касается исключительно его кода, а против него как человека вы ничего не имеете.
Хвалите за удачные решения. Обязательно хвалите за то, что получается. Старайтесь делать это при всех, на больших встречах или, например, в общих чатах, чтобы успех был более заметен. Чем больше людей станут свидетелями успеха, тем больше вдохновения получит герой для дальнейшей работы.
Подсвечивайте точки роста. Если у подопечного что-либо не получается, обратите на это внимание в личном общении. В крайнем случае в присутствии вашей маленькой команды. Обратная связь при этом должна быть конструктивной и аргументированной.
Объясните необходимость в перекрестном ревью. Некоторые думают, что ревьюить нужно только джунов, а Великий Оракул, воплощенный в техлиде, пишет идеальный код, который не нуждается в проверке. Это не так — ошибку может сделать каждый. Помимо этого, ревью нужно не только автору, но и ревьюеру, ведь это очень расширяет кругозор и развивает способность читать и понимать чужой код.
Научите адекватно воспринимать/давать критику. Это ключевой навык, с которым человеку предстоит прожить всю жизнь. К сожалению, новичок может дорасти даже до сеньора, так и не научившись воспринимать критику. Работать с ним тогда будет очень непросто: код-ревью превращаются в масштабные холивары, которые забирают все ресурсы.
Минимизируйте количество итераций ревью. В идеале ревью должно умещаться в одну итерацию — выложили, откомментили, исправили, залили. На практике ревью может растянуться до двух-трех итераций: это нормально, если согласовать должны одновременно несколько человек. Важно прийти к хорошему балансу цены/качества и не забывать о сроках.
Следите за качеством кода и принятых решений. Зачастую разработчики с небольшим опытом изобретают велосипеды и повторяют то, что уже было сделано до них. Даже профессионал, не зная об особенностях проекта, рискует повторить этот путь. Ваша задача — знать эти особенности и объяснить их подопечному.
Требуйте максимального покрытия. Это полезно не только для выполнения конкретных задач, но и для повышения качества проекта в целом.
Призывайте писать код для людей, а не для машин. Это придумал не я, это сказал небезызвестный в мире разработки ПО Мартин Фаулер.
Problem Solving
Дайте возможность совершать свои ошибки и исправлять их. Пусть ваш подопечный где-то облажается, увидит это и переживет последствия. Не тряситесь над ним, дайте ошибиться. Предположим, вы заранее из своего опыта знаете, что после его ошибки будут вполне конкретные последствия. Вы говорите об этом и получаете в ответ «всё будет нормально». Отпустите ситуацию, пусть ваш сценарий воплотится. Подопечный сам всё поймет и исправит. Пусть это дополнительно отнимет пару часов рабочего времени — пережить весь цикл траблшутинга «от первого лица» бесценно. Вы можете делиться опытом и опасениями, но не пытайтесь уберечь от всех на свете ошибок — это нереальная, недостижимая и ненужная цель.
Не бегите решать его проблему, даже если вы уже знаете решение.Наставникам иногда кажется, что без них никто ничего не может сделать. Это не так. Наш мозг обманывает нас. Да, вы наверняка знаете, как правильно выйти из ситуации, но оттащите себя за волосы — пусть человек дойдет до решения сам. Это будет гораздо полезней для его профессионального развития, а ведь именно этого вы по-настоящему и хотите, как его ментор, не правда ли?
Уважайте коллегу. Не отвечайте на вопросы, заданные ему. Ценный эмпатический навык, уместный не только в отношениях «наставник — подопечный». Если вы замечаете, что любите отвечать на вопросы, заданные не вам, это нужно исправлять. Выше я писал, что каждый специалист должен принять ответственность за свою задачу. Вы, как наставник, при этом тоже всегда должны держать в своей голове: он отвечает за задачу, а значит, и на вопросы, которые по ней задают. Дождитесь его ответа. Если же его не последовало, обсудите проблему вдвоем. В крайнем случае предложите ему в следующий раз тегнуть вас и только тогда вступайте в беседу.
Разделите ответственность за ошибки перед остальными. Ваш подопечный наверняка будет сильно огорчаться из-за своих ошибок. Помогите нести этот груз. На разборе полетов признайтесь перед всеми: «Мы ошиблись». Психологически падавану сразу станет легче.
Давайте негативную критику только в личном общении. Не надо песочить коллегу перед всеми. Договоритесь о созвоне, обсудите всё лично и двигайтесь дальше. Не забывайте, что мы критикуем не человека, а его рабочие решения и код.
Помогите отрефлексировать пережитый опыт совершения ошибок. Поначалу любые ошибки могут повергнуть в панику: «О нет, я ошибся, меня уволят». Научите подопечного видеть здесь профит, акцентируйте внимание на том, чему он научился благодаря ошибке.
Приучайте находить оптимальное решение в текущем контексте. Проблемы бывают разные, не стоит каждый раз сломя голову решать сразу всё. Иногда разумно понизить приоритет одних задач по отношению к другим, выстроить очередь. Самая простая схема здесь — научить классифицировать задачи по четырем группам в разрезе важности/срочности: важное срочное, важное несрочное, неважное срочное, неважное несрочное.
Развивайте переключаемость между разработкой и решением проблем. Весь рабочий процесс можно разделить на эти два потока, и между ними нужно уметь сохранять баланс.
Прокачивайте прогнозирование потенциальных проблем. Решать проблемы — это крутой навык, но еще круче проблемы прогнозировать, чтобы избегать их в будущем. Правда, чтобы научиться прогнозировать потенциальную проблему, порой нужно не раз с ней столкнуться и не раз ее решить.
Time Management
Начинающие разработчики не сразу понимают, что время — это такой же ресурс, как и деньги. Компания покупает этот ресурс за зарплату. Это может показаться меркантильным и циничным, но в такой плоскости человеку становится понятно, сколько стоит его час или рабочий день. Нужно донести до падавана, что оценка времени в Jira предусмотрена не просто так и время нужно ценить.
Цените время друг друга. И в созвонах, и в переписках, и вообще везде. Приучите подопечного, прежде чем задать вопрос, думать: может ли он ответить на него сам? Часто оказывается, что да. Тогда зачем тратить время наставника или другого коллеги? Кстати, то же самое справедливо и для самого ментора: важно ценить время своего падавана.
Призывайте логировать работу. Пусть ваш коллега трекает весь прогресс в Jira. Это прокачивает осознанность и адекватность в планировании времени и дает более четкое понимание процесса работы над задачей.
Привлекайте к оценке задач. Чтобы научиться оценивать время, нужно делать это как можно чаще. Когда вы привлекаете подопечного к оценке задач, то помогаете и себе, и ему — соизмерять желания и возможности в работе, как свои, так и коллег.
2 этап. Вдохновите расти
Приведу слова другого своего падавана, Алексея:
Опираясь на опыт Лёши, я выделил на втором этапе две важные темы: личный пример и передача опыта.
Личный пример
Вы не сможете вдохновить человека, если сами не будете делать то, чему хотите его научить. Ничто не работает лучше, чем личный пример.
Относитесь ответственно к делу. И он тоже будет становится ответственнее.
Изучайте Best Practices. И он тоже возьмет их на вооружение.
Развивайтесь постоянно. И он тоже будет развиваться.
Это важно зафиксировать каждому ментору. Вспоминаю свой вуз: я пять лет учился в МИФИ. Лучше всего запомнил одного преподавателя: его предметами были компьютерные сети и Java. На нашей кафедре он умудрился развернуть highload-сценарии на видеокартах и вообще делал очень много интересных вещей. На лекциях не занудствовал про какой-то Fortran из 60-х, а делился с нами последними достижениями, тем, что узнавал сам, постоянно развиваясь. Я писал у него диплом, и это, кстати, был мой первый опыт разработки. Вот такой личный пример :)
Передача опыта
Вы можете стать замечательным личным примером с прекрасным личным опытом, но этого, к сожалению, недостаточно.
Рассказывайте про успешные решения и выигрыш от них. Не скромничайте излишне. Делитесь тем, что и как вам пригодилось в работе, какой профит вы получили.
Делитесь провалами и их последствиями. Не бойтесь показаться глупым. Однажды меня уволили из компании, потому что я не укладывался в сроки, задерживал код-ревью, не учитывал баланс цены/качества. Болезненный и бесценный опыт, по итогам которого я многое понял. Сейчас я рассказываю об этом другим, и от этого меня не стали меньше уважать. Делиться негативным опытом не стыдно.
Будьте честными и открытыми. Не жадничайте. Не прячьтесь. Говорите, что думаете — прямо, но в то же время с мудростью.
Покажите как пользоваться удочкой, а не просто угощайте готовой рыбой. Всегда есть соблазн дать всё готовое, это быстрее, проще и не требует наличия навыков крутого наставника. Но если вы хотите вырастить специалиста, с которым хочется работать в команде, который будет сам решать сложные задачи, научите его пользоваться удочкой.
Научите задавать правильные вопросы и самостоятельно искать на них ответы. Наша культура образования построена таким образом, что задавать вопросы — это плохо: «Что за глупые вопросы, ты чё, дурак?» Если мы и осмеливаемся задавать вопросы, то задаем их только одному человеку — учителю. Но этот учитель (в данный момент — наставник) может не знать ответов на всё. Поэтому важно научить падавана задавать вопросы и самому себе, и любому другому человеку, и интернету.
Призывайте делиться полученными знаниями с другими. Узнал что-нибудь новое? Молодец! Напиши об этом статью, проведи митап, расскажи на стендапе, поделись другим способом. Твой опыт — это не «твоя прелесть», как у Голлума из «Властелина колец». Будьте щедрыми сами и воспитывайте щедрость. Когда человек делится опытом, он сам переживает его глубже.
Откажитесь от параноидального тотального контроля. Не будьте наседкой, он справится, решит всё сам. Дайте пространство для роста. Если он увидит доверие с вашей стороны, то будет расти быстрее.
Доверяйте декомпозицию и оценку задач, решение проблем прода и т. д., в зависимости от вашей сферы. Чем более разнообразные задачи вы делегируете, тем быстрее вырастет профессионал. Ваш подопечный сможет лучше понимать процессы, команду, проект, станет более адекватным, самостоятельным и ответственным.
Делегируйте часть своих обязательств на время своего отсутствия. Так ваш падаван будет чувствовать себя всё уверенней. Но все-таки на время отсутствия стоит сохранить канал для связи, чтобы в крайнем случае он мог вам написать.
Завершить рассказ о втором этапе наставничества хочу фразой одного миллиардера, основателя многих бизнесов и своей бизнес-школы:
Отключите зависть, если ваш падаван достигнет джедайских высот в несколько раз быстрее, чем вы. Выше я рассказывал о Михаиле, за два года он вырос до руководителя разработки. У меня же этот путь занял гораздо больше времени. Но я горжусь, что был среди тех, кто помог Мише. Если ваш коллега быстро развивается, порадуйтесь, какой вы классный наставник. Его успех — это ваш успех.
3 этап. Станьте ненужным
Здесь, в принципе, всё понятно из названия. Нужно уточнить лишь то, что вы становитесь ненужным именно как наставник, но остаетесь в прекрасных отношениях как коллега. Результаты вашего наставничества могут быть разные — человек может прийти либо к внешней, либо к внутренней мотивации. Посмотрите на две картинки: кого бы вы хотели видеть в качестве коллеги?
Так выглядит внешняя мотивация.
Распространенный вариант здесь — деньги. Вам повышают зарплату, вы получаете буст мотивации, но через некоторое время он точно сойдет на нет. Если у компании нет денег для нового буста, вы будете демотивированы. Внешняя мотивация зависит от внешних факторов — поэтому она временна, ненадежна и неэффективна.
Так выглядит внутренняя мотивация.
Она позволяет сохранять желание и работоспособность вне зависимости от внешних факторов. Это помогает добиваться крутых результатов, несмотря ни на что. В ваших интересах перетянуть падавана ближе к этой стороне силы — ведь вам с ним еще самому работать. Кстати, именно с такой внутренней мотивацией я сейчас и пишу для вас этот пост :)
3 принципа наставничества
Здесь я передаю слово еще одной моей подопечной, Саше:
На основе фидбэка Саши я выделил три принципа наставничества. Они тесно перекликаются с тремя этапами выше, но я выделил их отдельно, поскольку ими можно пользоваться на любом этапе.
Помогите обрести независимость. Поначалу новичок чувствует себя зависимым от вас, и это естественно. В компании он воспринимает вас как родителя. Но дети в определенный момент отделяются от родителей — и его путь с вами должен быть таким же. В конце концов, новичок должен стать равным вам, и это возможно, только если он обрел независимость.
Научите эффективному сотрудничеству. С вами, с другими членами команды, со всеми. Например, когда тестировщики будут проверять код вашего подопечного, то будут опираться на стори. Но в стори не всегда перечислены все нюансы, которые нужно проверить на этапе тестирования. Научите подопечного понимать, требует ли его решение пояснений, которые облегчат жизнь другим. В конце концов, это выгодно и ему — не придется потом отвлекаться на дополнительные вопросы. С другой стороны, научите новичка отслеживать, когда с вопросами не приходят вовсе: возможно, коллеги даже не знают о том, что нужно что-то проверить. И сделайте так, чтобы вы не были для своего подопечного единственным окном в мир. Если, например, упал какой-то стенд, пусть он сразу пишет в чат девопсам. Если появилась новая задача, пусть сразу идет к аналитику. Так прокачиваются коммуникации, навыки взаимовыгодного сотрудничества, выражение своей позиции и не только. В вас как в прокси нет необходимости :)
Выстройте культуру доверия. Да, мы все делаем серьезную работу. Но она занимает столько времени, что стоит получать удовольствие не только от результата, но и от самого процесса, в том числе и от коммуникаций. Легкое общение не получается само собой, особенно у начинающих сотрудников. Нужно создать такую обстановку, чтобы подопечный доверял вам и хотел с вами общаться, делился не только успехами, но и неудачами — и мог получить при этом адекватную обратную связь.
Главная цель наставничества
Когда-то у Стивена Кови в книге «Восьмой навык. От эффективности к величию» я подглядел вот такую концепцию, которая оказалась мне очень близка:
Я согласен с Кови и верю в то, что каждый человек — это уникальная значимая личность. У каждого из нас есть Голос — некое призвание, предназначение, кодекс души. Голос можно обрести, занимаясь работой, которая:
раскрывает ваш Талант — разнообразные врожденные дарования и достоинства;
питает ваш Энтузиазм — то, что стимулирует вас, мотивирует и вдохновляет;
возникает из-за существования в мире Потребности — настолько важной и ценной, что вам готовы за это платить;
к выполнению которой подталкивает ваша Совесть — интуиция, подсказывающая вам, что правильно, а что нет, побуждает к тем или иным действиям.
У наставников тоже есть свой Голос — Голос Наставника:
Талант Наставника, его дар — это определенная способность наставлять других людей.
Энтузиазм Наставника — когда вас, грубо говоря, прёт от достижений своих подопечных, от их результата, от их роста.
Потребность в Наставнике — это независимый внешний фактор, определяющий в принципе необходимость в наставничестве.
Совесть Наставника — интуиция, постоянно подталкивающая его к тому, чтобы передавать свои знания и опыт другим.
Ответьте себе честно на вопрос: «А живет ли во мне голос наставника?». Не у каждого складываются все четыре слагаемых — и это нормально. Если внутри вас не живет этот голос, признайтесь в этом себе и другим. Значит, ваша «фишка» в чем-то другом, необходимо лишь разглядеть и реализовать ее.
Конечно, вы в любом случае можете быть наставником, вопрос лишь в эффективности. Помните, что самые успешные люди — те, которые воплощают свой внутренний голос в жизни. Не нужно насиловать себя наставничеством или чем-то еще — это быстрый путь к выгоранию. Оставайтесь адекватны и ищите свой голос дальше.
Голос наставника — в том, чтобы помогать другим людям распознать и реализовать их голоса. Задача эта весьма нетривиальна, поэтому я верю в то, что быть наставником — это определенное Призвание. Миссия, если хотите. Свое Призвание я отчасти распознал. Почему отчасти? Потому что познание своего внутреннего голоса — это, конечно же, не конечная точка, а путь всей жизни. По дороге свой голос раскрывается все полнее и полнее. И со временем обнаруживаешь в себе новые глубины и возможности.
А в чем ваш голос?
