«Ти ідіот!», «загугли!». Розбираємо три історії невдалого менторства в ІТ

Менторство в ІТ — перевірений шлях для прокачування навичок, пізнання нового та успішної інтеграції в нову команду. Однак не завжди комунікація між ментором та менті йде за планом. Подекуди виникають непорозуміння, ігнорування чи навіть агресія.

Ми поговорили з трьома айтівцями про їхній негативний досвід роботи з менторами та попросили досвідчених менторів дати поради про те, як діяти у таких ситуаціях обом сторонам.

Історія 1: Вадим. Ментор без менторства

Нещодавно я потрапив на позицію аналітика баз даних. Для цієї посади потрібен досвід роботи безпосередньо з базами даних і знання мови програмування SQL. Я вивчив усе це на курсах, і це була моя перша робота за новою спеціальністю. Тому за мною одразу закріпили ментора і сказали, що до нього можна звертатися під час онбордингу та роботи з клієнтами. У перший місяць проблем і питань не виникало, адже «реальних» завдань мені не давали, однак згодом кейси ускладнилися, моментами ставало складно, і з’явилася потреба уточнювати деякі питання. Я почав звертатися до ментора. Реагував він, м’яко кажучи, неохоче — жодного разу прямо та детально не відповів на мої запитання. За майже рік роботи в нас не було жодної позапланової зустрічі.

Натомість я отримував типові «та це ж елементарно», «подивися в документації», «загугли». Я почав гуглити та розбиратися, шукати самостійно, хоча не мав жодної структури пошуку. Жодної підтримки не було.

Єдина зустріч щодо мого стажування відбулася за два чи три місяці від початку роботи: я, ментор та мій безпосередній керівник. Керівник з ментором обговорювали мої успіхи при мені. Я сказав, що мене не дуже влаштовує таке менторство, адже я досі не маю достатньо інформації. Мені порадили й надалі звертатися до ментора. За деякий час мене скоротили. Я був дуже радий.

Олекс Майстренко, радник заступника голови Київської міської державної адміністрації, колишній Head of Engineering

Важливо зрозуміти, чи були вирівняні очікування між ментором, менті та людиною чи організацією, яка створювала цей процес. Підозрюю, що ні. Ментор має розуміти, що від нього очікують; а людина, яка прикріплює його до менті, має попереджати про його рівень знань і навичок. Інакше може статися ситуація, за якої ментор вимагатиме від менті більше, ніж той може дати. Також цікаво, чи виділили ментору вдосталь часу для виконання своїх основних завдань і роботи з Вадимом. Якщо ні, то ментор міг просто відкидати цю роботу як низькопріоритетну.

Крім того, ментором має бути підготовлена людина. Не кожен інженер може ділитися своїми знаннями. Запитання Вадима можуть видаватися ментору елементарними, тому він не може дати корисних порад.

До Вадима варто ставитись поблажливо, оскільки він менті та нова людина в компанії. Але цікаво дізнатися, як саме він ставив ментору запитання. Від цього також залежать дії ментора.

Припустимо, він вважав, що ментор має виділяти на нього більше часу, якого той не мав. Саме тому над цим завданням мали попрацювати троє: ментор, менті та їхній керівник. Вадим мав би прокомунікувати всі питання, розповісти менеджеру про те, що саме не працює, а ще обговорити це з ментором. Тож у цьому випадку причиною поганої роботи може бути кожен учасник. Ментор має питати про зворотний зв’язок, а Вадим має його надавати.

Щодо «загугли»: людина може не знати, що саме гуглити, чи інформації може не бути в публічному доступі. Звісно, є сенс налаштувати спеціаліста на самостійний пошук, який є надзвичайно важливим, однак варто залишатися відкритим для уточнень і запитань, які виникнуть після самостійної роботи.

Артем Биковець, CEO / Organizational & Agile Coach у Simplesense

Такі проблеми доволі поширені. Ймовірно, ментор має недостатньо інструментів у своєму «менторському саквояжі», або ж йому просто бракує часу чи він лінується ними користуватися. Тоді людина не схильна до рефлексії.

Щодо менторів, які звикли казати людям «піди погугли». Є безліч способів та ресурсів, які можна використовувати для навчання початківців. Матеріали з посиланнями — серед них. Можна давати завдання в сендбоксі, щоби людина показала, що може зробити сама і, можливо, припустилася кількох помилок. Згодом їх можна розібрати та здобути новий досвід. Усе це ефективніше за «погугли», адже в мережі можна знайти велику кількість невідповідної інформації та начитатися місцевих «експертів», чиї поради зроблять лише гірше.

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

У ситуації з Вадимом можна сказати, що ментор був лише проксі між ним та Google. Вадиму та іншим початківцям я порадив би не чекати критичного моменту. Завжди треба проговорювати обов’язки та очікування, а також невдоволення. На мою думку, проговорювати та систематизувати процес має ментор. Попри все, він має знаходити підхід до кожного підлеглого та скеровувати роботу в правильне русло. А далі — домовлятися про зустрічі та міряти прогрес. Якщо якась зі сторін не виконує своїх завдань, варто обговорювати та знаходити підхід. Усе це — про домовленості та очікування.

Історія 2: Олег. Ментор, який переходить на особистості

Перший негативний досвід менторства був пов’язаний з тим, що я не зрозумів, що ментор — не твій друг, а просто людина, яка виконує свою роботу. З погляду менті складно зрозуміти, що наставник не завжди буде поруч й іноді варто самому шукати інформацію. Однак мій другий негативний досвід полягав у тому, що ментор просив мене самостійно шукати інформацію постійно.

Я тільки перейшов на новий проєкт, і мої очікування щодо його складності були дещо занижені. Тому ментор вимагав від мене більше, ніж я міг дати. Через це часто виникали конфлікти. Траплялося, що він переходив на особисті: «Ти ідіот, навіщо ти це зробив?!» тощо. Такого тиску ставало дедалі більше. Все дійшло до того, що він сказав «гугли самостійно», попри те, що деяку інформацію знайти в мережі неможливо.

Згодом я просто попросив перевести мене на інший проєкт. Про причини не запитували — я сказав, що не зрозумів матеріал. Ментор залишився в команді. Я дізнався, що до мене було ще три людини, які намагалися працювати в цій команді: одну перевели на інший проєкт, ще двох звільнили. Як я зрозумів, ця людина — хороший сольний робітник, але працювати в команді з ним не вдається.

Артем Биковець, CEO / Organizational & Agile Coach у Simplesense

Токсичні та неприйнятні стосунки треба припиняти. Можна дати фідбек ментору прямо. За описаною ситуацією ментор усім задоволений і певен, що в нього все чудово виходить. У таких випадках завжди є запитання до компанії. Це не лише проблема між ментором та менті. Якщо в компанії є HR (їхня робота полягає не лише в замовленні кави, а й у взаємодії з людьми), то вони мають увімкнутися в процес і розібратися, чому на менторських та лідерських позиціях такі люди.

На захист ментора скажу, що, можливо, це така команда. У деяких командах нецензурна лексика та перехід на особистості є нормальним типом відносин. Я мав досвід роботи в колективі, де ми стабільно «цитували Подерв’янського», підколювали одне одного і тролили. І це було нормою. Тому є вірогідність, що це специфічна команда, де неправильно налаштований процес наймання. Але це все одно мають вирішувати на вищому рівні, і керівництву необхідно пояснити, чого саме чекають від людини в ролі ментора та від менті.

Як завжди, все впирається в очікування та комунікацію. Я викладав на ФІОТі й бачив, за якої рольової моделі спеціалістів випускають з університету. Це воїн-одинак, не командний гравець. Здебільшого це хороші соло-кодери, технічно ідеально підковані, але без прокачаних навичок спілкування. Важко очікувати від них вміння прозоро пояснити, що вони хочуть і чим не задоволені. Про такі випадки варто говорити керівникові й підсвічувати проблеми.

Олекс Майстренко, радник заступника голови Київської міської державної адміністрації, колишній Head of Engineering

За своєї кар’єри я менторив у позаробочий час на волонтерських засадах. Тому дивно чути, що люди на громадських засадах вкладаються і намагаються зробити все як слід, а фахівці, яким платять, поводяться так, як в історії Олега.

Тут я також більшу відповідальність перекладаю на ментора, оскільки він не має права переходити на особистості або вживати нецензурну лексику, якщо це оговорено та не толерується компанією. Перш ніж братися до наставництва, мали визначити з людиною, яка це менторство призначає: що очікують від ментора, що він має робити й що робить не так. Робота має вестись і з боку компанії. Якщо така людина толерується і далі працює, то звучить це дуже токсично і проблема саме в керівництві.

Історія 3. Олександр, менторство на курсах

Проблеми виникли з першого дня — у більшості людей не було доступу до Moodle (там здавали завдання на перевірку). До кінця випробувального тижня деякі студенти так і не отримали доступ, хоча на мітингах керівництво курсів запевняло, що на всі запити відповідало. Завдання були хоч і не важкими, але відверто «відірваними від світу»: не думаю, що обчислення факторіала чи сума діапазону між двома значеннями потрібна нам у майбутньому. Я отримував хороші оцінки. Коротко про оцінювання: зайвий пробіл — одразу мінус бал, тому це був гарний досвід у плані форматування. І на цьому, напевно, все.

Фідбеку щодо завдань я геть не отримував. Потім мали бути невеликі мітинги з ментором. Говорили, що на всіх вистачить часу. Наприкінці поспілкувалися лише з офлайн-інтернами, на онлайн було наплювати. Наприкінці тижня нас зібрали й без жодної конкретики сказали: «Ви не проходите, ми не готові працювати з онлайн-інтернами». І після цього всім заблокували доступ до чатів.

Окремо хочу сказати про ментора — це найгірший ментор у моєму житті, людина комунікувала з нами на рівні «навіщо ви мені тут здались, швидше б вас позбутись».

Артем Биковець, CEO / Organizational & Agile Coach у Simplesense

На жаль, курсів, які обіцяють, але не виконують своїх зобов’язань, — безліч. Ментор просто мав би виконувати свою роботу, але чомусь «косив» від неї. В таких випадках усе ж можна особисто поспілкуватися з ментором; пояснити, що людина прийшла на курси заради певної цілі, а для її досягнення потрібна допомога ментора. Варто неконфліктно запитати, як вибудувати процес, щоб він не заважав іншим менті та роботі ментора.

Якщо контакт із ментором знайти неможливо або він провалився, то варто звернутись до того, хто продав вам цей курс і нагадати, що йдеться про фінансову угоду. Якщо й це не допомогло, ідіть до іншого викладача і просіть про допомогу. Не варто мовчати. Трапляється, що курси хороші, а один ментор — не на своєму місці. Буває й так, що на курсах погано все. Не треба толерувати роботу поганих менторів; але отримати те, за що заплатили — варто.

На чому базується успішне менторство

Олекс Майстренко, радник заступника голови Київської міської державної адміністрації, колишній Head of Engineering

Ментор — це людина, яка має внутрішнє натхнення та бажання вчити та допомагати іншим. Керівник, тимлід — це людина, яку призначили на таку посаду, а ментор має сам до цього прийти. Для цього варто мати бажання структурувати свій досвід і знання, ділитися ними з іншими та навчатися самому, отримувати зворотний зв’язок від людей. Водночас ментор має достатньо глибоко занурюватися в проблеми, з якими приходять менті, і надавати поради для їхнього руху. Не всі тимліди та керівники вміють навчати та структурувати свій досвід і подекуди діють ситуативно. Для ментора важливо структурувати знання та навички, а також вміти рефлексувати.

Важливо, щоби між ментором і менті була довіра, людина могла чесно поділитися всіма питаннями й не боялася щось уточнити. Звісно, як для менті, так і для ментора важливим елементом є самонавчання. ІТ-спільнота постійно розвивається та змінюється. Кількість інструментів для роботи збільшується, тож наставник має вчасно зрозуміти, що саме додати до «валізи знань», постійно її оновлювати.

Для мене важливий зворотний зв’язок від кожної людини: чи корисною була моя інформація, чи допоміг я людині розв’язати питання та структурувати навички. Завжди треба перевіряти, чи в правильному напрямі ми з менті рухаємося, що є корисним, а чого не вистачає. Завдяки цьому ментор також розумітиме, як йому професійно зростати. Крім того, від менті я очікую виконання домовленостей: якщо я дав завдання і спеціаліст на нього погодився, то я чекаю результату. До того ж і з боку ментора, і з боку менті має бути збережена конфіденційність розмов, якщо інше не погоджено.

Артем Биковець, CEO / Organizational & Agile Coach у Simplesense

Для роботи одного з клієнтів ми з командою на практичних прикладах визначили основні пункти, на чому має будуватися успішне менторство:

  1. Культура фідбеку та комунікації.
  2. Структура: план, цілі та структурований процес взаємодії ментор-менті. Неможливо просто навчати колегу усього, що знаєш, не факт, що все це знадобиться їй чи йому. Крім того, це хороший спосіб для визначення успіхів менторства та прогресу менті.
  3. Мотивація. Ментор має шукати мотивацію і прибирати чинники, які демотивують; пояснювати те, як навички кожного окремого фахівця пов’язані з цілями компанії. Важлива й мотивація самого ментора. І це не завжди гроші. У продуктовій компанії все легше, адже люди розуміють, що працюють над однією метою. В аутсорсі складніше — люди часто змінюють компанії, ментору постійно приводять нових інтернів, і він розуміє, що за рік вони підуть в іншу компанію. Тому ментори часто демотивовані. До того ж нерідко сеньйорам дають джунів для менторства, хоча вони не готові й не хочуть цим займатися.

Я досі маю потребу в менторі й вибираю їх суто за внутрішнім відчуттям. Мені важливо, щоби з людиною було комфортно, збігалися цінності та світогляд. Людині треба довіряти. Крім того, ментор має бути лідером.

Нещодавно я прочитав статтю на цю тему, і там розібрали основні компоненти довіри до лідерів:

  • стосунки — наскільки людина може їх будувати;
  • відповідність — коли ви про щось домовляєтеся, і це стається, для тебе це передбачуваний та прогнозований результат;
  • експертність і надійність.

З менторами те саме. Я маю відчувати, що можу бути чесним з ментором і не боятися розповісти про свої помилки.

Чи має ментор бути другом

Артем Биковець, CEO / Organizational & Agile Coach у Simplesense

Мені подобається думка про те, що ментор має бути другом. Однак тут варто правильно трактувати поняття «дружба». Між ментором та менті мають вибудовуватись рівноправні відносини. Втім, варто розділяти дружнє спілкування та робоче. Другу можна сказати, що ти щось не зробив через лінь чи втому, однак ментор вимагає від тебе виконання своєї частини договору.

Олекс Майстренко, радник заступника голови Київської міської державної адміністрації, колишній Head of Engineering

Я вважаю, що насамперед між ментором та менті має бути довіра. Довіра і дружба — це різні поняття. Якщо за допомогою дружби можна побудувати довіру, нехай буде так. Однак і без неї можна сформувати довіру у відносинах, тож я не вважаю, що дружба є необхідним складником успішного менторства.

Все про українське ІТ в Телеграмі — підписуйтеся на канал редакції DOU

👍ПодобаєтьсяСподобалось16
До обраногоВ обраному5
LinkedIn



Найкращі коментарі пропустити

«подивися в документації», «загугли»

На захист цього я можу сказати що існують люди, які не докладають взагалі самостійних зусиль для вирішення проблеми, а одразу біжать до неньки (як варіант — колективної неньки у вигляді якого-небудь чатику). А, між тим, вирішення проблем це один з найнеобхідніших скілів.

У таких ситуаціях завжди потрібні коментарі другої сторони (тут — менторів). Якщо людина через рік роботи на одному місці ще пов’язує власні складнощі/неуспіхи з ментором, це може сигналізувати про те, що не тільки в менторі справа.

жодного разу прямо та детально не відповів на мої запитання

Что значит «ментор детально не ответил»?
По-моему, юноша просто путает менторство и бесплатные курсы.

Я могу быть неправ конечно, но мне видится картина типа такой:
— Как сделать XXX ?
— Попробуй тут LEFT JOIN, тут RIGHT JOIN и проверь на NULL-ы
— А чем LEFT отличается от RIGHT?
— Иди погугли
...
— Мне прямо и детально не ответили!

За майже рік роботи ...
За деякий час мене скоротили

В сухом остатке, просто не асилил — год его терпели, но потом все

Прочитал истории всех троих — какие-то неревантные комментарии вообще. Первые два то ли студенты, то ли свитчеры, у которых было ожидание что «ИТ — это где нихрена не делаешь и платят в долларах». Один год не мог выучить сиквел, второго, очевидно, взяли «23-летним сеньором», но ожидания у них были, видите ли, завышенные. За курсы молчу, все и так знают их «уровень».
Короче, народ не понял, что работа в ИТ — это каждый день учиться, надеялся пропетлять. Менторы скорее всего ни при чём.

Решила насыпать историю, а то в статье какой-то детский сад)
Я когда пришла на проект, мало того, что по нему не было документации и он был построен на внутреннем фрейморвке компании, ментор мне ничего вообще не объяснял и приходилось искать ответы в коде, так ещё и оскорблял меня постоянно, при чем при директоре и коллегах, и это было для них норм. А потом я нашла серьезную уязвимость в авторизации, а он выдал это за свое достижение, получил почет и кучу бонусов.
Но это не самое веселое. В первый день работы я больше чем пол-дня не могла тупо допроситься паролей, ни у него, ни у коллег, все футболили, директор посоветовал решить проблему самостоятельно, и это далеко ещё не всё зашквары. Звучит дико, да. Но было именно так. Зато теперь меня ничем не удивишь.

82 коментарі

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Не будуть говорити про менторство на роботі, але у нас на курсах IT-Discovery викладач завжди і ментор, що полягає у трьох відповідальностях:
1) Перевірка домашніх завдань та робочих проектів з обов’язковим фідбеком по рішенню
2) Відповіді на запитання, допомога у разі помилок, проблем із проектом
3) Регулярний фідбек по кожному студенту, щоб він розумів, наскільки він ефективно навчається та виконує завдання

Шкода що кейси слабенькі. Дуже цікаві варіанти з різними поколіннями: Mentor — gen X, mentee — gen Z. Чи навпаки, що ще цікавіше. Там різні культурні моменти випливають.

Ай ем сорі, а інших «досвідчених» експертів не знайшлось? У мене досвіду як у них обох разом взятих. Якщо ж по суті, то

вирівняні очікування між ментором, менті та людиною чи організацією, яка створювала цей процес

і є резюмуючим висновком цієї статті і відповіддю на всі питання. 99% проблем виникають на невідповідності очікувань: ментора не питали, менті думав що ментор — це такий розумний lmgtfy, а організація — що все має відбуватись якось саме.

так а в чому вам не сподобалась відповідь? як би ви розібрали ці кейси, та які поради дали? цікаво почитати досвідчених колег!

Історія 1.
У всіх історіях біда у тому, що у них бракує контексту. Ми завжди чуємо чийсь один бік. Але навіть з одного боку мова завжди йде про домовленості та очікування. До чого тут «менторський саквояж» якщо банально кожна з сторін виходила з якихось очікувань, часто не прокомунікованих? Наприклад, менті думав що йому проведуть серію лекцій по SQL, тоді як компанія очікувала вже наявність певних знань, а ментор вважав що його роль зведеться до разових рев’ю. У таких ситуаціях менті вкрай часто стають у дитячу роль, складають хибне враження про себе в інших сторін, не діляться відгуками, і очікують не на менторство, а на типовий «бейбісітінг».

Порада: проговорити очікування кожного окремо, потім разом. Повторювати щомісяця для контролю.

Історія 2
Тут взагалі ультра-просто і менторство тут ні до чого. Ігнор чи перехід на особистості завжди унеможливлює будь-яку командну взаємодію. Крапка. Все решта — це вже вода та здогадки. Тому далі можу як і ви довго спекулювати чому так: така команда, культура, ментор вовк-одинак, ментор має особисті проблеми і т.д., але корисної інфи від того буде мінімально.

Побуду занудним стариганом, але в мої часи про менторство мови не йшлося, тільки сам до ранку сидиш і шукаєш рішення))

І якою є ефективність такого навчання в порівнянні з тим, коли тобі допомагає ментор?

Так, ефективність дещо меньша, але набагато краще розвивається навик самостійно вирішувати задачі, що є ключовим у подальшому розвитку.

Як зрозуміти, що ти правильно вирішив завдання, якщо ти робиш це самостійно?

У будь-якому разі на іншому кінці feedback loop хтось буде, клієнт зрештою. Без належної роботи з ментором цикл відгуку просто часто дорогий і довгий.

Якість виконання на рівні коду перевіряється під час code review, якість виконання на рівні функционалу — під час тестування завдання QA.

Я не проти менторства як такового, але, як на мене, роль ментора це:
— по-перше (і головне) загальні рекомендації, якщо менті якийсь взагалі невірний підхід використовує;
— по-друге може якісь практичні поради щодо конкретних завданнь, але тільки як напрямок вирішення проблеми, ментор не повинен вирішувати завдання за менті;

У цій гілці мова йде про самостійне навчання та його перевагу, тому тут не може бути QA або code review.

Так самостійне навчання але ж все одно ми обговорюємо працю у компанії, не як фрілансер
Тому і QA, і code review зазвичай мають місце.

Щодо «загугли»: людина може не знати, що саме гуглити,

так. тому перший гуглінг роблю я — і даю лінки — «з них можеш почати заглиблюватись у тему»

За своєї кар’єри я менторив у позаробочий час на волонтерських засадах. Тому дивно чути, що люди на громадських засадах вкладаються і намагаються зробити все як слід, а фахівці, яким платять, поводяться так, як в історії Олега.

сам волонтерив. і це — легше чим професійно. заради досвіду пробував і репетириство — це взагалі капець: «я вам плачу гроші — ви повинні зробити мені мої лабораторки! в мене скоро закінчення курсу, мені ніколи їх робити». причому це не студенти були — а слухачі вайтікурсів!

і, важче тому що:

фахівці, яким платять

як овертайм. Менторство зазвичай не прописується як основні робочи години.
Тому прикріплений ментор розглядає кожне звернення до нього як
«от йоп, сидіти над своїми тасками доведеться до дев’ятої години».

а то й до одинадцятої, якщо:

давати завдання в сендбоксі, щоби людина показала, що може зробити сама і, можливо, припустилася кількох помилок. ...
... практикувати з менті парне програмування й показати, як виконувати роботу.

на менторство — скільки давалось годин на тиждень у наведених історіях?

Ментор просто мав би виконувати свою роботу, але чомусь «косив» від неї.

його сильніше будуть бити за — незакриті таскі, аніж за незадоволення менті.
зазвичай менторство — то додаткова роль. а «своя робота» у ментора інша.

тому під таким пресиногом приорітетів ментор і «косить» від менторства. якє ще й навішують — без його згоди.

якщо пріорітети і елементи «організаційного дизайну / структури» — такі, як ви описали: «займайся цим у вільний від роботи час», хвалять/сварять тільки за «таски» і тд — то дійсно, не варто очікувати іншої динаміки в більшості випадків.

Тому я декілька разів посилався на важливість побудови процесу, та чітких домовленностей («контрактів») між УСІМА учасниками процесу (включно з представниками організації: менеджмент, ліди, HR, ...)

якщо пріорітети і елементи «організаційного дизайну / структури» — такі,

треба писати код по бестпрактікам, з тестами, документацією, оформлювати пул реквести розгорнуто, юайні з — с скріншотами, і т.д.

а на практиці як частенько (якщо не в більшості випадків)

Звісно, кожен з свого життєвого досвіду виносить своє.
Я за більш як 20 років у прогрумуванні став
скептичним емпіриком та й просто — циніком :)

тому коли я чую — «треба робити добре, а недобре — не треба робити», то жалкую що немає скролу — що проскролити цей епізод «кіна про любов»

ну або — коли в інеті, видаю занадто різкі коментарі :)

Стандартна причина конфлікту — нестача якогось ресурсу, у випадку менторства — це, як правило, час. На моїй першій роботі мені дуже допоміг мій ментор (щоправда, ніхто їх тоді так не називав) який мав на мене бюджет часу і записував його витрати в трекер. Все було рівно, спокійно. Згодом траплялись випадки, вже не в мене, коли людина має свої таски, естімейти, дедлайни, а до неї докидають ще й якогось джуна дзирчати над вухом, а над іншим стоять з класичним «ну так коли?». Та ще й джуни різні бувають, іноді вони швидко врубаються і хочеться стрибати від радості спостерігаючи за прогресом, іншим разом воно взагалі не здатне до самостійної роботи й більше жере часу ніж з нього толку, причому жере навіть тоді, коли відповідь справді на першій сторінці гугля чи в документації яку треба, треба читати.

Проблеми з комунікацією детектед.
Ментор — це не вчитель, він не має навчати менті в класичному розумінні. Він має консультувати, направляти і давати правильні завдання, може ще поділитись навчальним матеріалом. Конкретні рішення дійсно треба самому гуглити, хоча якщо з гуглом не допомогло, то треба йти до ментора.
Потрібно означити відразу межі і відповідальність кожної сторони, менті повинен знати з якими питаннями він може звертатись, а ментор повинен усвідомлювати, що це теж його робота і реджектити її не вийде.

Потрібно означити відразу межі і відповідальність кожної сторони

ось це тут ключове, гадаю.

Все залежить від відповідальності.
У принципі, ментор не повинен робити роботу за новачка.
Так, він може допомогти розібратися із проблемою, але якщо у нового співробітника постійно проблеми, які він не може вирішити самостійно навіть після порад колег — значить, він або не підходить проекту, або немає мотивації вчиться.

Решила насыпать историю, а то в статье какой-то детский сад)
Я когда пришла на проект, мало того, что по нему не было документации и он был построен на внутреннем фрейморвке компании, ментор мне ничего вообще не объяснял и приходилось искать ответы в коде, так ещё и оскорблял меня постоянно, при чем при директоре и коллегах, и это было для них норм. А потом я нашла серьезную уязвимость в авторизации, а он выдал это за свое достижение, получил почет и кучу бонусов.
Но это не самое веселое. В первый день работы я больше чем пол-дня не могла тупо допроситься паролей, ни у него, ни у коллег, все футболили, директор посоветовал решить проблему самостоятельно, и это далеко ещё не всё зашквары. Звучит дико, да. Но было именно так. Зато теперь меня ничем не удивишь.

Співчуваю 🙏🏻 карма їм все поверне і вони будуть працювати в цій компанії разом багато років🤣

Спасибо!)) Ну это ментора уволили в итоге, хотябы его кармой стукнуло)

не было документации и он был построен на внутреннем фрейморвке компании, ментор мне ничего вообще не объяснял и приходилось искать ответы в коде

це взагалі жахливий жах, ніколи такого не було і от опять...

директор посоветовал решить проблему самостоятельно

уявляю собі як директор гугла займається менеджментом паролей для новачків...

все це звичайні ситуації, особливо в аутсорсі. на поточному проекті я 2 місяці ждав поки мені дадуть доступи до ресурсів. за 2 міс я не зробив жодного комміта і отримував гарну зп

по темі у вас тільки одна фраза про образи — тільки через це не варто залишатись в такому коллективі

Директор должен был отвесить мзды тому, кто должен был дать мне пароли, да и было в конторе 20 человек. И результат он потребовал в первый день, включая те пол-дня, которые я сидела без паролей.
А требовать с меня результатов наравне с теми, кто там работает 5 лет, начали после недели работы, и директор писал мне каждые два часа с требованием подробного отчёта о моей работе, забирая тем самым мое время на выполнение задач. На это время у него было, а на то чтобы обеспечить мне условия — нет. А, и я там месяц работала бесплатно типа тестовый период. Когда я просила неделю на задачу, мне давали два часа, все время резали сроки, которые я запрашивала, приходилось работать по вечерам и выходным, чтобы догнать, без оплаты за овертаймы, потому что типа сама виновата. Продолжать?)) Тут можно целую книгу написать

назви компанії буде достатньо або відкук на доу ;)

А смысл?) Девочка пожаловалась на них клиенту что у нее нервный срыв, после чего ее на пол-города заклеймили. Не знаю, нашла ли она потом работу. У нас в мире пока что принято винить того, кто оказался слабее при определенных обстоятельствах. Я лучше просто буду использовать свой опыт экстремального программирования и решения сложных задач в работе и в жизни)

Ви з таким ентузіазмом описуєте цей неймовірний досвід, що складається враження ніби ви від такого приниження отримували неабияке задоволення.

Вы ошибаетесь здесь абсолютно во всем. Я описываю его совершенно без энтузиазма, потому что я пережила его давно и писать мне было лень, о чем уже упомянула выше. Вы воспринимаете это как унижение, а я — как опыт работы в крайне сложных условиях, в том числе психологических, и только мне известно, почему я должна была находиться в той ситуации тогда. И я ни о чем не жалею, так как в последствии он мне сильно пригодился.
По вашим комментариям создаётся впечатление, что вы от перекручивания слов других на свой лад получаете огромное удовольствие.

Чудово! Головне, що ви зробили відповідні висновки. Experience is cheap at any price. ))

Звичайно я роблю висновки) А якщо вам так кортить мене повчити, то можете поділитися своїм досвідом у програмуванні) Цього ніколи не буває забагато)

Я когда пришла на проект, мало того, что по нему не было документации и он был построен на внутреннем фрейморвке компании

это — обычное дело

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

и приходилось искать ответы в коде

отличная школа!

код — источник правды.
все остальное — подсказки.

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

«а потом я придумал, и написал мега фичу, на выходных — а заработали на ней стейкхолдеры а не я. даже за овертайм не заплатили»

так оно устроено, да. в реальном мире, а не мире розовых пони.

Зато теперь меня ничем не удивишь.

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

поэтому да, то что сейчас называют токсичностью — это вообще смешно.

У меня 13 лет опыта, я отлично знаю, что норм, а что нет. Меня не пугает искать ответы в коде, но когда код состоит из кучи несвязанных технологий, прикрученных друг к другу гвоздями, и когда от тебя через неделю требуют разбираться на уровне людей с пятилетним стажем, и при этом режут тебе сроки, которые та запрашиваешь, это НЕ нормально.
Когда тебя и коллег доводят до истощения и нервных срывов — это НЕ нормально. Люди уползали из той конторы на больничку, и если вас не впечатлила моя история, так это потому, что мне лень ее в деталях расписывать, я просто помню, что она была, и просто написала то, что всплыло. Хотя, конечно, чтобы было ясно что там происходило, нужно было приложить усилия к описанию ситуации.

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

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

И что-то мне подсказывает, что не стоит поучать старого волка, в данном случае волчицу, я через такие ситуации давно многому научилась. Большое спасибо)

И что-то мне подсказывает, что не стоит поучать старого волка

что-то мне подсказывает что странно ожидать дара телепатии от форумного участника.
как для старого волка, по крайней мере :)
меня там не было — откуда я могу знать подробности?
есть пост — типичный. на него и отвечал. а о реальной ситуации — знаете только вы. да и то, бооольшой вопрос — а все ли рассказываете о ней даже таким ответом :)

ну, может опыта еще маловато. у меня что-то там за 25 лет.

я можно сказать стояла у истоков этой отрасли в Украине с 2003,

у истоков никаких не стоял, просто программист, года с 93го.

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

код состоит из кучи несвязанных технологий, прикрученных друг к другу гвоздями

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

Когда тебя и коллег доводят до истощения и нервных срывов

так и не понял как это происходит :)
на кой черт там работать то — до такого опупения.

Я не ждала понимания, меня просто что-то дёрнуло написать, вот я это и сделала. Обычно я эту историю не рассказываю, ведь в жизни бывает всякое, а для меня это был опыт, который многому научил.

Насчёт истоков отрасли я имела ввиду именно веб.

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

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

Что у вас за стремление найти подвох в человеке и сказать ему что он сам не золото? Поверьте, в первую очередь в любой ситуации я задаю себе именно это вопрос: а где я не права? Так что слегка не по адресу)

Что у вас за стремление найти подвох в человеке и сказать ему что он сам не золото?

ну то есть вы телепат :)

Так что слегка не по адресу)

адрес — dou.ua

не знал что по этому адресу нельзя писать

у меня свои убеждения по поводу людей

у всех свои убеждения
но чаще это — стереопные заблуждения.

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

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

Не надо перекручивать мои слова, насчёт телепатии — это как раз про вас)

Самостійно знайти пароль для проекту? Ну якщо це для production системи, можливо вас брали на роль хакера

Вы не поверите, но я таки нашла))

жодного разу прямо та детально не відповів на мої запитання

Что значит «ментор детально не ответил»?
По-моему, юноша просто путает менторство и бесплатные курсы.

Я могу быть неправ конечно, но мне видится картина типа такой:
— Как сделать XXX ?
— Попробуй тут LEFT JOIN, тут RIGHT JOIN и проверь на NULL-ы
— А чем LEFT отличается от RIGHT?
— Иди погугли
...
— Мне прямо и детально не ответили!

За майже рік роботи ...
За деякий час мене скоротили

В сухом остатке, просто не асилил — год его терпели, но потом все

Прочитал истории всех троих — какие-то неревантные комментарии вообще. Первые два то ли студенты, то ли свитчеры, у которых было ожидание что «ИТ — это где нихрена не делаешь и платят в долларах». Один год не мог выучить сиквел, второго, очевидно, взяли «23-летним сеньором», но ожидания у них были, видите ли, завышенные. За курсы молчу, все и так знают их «уровень».
Короче, народ не понял, что работа в ИТ — это каждый день учиться, надеялся пропетлять. Менторы скорее всего ни при чём.

Круто оцінити всіх та обвішати ярликами не знаючи контексту 😜 може тут є домішки «власної карти світу» у коментарі?

У перший місяць проблем і питань не виникало, адже «реальних» завдань мені не давали, ... За майже рік роботи в нас не було жодної позапланової зустрічі.

Які ж тут ярлики ? Після курсів має будти базове розуміння SQL, маючи доступ до бази, можна опрацьовувати якісь кейси. Можна самому ініціювати колл раз на якийсь час, можно в лоб задати питання — що за відношення, так таке інше. Як інформацію подали — такий контекст і отримали.

про бути більш сміливим і проактивним: давати фідбек в лоб і задавати питання — це +1оо5оо!

Натомість я отримував типові «та це ж елементарно», «подивися в документації», «загугли». Я почав гуглити та розбиратися, шукати самостійно, хоча не мав жодної структури пошуку. Жодної підтримки не було.

как то так когда то я попал на супер-ментора в сциклуме :)))
обещал научить гуглить за вискарь :)))

Люто плюсую до того що менторити якісно ще треба навчитися. Я нікого не менторю, але часом приходять джуни з проханням допомогти. Залізти разом поколупатись в коді щоб знайти косяк — ок, а от як просто спрямувати людину так щоб вона сама знайшла рішення — переважно без поняття)) а от саме друге і цінне в менторах)

От то «друге», то якраз навички коучінгу, які дійсно дуже допомагають в процесі менторінгу, щоб не забути всю відповідальність на себе і не стати «вічною нянькою»

Я тільки перейшов на новий проєкт, і мої очікування щодо його складності були дещо занижені. Тому ментор вимагав від мене більше, ніж я міг дати. Через це часто виникали конфлікти. Траплялося, що він переходив на особисті: «Ти ідіот, навіщо ти це зробив?!» тощо. Такого тиску ставало дедалі більше. Все дійшло до того, що він сказав «гугли самостійно», попри те, що деяку інформацію знайти в мережі неможливо.

Є ще книжка на схожу тему «В оточенні ідіотів, або Як зрозуміти тих, кого неможливо зрозуміти»
nashformat.ua/...​mozhlyvo-zrozumity-622515
www.yakaboo.ua/...​vo-zrozumiti-2204038.html

Натомість я отримував типові «та це ж елементарно», «подивися в документації», «загугли»

Послушать бы вопросы. Возможно автор задавал настолько бестолковые вопросы, что других ответов на них не было. Мне кажется ещё, что многие почему-то путают менторство с курсами.

бачу ви з таких менторів ;) відповів нижче що задача ментора(інженера) вирішувати проблеми а не створювати нові такими відповідями

не всі проблеми є проблемами ментора

Вирішувати проблеми компанії/бізнесу/продукту/проекту/команди😜

Вирішувати проблеми компанії/бізнесу/продукту/проекту/команди

Мы же семья ©, teamwork ©, надо больше вовлеченности ©, деньги-не-главное © ?

Пока у меня нет доли в компании, % от прибыли:, или отдельной оплаты за:

  • Проблемы компании !== мои проблемы
  • Проблемы бизнеса !== мои проблемы
  • Проблемы продукта != мои проблемы
  • Проблемы проекта != мои проблемы
      Из всего списка, только проблемы команды некоторым боком относятся к.

сорі, а ви точно Scrum Master? :)))

бачу ви з таких менторів

Вполне может быть. У меня обостряется аллергия на тупые вопросы, когда человек на важных щах перед всеми рассказывает, как он оптимизировал работу БД где-то, но в то же время вместо JOIN-а в запросе к БД делает 2 отдельных запроса и потом в коде:
foreach(...) foreach(...)

А когда ты спрашивашь: «Почему ты так сделал?», — ответ в 90% случаев звучит: «В смысле?».

Я в IT ~15 лет. Я не помню, чтобы за это время я встречал такое понятие, как «ментор».
«У вас будет ментор, который всему научит», — *смайлик с покерфейсом*. Этот миф, мне кажется, придумали создатели курсов, чтобы завлечь себе больше клиентов, мол, сейчас пройдете курсы, теорию будете знать, а там на месте ментор всему научит. Да, да, да. Я не помню, чтобы за все время у меня когда-то был «ментор», который бы меня «вёл», при том, что я сменил 2 стека (не с JAVA на C#) и 2 раза начинал с низов. Где-то были «старшие» и более умные товарищи, которые действительно где-то могли подсказать и помочь. Где-то были «старшие» и более умные товарищи, которые мало чем помогали. Но никогда не было такого, что «Знакомьтесь, это Василий, он тебя всему обучит». Всегда было так, что не «Василий» тебе должен, а ты должен «Василию», чтобы он тебе помог. Под «должен» я имею ввиду, что ты должен иметь какую-то базу по вопросу, ты должен сформулировать нормально вопрос, ты должен предварительно попробовать найти решение самостоятельно и только после этого можно пойти к «Василию» с просьбой тебе помочь. «Просьба» не подразумевает, что он тебе поможет прямо сейчас или вообще поможет. Хз конечно, может сегодня это все уже по другому работает.

«Почему ты так сделал?», — ответ в 90% случаев звучит: «В смысле?».

токсичний діалог який тільки погіршує ситуацію... людина не знає бази — з цього починати треба розмову.
наприклад дати інфу по основам, потім вже по складним запросам, і потім по оптимізаціям.
про «важні щі» можливо треба поговорита на 1-1 або з менеджером

токсичний діалог

А как этот диалог должен выглядеть? Ух ты мой хороший, форич форич сделал, мой маленький, фу-фу-фу так делать, так делать плохо, нельзя так делать, мой золотой. На тебе LEFT JOIN, пиши вот тут, нет нет, не тут, а тут, нет, левее, еще левее, стоп, правее, ага, тут. L, E, нет-нет «и» в смысле «е», ага, да-да, дальше F, T, пробел, J, O, I, N. Умница моя!!! Ты лучший в мире айтишник! Получишь премию в конце месяца, через месяца два дадим тебе синьера.

Возможно, сейчас это называется «токсичность». Мне кажется, что это (дебильное, как по мне) слово «токсичность» ввели в индустрию люди, которые продают курсы или свои услуги по трудоустройству. Я помню, как в старые добрые времена, можно было без задней мысли коллегу на xyz послать (причем этот посланный коллега — это мог быть ты) и атмосфера в коллективе была здравее, чем сейчас, где «у нас нету токсичности в коллективе, все ребята помогают друг другу, по любым вопросам обращайся к кому угодно, все бросят свои дела и займутся своими, главное, чтобы тебе все нравилось».

який тільки погіршує ситуацію...

Смотря для кого.

про «важні щі» можливо треба поговорита на 1-1 або з менеджером

Ну да, какая же тут «токсичность», когда ты объясняешь человеку, чтобы вел себя скромнее, либо жалуешься в тихую менеджеру.

А как этот диалог должен выглядеть?

так — реджектнутий мерж реквест з комментом поясненням що це не оптимальний запрос.

я теж пам’ятаю такі компанії, але ми трохи не про це.
новачка не варто посилати на хер.. а то раптом цим новачком буже Кожаев і погано буде для вас))

"у нас нету токсичности в коллективе, все ребята помогают друг другу, по любым вопросам обращайся к кому угодно

саме так і є в більшості коллективів де я працював і зараз так, і % душних людей завжди присутній але це виняток а не правило і не основний костяк коллективу

Я так понял, что вы скорее теоретик, чем практик.

а то раптом цим новачком буже Кожаев і погано буде для вас))

Кто такой Кожаэв и почему мне будет плохо?

Кто такой Кожаэв и почему мне будет плохо?

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

У роботі завжди будуть такі речі, які цінуються, а також такі, про які ніхто не згадає. Менторство це як раз таке, «ні про що». Виміряти час неможливо, тобі доведеться думати за свої задачі та «за того парня». Так що .. менторство це не вигідно для ментора. Яка мотивація ? Приємно передати трошки своїх знань, без проблем, але якщо в тебе самого є час. Буває проблема мізерна, якщо «знаєш як». Ось тут легка підказка допомагає — типу «О, я бачу ти завис над оцим, а можна зробити ось так...». Але більшість роботи твій «новачок-колега» повинен зробити сам. Інакше виросте у вас такий товарищ, що так і буде сам не думати а до ментора бігати. І думає собі «Боже, userName, а ти пробував може подумати годину-три ? Ти одразу через 15 хвилин до ментора (ліда) ?»

«подивися в документації», «загугли»

На захист цього я можу сказати що існують люди, які не докладають взагалі самостійних зусиль для вирішення проблеми, а одразу біжать до неньки (як варіант — колективної неньки у вигляді якого-небудь чатику). А, між тим, вирішення проблем це один з найнеобхідніших скілів.

Хотелось бы узнать, там было «загугли» или все-таки (пример) «загугли как собрать статистику по индексам и проанализировать план запроса»? Некоторые вещи просто не имеет смысла рассказывать если у подопечного вообще нет понимания базовых вещей что тут происходит.

навіть якщо у менті немає базових знать в питанні(це нормально для новачків), «загугли» це не відповідь. задача ментора допомагати рішати проблеми імхо
наприклад менті джавіст може не знати noslq або якісь тонкощі git-a або поточної ci/cd системи...

наприклад менті джавіст може не знати noslq або якісь тонкощі git-a або поточної ci/cd системи...

2 з 3-х пунктів гугляться.

І тому не варто допомогти людині без досвіду, якщо серед твоїх обов’язків додалося (за грейдом=досвідом+платнею?) менторити новачків?😜

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

У меня не стартует с ошибкой X, я проверил Y,Z которым могут причинять зло — вроде Ок, need help — stuck here

Такой подход абсолютно валидный и только приветствуется — везде могут быть неочевидные вещи.

У меня почему-то не стартует, need help

За такой подход — безжалостно бить — так как даже минимальной попытки разобраться не видно

Это совершенно НЕнормально когда

у менті немає базових знать в питанн

В следующем примере, слово

тонкощі.

— как бы уже толсто намекает на специализированные знания, никак не базовые.

git-a або поточної ci/cd системи...

И такие вопросы — да, абсолютно валидны.

С другой стороны — проведи мысленный эксперимент. К тебе приходитм менти который

може не знати noslq

, да еще и требует прямо и детально ответить. Тогда ты, как добрый человек, отложишь все дела, и начнешь читать 4х-часовую лекцию, начиная с CAP-теоремы и далее, так ведь? Или все-таки посоветуешь хотя бы сделать минимальный homework вначале?

Или все-таки посоветуешь хотя бы сделать минимальный homework вначале?

і це норм відповідь, обоє зрозуміли в чому проблема і з чого почати.

Не потрібно починати з теореми. Мені подобається Android basics курс від Google. Там дається — при першому ознацомленні — визнвчення нового поняття буквально одним реченням. Можливо, порівняння з предметом у реальному світі. Є така штука. Потрібна для цього. Використовувати так. Зроби це: практика на використання. Наголос на тому, як виконати практичне завдання. А нові елементи мови програмування, середовища розробки, тестування та налагодження даються в цьому контексті з прикладами.

У таких ситуаціях завжди потрібні коментарі другої сторони (тут — менторів). Якщо людина через рік роботи на одному місці ще пов’язує власні складнощі/неуспіхи з ментором, це може сигналізувати про те, що не тільки в менторі справа.

Натомість я отримував типові «та це ж елементарно», «подивися в документації», «загугли». Я почав гуглити та розбиратися, шукати самостійно, хоча не мав жодної структури пошуку. Жодної підтримки не було.

А ведь когда-то не так уж и давно — никакого гугла не было. И приходилось искать литературу по библиотекам, выписывая важные вещи в тетрадь. Ну а структуру поиска проходят в любом ВУЗе.

Менторити треба так, шоб в учня через кілька років була власна ITкомпанія!

И потом он бы мог тебя нанять на более высокую ЗП :)

Но только после выполнения тестового задания на 4 часа

Которое ты сам когда-то давал ему, по этому выполняешь за 15 минут :)

Но они принимают решенное задание и больше их HR тебе не отвечает.

І каже: піди загугли 🤣

И круг замкнулся. Колесо Сансары сделало еще один оборот.

Підписатись на коментарі