Комментарии 8
Из статьи следует, что наставник существует, чтобы вовремя сказать "подыми свою задницу и иди меняй работу". Ну что... и то хлеб
Ищите того, кто будет учить вас думать.
Это тоже ошибочный путь, так как, кроме вас самих, никто вас не научит
Нужно выделять бюджет времени на условно свободную разработку. Один балбес предлагает, бывалый с той же ролью до начала работ обсуждает предложенное, после окончания критикует, балбес вносит правки. После это уходит остальным ролям в том же формате. Второй балбес берет задачу по реализации предложения, объясняет уже своему бывалому, как будет делать. По окончанию работ критика (у разработчиков в рамках ревью, например).
Компании могли бы выстроить процесс иначе.
Это проблема шире и касается не менторства, а вообще построение процессов в компании.
Проблемы начинаются в 2х случаях (на примере ITIL)
1) инициатива спускается сверху, исполнителю берут под козырек, генерятся инструкции и регламенты , в итоге все как работали так и работают. Руководство уверено - у нас все по ITIL наша компания вышла на новый уровень зрелости. Отдельные сомневающиеся - как вопли одинокого путника в пустыне. Остальным глубоко все равно, лишь бы ничего не менялось.
2)Инициатива идет сверху, но начальству это не нужно - и так все работает , к чему эти лишняя возня - "Твой ITIL нам не нужен и так все работает"
C менторством - тоже самое. Если спустить инициативу сверху народ быстро приспособится и подберет хитрый болт на гайку с левой резьбой.
Что делать ? Я не знаю , я не манагер.
За 30 лет в IT у меня никогда не было ментора и я сам никогда не менторил.
Запрос на ментора должен созреть изнутри.
Да именно так !

Боль и провокация: почему 90% наставничества в IT бесполезно