Менторство — один із потужних інструментів розвитку, який використовують IT-спеціалісти. Кожен фахівець колись звертався за порадою та настановами до більш досвідченого спеціаліста, а деякі системно працюють із менторами для вдосконалення навичок та пошуку власного шляху.
Про те, яких антисценаріїв у менторстві краще оминати та які поради давати початківцям в DevOps, Всеволод Поляков, Head of Infrastructure в Let’s Enhance, засновник спільноти UkrOps Club та телеграм-каналу «Українська Девопсарня», розповів на конференції DevOps fwdays’24. Публікуємо найцікавіші тези з виступу.
Ментор і менті: ролі та завдання
Перше, що має зробити ментор, — познайомитись зі своїм менті по-справжньому. Люди завжди намагаються бути кимось іншим. Хтось хоче здаватись крутішим, ніж він є хтось, навпаки, — слабшим, ніж насправді.
Як казав Доктор Хаус, усі люди брешуть. Для менторства не потрібно викривати усю брехню, а лише ту частину брехні, яка заважає людині вчитися та досягати вершин. Щоби зрозуміти, яку саме правду нам треба відкрити, найперше варто визначити що, власне, робить ментор та яка його роль.
Спитавши будь-якого фахівця, де він хоче опинитись, ви отримаєте відповіді типу: «хочу бути крутим спецом», «щоби мене усі поважали», «щоби були гроші», «щоби до мене на суперджетах прилітали люди й питали професійної поради» тощо. Ментору важливо розуміти, що саме мотивує менті на навчання.
Антисценарій №1. «Хочу на ручки»
Якщо ми цього не розуміємо, дуже просто опинитись у першому антисценарії. Проблема в тому, що часто у менторів виникає бажання просто взяти свого підопічного «на ручки» і на собі донести до тої точки, куди йому власне і потрібно. Здається, що це позбавить людину непотрібних проблем та допоможе їй рости. Якщо ми когось беремо «на ручки» й несемо, а потім відпускаємо, то ця людина неминуче опиниться у тому місці, де починала. Ментор не несе свого підопічного, а показує шлях, розповідає, як розв’язувати проблеми, що трапляються на ньому. Людина має відчувати цінність знань, які вона здобуває самостійно.
Коли ми визначились, де людина хоче опинитись, то наступна задача — зрозуміти, де вона знаходиться зараз. Якщо це джун, варто розпочати з нетехнічного інтерв'ю.
У випадку з сеньорами і мідлами обов’язкове також технічне інтерв’ю.
Антисценарій №2. «Сумно жити»
Іноді я зустрічаю людей, у яких нема мотивації, яким сумно жити, які пам'ятають, що колись було цікаво й азартно розбиратися з новими технологіями. А зараз все одне і те саме, і незрозуміло, навіщо щось учити.
Моя думка — тут немає потреби в менторі, а є потреба у фахівцеві з психології. Тому що мотивація — це не проста штука. Якщо людина не має мотивації вчитися, розбирати щось самостійно, то це означає, що є проблеми з якимись позаробочими питаннями в її житті. Це можуть бути стосунки, шлюб, може депресія з інших причин. Це потребує роботи із відповідним спеціалістом. Немає нічого гіршого і складнішого, аніж намагатись заохотити людину з подібними проблемами щось робити й розвиватись.
Коли треба сказати «ні»
Велика частина роботи ментора полягає в тому, щоби навчитись правильно і вчасно відмовляти. Якщо ви лише починаєте менторити, не відмовляйте нікому, окрім фахівців з антисценаріями, що описані вище. Лише працюючи з людьми, ви можете зрозуміти, які ваші сторони сильні. З ким ви вмієте працювати, з ким — ні.
Кожному, хто хоче стати ментором чи хто хоче розвиватись самостійно, важливо зрозуміти, що він не здатен робити. Наприклад, я не вмію працювати з невмотивованими людьми. Я не вмію бігати за людьми. Для мене це відчувається як боротьба, яку я не люблю. Хтось, навпаки, любить цей виклик, а не хоче працювати з іншими аспектами або менті з певними рисами.
Варто сфокусуватись на тих людях, яких вам приємно вчити. Для тих, хто не підходить вам, знайдуться інші ментори, що підійдуть ідеально.
Що є менторством
Інший важливий поінт — розрізняти менторство і навчання. Я давно намагаюсь підняти рівень української DevOps-спільноти, залучити до неї якомога більше людей. Спочатку я почав просто розмовляти з друзями й лідити команду. Потім створив ком’юніті, почав виступати. І декілька років тому вирішив, що можу зробити курс DevOps.
Над планом курсу я працював три місяці, і врешті пішов до інституту Projector, аби вести там цей курс. Спочатку я показав їм план з 50 тем. Виявилось, що це занадто. Оптимальна кількість тем — три, а краще одна, сказали мені. Я взяв тему про системне програмування в Linux, і в процесі розробки теми зрозумів, що просто переписую підручник — в цьому немає жодної творчості. Подумав — навіщо мені писати ще один курс, якщо я можу просто порекомендувати менті ті курси та підручники, що вже існують. Ментор не має навчати, ментор має бачити, що людині не вистачає, і направляти її вірним шляхом.
Уявімо, що наш менті, — це фахівець-джун, який хоче заробляти більше грошей або людина, яка хоче зайти в IT. Найперше, треба зробити так, щоб менті знайшов роботу. Кожному потрібна мета. Тож на першій менторській сесії ми визначаємо мету та інструменти, за допомогою яких ми будемо до неї рухатись.
Наприклад, ми разом шукаємо, як найкраще продати кандидата потенційному роботодавцю: показати, що початківець вміє навчатись та замотивований швидко опановувати нову інформацію. Тому я, як ментор, тут буду радити, наприклад, пройти навчання на сертифікацію AWS DevOps. Процес навчання й отримання сертифіката дуже простий, але роботодавець бачитиме, що кандидат вже доклав зусиль і має мінімальні знання.
Буває й інша ситуація: приходить менті-сеньор, який не знає Kubernetes, і хоче знайти високу посаду, але без опанування цієї системи розгортання. Тут я теж раджу пройти курс по Kubernetеs і отримати сертифікацію. Звичайно, це не зробить із людини спеціаліста із Кубу, але роботодавець побачить, що той готовий навчатись. Такий підхід також допомагає з тим, щоби світчнутись між сферами, наприклад перестрибнути з Bare Metal на клауд, або з Chef на Kubernetes тощо.
Якщо ми знаємо, де людина хоче опинитися, ми можемо дати менті завдання, наприклад, аби він пішов на LinkedIn і знайшов усі вакансії на джуна, які існують. І потім виписав чотири теми та чотири технології, які найчастіше зустрічаються в описі вакансій на джуна чи мідла. Зазвичай це AWS, CI/CD, Terraform, Docker і Kubernetes. І з кожної з цих тем є багато курсів і сертифікацій. Можна порекомендувати курс, книгу, або ж порадити кандидату знайти на YouTube такого спікера, у якого йому сподобається голос, подача тощо. Можна також давати невеликі завдання типу створити репо на GitHub, pull request, написати докер-файл і таке інше.
Якщо менті каже: хочу заробляти вдвічі більше грошей на системному програмуванні. Тут моя задача як ментора пояснити, що це працює по-іншому: більше грошей за знання Linux не платять. Більше грошей платять за проведення співбесід, за вирішення бізнес-питань, за те, як фахівець може вирішувати бізнес-проблеми. Тому задля вищої зарплати фахівець має показати компанії, як він може розв'язати її проблеми.
Я особисто дуже рекомендую паралельно розвивати софт-скіли: спілкування з колегами, вміння брати на себе відповідальність, здатність шукати й знаходити оптимальні рішення. І ще вчити мови — англійську, французьку, іспанську, інші. Це додасть поінтів до резюме, до зарплати, до загального рівня підготовки.
Як зрозуміти, що треба завершувати менторство?
Ментору важливо оцінювати якість власної роботи та обсяг користі, який він приносить іншій людині. Важливо відстежувати всі зміни та питати, чи є користь від менторства. Важливо бути дуже критичним до себе — чи ви приносите користь людині, чи ви просто користуєтесь авторитетом, який завоювали раніше та просто конкуруєте з менті. Якщо ви відчуваєте, що є конкуренція, то це вірна ознака того, що треба прощатися одне з одним.
Не варто брати на себе відповідальність за життя іншої людини. Важливо відокремлювати себе від підопічного, зберігати здатність відійти вбік та сказати собі — якщо людина десь зупиняється чи йде повільно, то це її життя і це ок.
Кожна людина реалізує свої ідеї та йде своїм шляхом. І навіть якщо ми пройшли разом лише певний відрізок цього шляху, це також може бути корисно.
