На моей первой работе в роли программиста у меня ушло три недели на то, чтобы полностью настроить рабочее окружение. Я был всего лишь вторым программистом в данной компании (а первый уволился — меня потому и взяли). Никакой документации, никакой передачи знаний. Всё пришлось изобретать самому.
На втором моём месте работы я управился с той же задачей уже всего за четыре дня. В команде было целых восемь человек, так что я мог задавать вопросы и получать ответы.
Сегодня есть люди, которые заявляют что-то вроде «мы используем Docker для настройки окружения, так что включить нового человека в проект занимает меньше часа».
С одной стороны, я, конечно, рад за новых разработчиков, которым не нужно проходить через те боль и страдания, которые в своё время прошел я. Но с другой стороны «настроенное рабочее окружение» ещё совершенно не равно «разработчику, вовлечённому в проект». Чтобы работать продуктивно, человеку нужно нечто большее, чем просто компьютер, настроенный под разработку данного проекта.
Заблуждения менеджера
Может создаться впечатление, что дав новому члену команды настроенный компьютер, мы сделали всё необходимое для его дальнейшей продуктивной работы. Ну правда, что же ещё нужно программисту, кроме компьютера, стула, стола и исходников проекта, над которым предстоит работать?
Такой подход может оказаться очень опасным. Опасным для менеджеров проекта и ещё более опасным для нового разработчика. В некоторых компаниях, где я работал, иногда случались разговоры вот такого типа:
Я: Как там дела у нового разработчика?
Менеджер: Ну, как-то работает… Пока не очень, но я надеюсь, что со временем станет лучше.
Я: А что именно не так?
Менеджер: Ну, мы помогли ему настроить рабочее окружение достаточно быстро и дали все нужные доступы. Но работает он медленнее, чем я ожидал.
Я: А почему ты ожидал, что он будет работать быстрее?
Менеджер: Во-первых, он хорошо показал знания Java на собеседовании. Во-вторых, мы вложили много усилий в автоматизацию разворачивания рабочей среды — и это должно было помочь ему быстрее войти в курс дела. На его пути нет никаких преград.
Как вы можете заметить, ситуация здесь более опасна для программиста, поскольку его работа оценена как недостаточно эффективная. Менеджер не доволен тем, насколько быстро новый разработчик работает над задачами. И при этом этот же менеджер считает, что сделал всё от него зависящее, чтобы сделать его работу эффективной (просто дав ему настроенный компьютер). А значит, всё дело в способностях или мотивации нового разработчика.
В этих умозаключениях игнорируется наиболее важная причина хорошей (или плохой) продуктивности: хорошие взаимоотношения и здоровый климат в команде. Вот на чём следует сфокусироваться при добавлении нового сотрудника и это точно нельзя автоматизировать. И это займёт больше, чем пара часов.
Включение нового сотрудника в команду
Это одна из ключевых обязанностей менеджеров и тимлидов. И сюда не входят задачи HR по найму нового сотрудника или работа офисных служб по организации его рабочего места. По моему опыту, в это понятие можно включить:
- Знакомство с командой в общем
- Объяснение зоны ответственности каждого члена команды
- Чёткое объяснение текущих целей команды и планов на будущее
- Чёткое объяснение ценностей команды
- Указание людей, к которым можно обращаться за помощью, а также того, насколько часто это уместно делать
- Объяснение того, по какой методологии ведётся разработка и приглашение на ближайшее собрание
- Объяснение используемых каналов коммуникаций в команде (чаты, почта, аудио-видео связь) с предоставлением всех необходимых контактов
- Обязательная обратная связь от менеджера после первой выполненный задачи
- Чёткое понимание того, что из используемого стека технологий знакомо новому сотруднику, а что требуется изучить. Выделение времени на изучение.
- Настройка рабочего окружение (ну да, это тоже нужно)
Сколько времени этой займёт?
Наивно полагать, что всё вышеперечисленное можно сделать за пару дней. По моему опыту уходит минимум недели две, чтобы дать новому сотруднику действительно всё необходимое ему для работы. После этого можно ожидать плавного возрастания его продуктивности, которая выйдет на максимум через несколько кварталов (я не оговорился, через 3-9 месяцев). И только после этого вы можете без поблажек посмотреть на эффективность работы программиста.
Конечно, всё это очень зависит от типа и масштабов проекта. Однажды я руководил разработкой громадной ERP-системы, где на включение нового программиста в работу уходил почти год. Это очень важная часть работы руководителя проекта. Её не обязательно всю делать самостоятельно, но нужно контролировать, что она всё же кем-то делается.
Проявив дружелюбие и уважение к своему новому сотруднику, вы закладываете базис на годы продуктивной работы. Не старайтесь свести важный процесс знакомства и построения отношений с человеком к настройке его компьютера и бумажной работе HR-отдела. Так вы не получите коллегу, с которым будет приятно ежедневно работать рука об руку.
Автор: tangro
