[Управление разработкой, Управление персоналом] Переоценка кадров или как сеньоры становятся мидлами, а мидлы джунами
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
В процессе работы над проектами в качестве тимлида я столкнулся с одним процессом, который неизбежно возникает практически в любой команде — переоценка сотрудника в ходе его работы. Далее по тексту сугубо личное мнение.
Опишу на примере абстрактного разработчика Тома. Том устроился на работу в компанию «Ынтернетмагазинзадень» в качестве мидл разработчика php. Компания делает интернет-магазины от шаблонных до сложных с кучей интеграций. В компании всё самое лучшее Agile, SCRUM, стендапы и ретро. Том отработал уже 3 месяца и всё у него идёт хорошо, запустил парочку ИМ, они даже работают и клиенты довольны.
Тут приходит новая задача на разработку ИМ, но уже с интеграцией с CRM. Том начинает с задачей интеграции и в какой-то момент у него не получается и срок растягивается на неделю. При этом на общих митинга Том говорит, что «разбирается с задачей», надеясь на то, что уже близок к решению. Том обращается к сеньор разработчику Майку (который не является его ментором и просто сидит недалеко от Тома), тот направляет его на мануалы и кратко объясняет что нужно сделать.
Том уходит читать туториалы и разбираться с задачей. Через ещё пару дней он возвращается к Майку с вопросами по интеграции и они вместе разбирают их.
Том уходит разбираться ещё на пару дней, после этого он возвращается снова к Майку и даёт ему конечное решение. Майк проверяет задание и указывает на несколько незначительных ошибок, которые Том вскоре поправит.
Вроде вполне себе рабочая картинка, но есть несколько моментов, которые показывают нам, что Том уже не мидл разработчик как мы считали раньше, а джун.
1. Том очень долго (в данном случае неделю) разбирался с задачей и не просигнализировал о проблеме вовремя.
2. Не смог разобраться с туториалом сам и вместо того, чтобы прогуглить какие-то непонятные моменты отправился к Майку.
3. Том потратил время другого разработчика вместо того, чтобы использовать стендапы и обсудить свои проблемы там.
Иногда на собеседованиях на должность тимлида задают вопрос «Как вы разделяете разработчиков на джун, мидл, сеньор?». И я отвечаю примерно так:
— джун знает технологии, но не всегда знает где и как их применить;
— мидл знает технологии, умеет их применять и может по описанию реализации или туториалу выполнить задачу;
— сеньор способен по бизнес-постановке задачи придумать оптимальное решение и реализовать его.
В случае Тома он как раз получил туториал и описание реализации от Майка, но не смог разобраться с ним и вернулся к Майку. Это для меня послужило первым важным «звоночком», что перед нами не мидл. Вторым важным звоночком стало то, что для мидла очень важен навык «сигнализировать о проблеме», и если он им не обладает, то по софт скиллам это возвращает его к джунам. Третий «звоночек» — это небрежное отношение к времени другого разработчика присущее джунам, которые иногда не понимают важности следовать по процессу и обращаются к самому «доброму» разработчику вместо того, чтобы пойти к лиду и получить наставника через него. Это важно, так как возможно разработчик Майк занят на супер ответственном проекте или его задача требует высокой концентрации, а вот буквально за соседним столом сидит программист Джон, который только что закончил проект и ещё не успел начать погружаться в новый.
Рассмотрим другой кейс. Старший разработчик Вася уже долго работает в компании. У Васи есть тимлид Петя. И так уж случилось, что Петя очень вдумчивый руководитель и он не просто ставит задачу, а прорабатывает вместе с системным аналитиком каждый её аспект и только потом отдаёт в работу. Вася и Петя работают в компании уже 4 года и данная схема уже в порядке вещей. При этом Вася прекрасно реализует задачи по написанной технической спецификации, документирует код и доволен тем, что у него всё так «красиво и ладно».
Но вот незадача, через какое-то время компания закрывается и Васе приходится искать работу и на собеседованиях Васю почему-то начинают квалифицировать не как сеньора, а как мидла. «Как же такое получилось? Где я завалился?» — задаёт он себе вопрос.
Всё опять же просто, Вася потерял навык поиска оптимального решения задачи, за 4 года системный аналитик и заботливый тимлид расслабили Василия настолько, что данный скилл отпал за ненадобностью.
Что делать в таком случае? Чаще всего, обнаружив такое в компании, стоит не отбирать рубли у разрабов и понижать их зарплаты (пусть даже косвенно), а озадачится вопросом «а можно ли это исправить?». И если ответ «нет», то лучше распрощаться с работником «по-доброму», ведь в какой-то момент времени он будет недоволен тем, что его заработная плата не растёт, да и остальной команды могут быть с этим проблемы. Если же ответ «да», то нужна будет очень продуманная работа как отдела по обучению персонала, так и тимлида. Ведь в данном случае придётся накачивать скилл работника и делать это максимально мягко, чтобы не задеть его самолюбие и дать ему мотивацию развиваться.
===========
Источник:
habr.com
===========
Похожие новости:
- [MySQL, SQL, Администрирование баз данных, Управление разработкой] Серия мастер-классов по MySQL 15—17 декабря
- [Программирование, Управление разработкой, Управление персоналом, Карьера в IT-индустрии] О плюсах парного программирования
- [Анализ и проектирование систем, Управление разработкой, Управление проектами, Микросервисы] Скрытые расходы при переходе на микросервисы
- [Управление персоналом, Карьера в IT-индустрии, Удалённая работа] Убрать ковер и еду. Чек-лист перед онлайн-собеседованием
- [Open source, Управление проектами, Развитие стартапа, Управление продуктом, Управление персоналом] Мы всё переписали на $HOTLANG, но стартап всё равно провалился (перевод)
- [Управление разработкой, Разработка под Windows, Софт] Microsoft представила новую систему доставки функций Windows 10 отдельно от глобальных патчей
- [Информационная безопасность, Управление персоналом, Удалённая работа] Microsoft пообещала поменять систему слежки за сотрудниками Productivity Score после волны критики от экспертов
- [Управление персоналом, Автомобильные гаджеты, Транспорт, IT-компании, Удалённая работа] «Удаленка» навсегда? Опыт команд Firmware, PD, Project Management Office и Technical Support в Bright Box
- [Управление персоналом, Читальный зал] Помогите стахановцу — увольте его сразу
- [Программирование, Управление разработкой, Управление проектами, Управление продуктом] Оценка трудозатрат в разработке ПО для начинающих (перевод)
Теги для поиска: #_upravlenie_razrabotkoj (Управление разработкой), #_upravlenie_personalom (Управление персоналом), #_upravlenie_ljudmi_i_proektami (управление людьми и проектами), #_upravlenie_razrabotkoj (
Управление разработкой
), #_upravlenie_personalom (
Управление персоналом
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 19:49
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
В процессе работы над проектами в качестве тимлида я столкнулся с одним процессом, который неизбежно возникает практически в любой команде — переоценка сотрудника в ходе его работы. Далее по тексту сугубо личное мнение. Опишу на примере абстрактного разработчика Тома. Том устроился на работу в компанию «Ынтернетмагазинзадень» в качестве мидл разработчика php. Компания делает интернет-магазины от шаблонных до сложных с кучей интеграций. В компании всё самое лучшее Agile, SCRUM, стендапы и ретро. Том отработал уже 3 месяца и всё у него идёт хорошо, запустил парочку ИМ, они даже работают и клиенты довольны. Тут приходит новая задача на разработку ИМ, но уже с интеграцией с CRM. Том начинает с задачей интеграции и в какой-то момент у него не получается и срок растягивается на неделю. При этом на общих митинга Том говорит, что «разбирается с задачей», надеясь на то, что уже близок к решению. Том обращается к сеньор разработчику Майку (который не является его ментором и просто сидит недалеко от Тома), тот направляет его на мануалы и кратко объясняет что нужно сделать. Том уходит читать туториалы и разбираться с задачей. Через ещё пару дней он возвращается к Майку с вопросами по интеграции и они вместе разбирают их. Том уходит разбираться ещё на пару дней, после этого он возвращается снова к Майку и даёт ему конечное решение. Майк проверяет задание и указывает на несколько незначительных ошибок, которые Том вскоре поправит. Вроде вполне себе рабочая картинка, но есть несколько моментов, которые показывают нам, что Том уже не мидл разработчик как мы считали раньше, а джун. 1. Том очень долго (в данном случае неделю) разбирался с задачей и не просигнализировал о проблеме вовремя. 2. Не смог разобраться с туториалом сам и вместо того, чтобы прогуглить какие-то непонятные моменты отправился к Майку. 3. Том потратил время другого разработчика вместо того, чтобы использовать стендапы и обсудить свои проблемы там. Иногда на собеседованиях на должность тимлида задают вопрос «Как вы разделяете разработчиков на джун, мидл, сеньор?». И я отвечаю примерно так: — джун знает технологии, но не всегда знает где и как их применить; — мидл знает технологии, умеет их применять и может по описанию реализации или туториалу выполнить задачу; — сеньор способен по бизнес-постановке задачи придумать оптимальное решение и реализовать его. В случае Тома он как раз получил туториал и описание реализации от Майка, но не смог разобраться с ним и вернулся к Майку. Это для меня послужило первым важным «звоночком», что перед нами не мидл. Вторым важным звоночком стало то, что для мидла очень важен навык «сигнализировать о проблеме», и если он им не обладает, то по софт скиллам это возвращает его к джунам. Третий «звоночек» — это небрежное отношение к времени другого разработчика присущее джунам, которые иногда не понимают важности следовать по процессу и обращаются к самому «доброму» разработчику вместо того, чтобы пойти к лиду и получить наставника через него. Это важно, так как возможно разработчик Майк занят на супер ответственном проекте или его задача требует высокой концентрации, а вот буквально за соседним столом сидит программист Джон, который только что закончил проект и ещё не успел начать погружаться в новый. Рассмотрим другой кейс. Старший разработчик Вася уже долго работает в компании. У Васи есть тимлид Петя. И так уж случилось, что Петя очень вдумчивый руководитель и он не просто ставит задачу, а прорабатывает вместе с системным аналитиком каждый её аспект и только потом отдаёт в работу. Вася и Петя работают в компании уже 4 года и данная схема уже в порядке вещей. При этом Вася прекрасно реализует задачи по написанной технической спецификации, документирует код и доволен тем, что у него всё так «красиво и ладно». Но вот незадача, через какое-то время компания закрывается и Васе приходится искать работу и на собеседованиях Васю почему-то начинают квалифицировать не как сеньора, а как мидла. «Как же такое получилось? Где я завалился?» — задаёт он себе вопрос. Всё опять же просто, Вася потерял навык поиска оптимального решения задачи, за 4 года системный аналитик и заботливый тимлид расслабили Василия настолько, что данный скилл отпал за ненадобностью. Что делать в таком случае? Чаще всего, обнаружив такое в компании, стоит не отбирать рубли у разрабов и понижать их зарплаты (пусть даже косвенно), а озадачится вопросом «а можно ли это исправить?». И если ответ «нет», то лучше распрощаться с работником «по-доброму», ведь в какой-то момент времени он будет недоволен тем, что его заработная плата не растёт, да и остальной команды могут быть с этим проблемы. Если же ответ «да», то нужна будет очень продуманная работа как отдела по обучению персонала, так и тимлида. Ведь в данном случае придётся накачивать скилл работника и делать это максимально мягко, чтобы не задеть его самолюбие и дать ему мотивацию развиваться. =========== Источник: habr.com =========== Похожие новости:
Управление разработкой ), #_upravlenie_personalom ( Управление персоналом ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 19:49
Часовой пояс: UTC + 5