Андрей Урядов - руководитель отдела разработки в RentaTeam.
Особенность управления персоналом в IT заключается в том, что менеджерами становятся технари и в силу этой специфики иногда управляют людьми (как бы грубо это ни звучало), как компьютерами. Часто и я замечаю за собой формат «я сказал, они должны сделать». У нас нет проблем с техническими задачами, но для управления командой важна и психология, и общение, и soft-skills. В этом и заключается типичная сложность работы лида. Так как в IT я прошел все этапы роста в компании, то был на обоих берегах отношений, и понимаю и менеджеров, и рядовых разработчиков.
С кем мы работаем?
В нашей команде разные специалисты и разная мотивация: кому-то интересно прокачивать знания, для кого-то важна значимость его мнения и его труда, для кого-то – выполнить задачу без ошибок, для другого – поработать с технологиями, кто-то любит делать новые задачи «с нуля», а кому-то нужны рамки и «рельсы». Все определяется в процессе, и работать с командой нужно под правильным углом. И самое главное, ценности компании и сотрудника должны совпадать.
Принципы работы с командой
Сдерживать обещания
Если что-то пообещал сотруднику, надо сделать. Пообещать, забыть, не сделать – недопустимо. Доверие сотрудника к руководителю крайне важно, потому что если нет доверия, то слова могут восприниматься не всерьез даже в критической ситуации, где только руководство может знать, что и как нужно делать.Давать фидбэк
Фидбэк очень важен: как положительный, так и отрицательный. Положительный фидбэк работает лучше отрицательного, при этом отрицательный, как правило, работодатели не забывают давать, а положительный – ну как получится. Чем менее опытен разработчик, тем важнее для него фидбэк и тем меньше вероятности, что он его попросит.Предоставлять возможности развиваться и обучаться
Насильно сотрудника обучить невозможно. Если желание развиваться было и почему-то пропало, то для нас это сигнал к тому, что дальнейшее обучение надо прекращать и думать над тем, что можно сделать дальше. Мы ищем либо новую мотивацию с ним вместе, либо прекращаем обучение. По опыту скажу, что бывают моменты, которые «убивают» мотивацию, но обсуждение помогает решить проблему.Понимать мотивацию разработчика
Человека нельзя заставить что-то сделать. Можно запихнуть его в архитектуру, во временные рамки задачи, продавить свое мнение, и разработчики это выполнят. На это «продавливание» уходят время и силы, и самое неприятное, что разработчик может выгореть, потому что не может предложить что-то свое. Для нас важно, чтобы разработчику было интересно именно самому выполнять задачи.Слышать сотрудника и реагировать на его фидбэк
Дело даже не в том, чтобы просто дать возможность высказаться, а в том, чтобы сотрудника услышали. Мы стараемся, чтобы наш сотрудник видел, что его действия и мнение учитываются. В противном случае разработчик перестает что-то предпринимать и предлагать.Делегировать
Нужно уметь отдавать задачу и понимать, что ее, возможно, сделают хуже, чем можешь сделать сам. И это нормально. Для нас важно научить разработчика исправлять ошибки самому. В противном случае, сотрудник так и будет делать эту ошибку, а лид будет продолжать исправлять ее. Понятно, что легче всего закрыть задачи самому, но это путь в никуда, руководителя с ростом компании просто не хватит на все.Менторить
«Схантить» опытного специалиста в команду довольно сложно, поэтому мы растим сильных разработчиков сами. За полгода эффективного управления и менторства мы получаем из джуниора уверенного мидла. Компания прикрепляет к новому сотруднику ментора, который «натаскивает» его по теории и практике разработки. Эффект от менторства проявляется только тогда, когда делаешь это постоянно и вовремя.Отношение к стандартам
“Растить” стандартных программистов удобно, и можно это поставить на поток, но изменять разработчика без учета его сильных сторон в конечном счете обходится гораздо дороже, чем оценить его преимущества и развить их. Понятно, что мы не можем корректировать свои стандарты под каждого специалиста. Поэтому ментор в нашей компании выступает в роли “маппинга” между разработчиком и целями и стандартами компании.
