В процессе работы над проектами в качестве тимлида я столкнулся с одним процессом, который неизбежно возникает практически в любой команде — переоценка сотрудника в ходе его работы. Далее по тексту сугубо личное мнение.
Опишу на примере абстрактного разработчика Тома. Том устроился на работу в компанию «Ынтернетмагазинзадень» в качестве мидл разработчика php. Компания делает интернет-магазины от шаблонных до сложных с кучей интеграций. В компании всё самое лучшее Agile, SCRUM, стендапы и ретро. Том отработал уже 3 месяца и всё у него идёт хорошо, запустил парочку ИМ, они даже работают и клиенты довольны.
Тут приходит новая задача на разработку ИМ, но уже с интеграцией с CRM. Том начинает с задачей интеграции и в какой-то момент у него не получается и срок растягивается на неделю. При этом на общих митинга Том говорит, что «разбирается с задачей», надеясь на то, что уже близок к решению. Том обращается к сеньор разработчику Майку (который не является его ментором и просто сидит недалеко от Тома), тот направляет его на мануалы и кратко объясняет что нужно сделать.
Том уходит читать туториалы и разбираться с задачей. Через ещё пару дней он возвращается к Майку с вопросами по интеграции и они вместе разбирают их.
Том уходит разбираться ещё на пару дней, после этого он возвращается снова к Майку и даёт ему конечное решение. Майк проверяет задание и указывает на несколько незначительных ошибок, которые Том вскоре поправит.
Вроде вполне себе рабочая картинка, но есть несколько моментов, которые показывают нам, что Том уже не мидл разработчик как мы считали раньше, а джун.
Иногда на собеседованиях на должность тимлида задают вопрос «Как вы разделяете разработчиков на джун, мидл, сеньор?». И я отвечаю примерно так:
В случае Тома он как раз получил туториал и описание реализации от Майка, но не смог разобраться с ним и вернулся к Майку. Это для меня послужило первым важным «звоночком», что перед нами не мидл. Вторым важным звоночком стало то, что для мидла очень важен навык «сигнализировать о проблеме», и если он им не обладает, то по софт скиллам это возвращает его к джунам. Третий «звоночек» — это небрежное отношение к времени другого разработчика присущее джунам, которые иногда не понимают важности следовать по процессу и обращаются к самому «доброму» разработчику вместо того, чтобы пойти к лиду и получить наставника через него. Это важно, так как возможно разработчик Майк занят на супер ответственном проекте или его задача требует высокой концентрации, а вот буквально за соседним столом сидит программист Джон, который только что закончил проект и ещё не успел начать погружаться в новый.
Рассмотрим другой кейс. Старший разработчик Вася уже долго работает в компании. У Васи есть тимлид Петя. И так уж случилось, что Петя очень вдумчивый руководитель и он не просто ставит задачу, а прорабатывает вместе с системным аналитиком каждый её аспект и только потом отдаёт в работу. Вася и Петя работают в компании уже 4 года и данная схема уже в порядке вещей. При этом Вася прекрасно реализует задачи по написанной технической спецификации, документирует код и доволен тем, что у него всё так «красиво и ладно».
Но вот незадача, через какое-то время компания закрывается и Васе приходится искать работу и на собеседованиях Васю почему-то начинают квалифицировать не как сеньора, а как мидла. «Как же такое получилось? Где я завалился?» — задаёт он себе вопрос.
Всё опять же просто, Вася потерял навык поиска оптимального решения задачи, за 4 года системный аналитик и заботливый тимлид расслабили Василия настолько, что данный скилл отпал за ненадобностью.
Что делать в таком случае? Чаще всего, обнаружив такое в компании, стоит не отбирать рубли у разрабов и понижать их зарплаты (пусть даже косвенно), а озадачится вопросом «а можно ли это исправить?». И если ответ «нет», то лучше распрощаться с работником «по-доброму», ведь в какой-то момент времени он будет недоволен тем, что его заработная плата не растёт, да и остальной команды могут быть с этим проблемы. Если же ответ «да», то нужна будет очень продуманная работа как отдела по обучению персонала, так и тимлида. Ведь в данном случае придётся накачивать скилл работника и делать это максимально мягко, чтобы не задеть его самолюбие и дать ему мотивацию развиваться.
Опишу на примере абстрактного разработчика Тома. Том устроился на работу в компанию «Ынтернетмагазинзадень» в качестве мидл разработчика php. Компания делает интернет-магазины от шаблонных до сложных с кучей интеграций. В компании всё самое лучшее Agile, SCRUM, стендапы и ретро. Том отработал уже 3 месяца и всё у него идёт хорошо, запустил парочку ИМ, они даже работают и клиенты довольны.
Тут приходит новая задача на разработку ИМ, но уже с интеграцией с CRM. Том начинает с задачей интеграции и в какой-то момент у него не получается и срок растягивается на неделю. При этом на общих митинга Том говорит, что «разбирается с задачей», надеясь на то, что уже близок к решению. Том обращается к сеньор разработчику Майку (который не является его ментором и просто сидит недалеко от Тома), тот направляет его на мануалы и кратко объясняет что нужно сделать.
Том уходит читать туториалы и разбираться с задачей. Через ещё пару дней он возвращается к Майку с вопросами по интеграции и они вместе разбирают их.
Том уходит разбираться ещё на пару дней, после этого он возвращается снова к Майку и даёт ему конечное решение. Майк проверяет задание и указывает на несколько незначительных ошибок, которые Том вскоре поправит.
Вроде вполне себе рабочая картинка, но есть несколько моментов, которые показывают нам, что Том уже не мидл разработчик как мы считали раньше, а джун.
- Том очень долго (в данном случае неделю) разбирался с задачей и не просигнализировал о проблеме вовремя.
- Не смог разобраться с туториалом сам и вместо того, чтобы прогуглить какие-то непонятные моменты отправился к Майку.
- Том потратил время другого разработчика вместо того, чтобы использовать стендапы и обсудить свои проблемы там.
Иногда на собеседованиях на должность тимлида задают вопрос «Как вы разделяете разработчиков на джун, мидл, сеньор?». И я отвечаю примерно так:
- джун знает технологии, но не всегда знает где и как их применить;
- мидл знает технологии, умеет их применять и может по описанию реализации или туториалу выполнить задачу;
- сеньор способен по бизнес-постановке задачи придумать оптимальное решение и реализовать его.
В случае Тома он как раз получил туториал и описание реализации от Майка, но не смог разобраться с ним и вернулся к Майку. Это для меня послужило первым важным «звоночком», что перед нами не мидл. Вторым важным звоночком стало то, что для мидла очень важен навык «сигнализировать о проблеме», и если он им не обладает, то по софт скиллам это возвращает его к джунам. Третий «звоночек» — это небрежное отношение к времени другого разработчика присущее джунам, которые иногда не понимают важности следовать по процессу и обращаются к самому «доброму» разработчику вместо того, чтобы пойти к лиду и получить наставника через него. Это важно, так как возможно разработчик Майк занят на супер ответственном проекте или его задача требует высокой концентрации, а вот буквально за соседним столом сидит программист Джон, который только что закончил проект и ещё не успел начать погружаться в новый.
Рассмотрим другой кейс. Старший разработчик Вася уже долго работает в компании. У Васи есть тимлид Петя. И так уж случилось, что Петя очень вдумчивый руководитель и он не просто ставит задачу, а прорабатывает вместе с системным аналитиком каждый её аспект и только потом отдаёт в работу. Вася и Петя работают в компании уже 4 года и данная схема уже в порядке вещей. При этом Вася прекрасно реализует задачи по написанной технической спецификации, документирует код и доволен тем, что у него всё так «красиво и ладно».
Но вот незадача, через какое-то время компания закрывается и Васе приходится искать работу и на собеседованиях Васю почему-то начинают квалифицировать не как сеньора, а как мидла. «Как же такое получилось? Где я завалился?» — задаёт он себе вопрос.
Всё опять же просто, Вася потерял навык поиска оптимального решения задачи, за 4 года системный аналитик и заботливый тимлид расслабили Василия настолько, что данный скилл отпал за ненадобностью.
Что делать в таком случае? Чаще всего, обнаружив такое в компании, стоит не отбирать рубли у разрабов и понижать их зарплаты (пусть даже косвенно), а озадачится вопросом «а можно ли это исправить?». И если ответ «нет», то лучше распрощаться с работником «по-доброму», ведь в какой-то момент времени он будет недоволен тем, что его заработная плата не растёт, да и остальной команды могут быть с этим проблемы. Если же ответ «да», то нужна будет очень продуманная работа как отдела по обучению персонала, так и тимлида. Ведь в данном случае придётся накачивать скилл работника и делать это максимально мягко, чтобы не задеть его самолюбие и дать ему мотивацию развиваться.
