В 2015 году я перешёл в компанию, где мне предстояло поработать над очень разными проектами, участвовать в развитии команды, получении партнёрских компетенций 1С-Битрикс и работе нескольких офисов.
Один из проектов этого периода позже окажется судьбоносным и станет шагом к переходу на «тёмную сторону» заказчика. Но это уже будет другая история.
А эта серия — про путь от тимлида до руководителя направления разработки. Про процессы, людей, ошибки, рост команды и постепенное понимание, что разработка — это не только код.
Соревновательный старт
Мой приход в компанию получился интересным — почти соревновательным.
У компании было несколько офисов. Я пришёл в один из них, который располагался в Москве, рядом с метро Новые Черёмушки. Отделу веб-разработки требовалось усилить команду и организовать её работу. Нужен был сильный тимлид, который смог бы выстроить процессы и поднять производительность.
В команде уже были ведущий программист, мидлы и стажёры. Начальник отдела предложил нестандартный вариант: группу разработки разделили на две части. По итогам работы тимлид победившей подгруппы должен был возглавить всю группу разработки.
Борьба, скажем честно, изначально выглядела не совсем равной. Сильных разработчиков забрал себе ведущий программист. Но я не растерялся и начал с анализа проблемы.
Задачи без вводных
Первая задача была очевидна — поднять производительность разработки.
И тут меня ждал сюрприз.
Я увидел, как ставятся задачи разработчикам. Часто это было просто название задачи — без подробностей, без ссылок на техническое задание, без описания ожидаемого результата. После этого начиналось ожидание: кто объяснит, кто поможет, кто сформулирует архитектурное решение.
Кроме того, не было привычки вовремя обращаться за помощью. Разработчик мог несколько дней искать решение самостоятельно, и далеко не всегда это решение в итоге оказывалось правильным.
Два простых изменения
Сначала я занялся задачами и взаимодействием с руководителями проектов. Мы выработали понятный для всех формат: задача должна содержать описание, необходимые вводные или хотя бы ссылку на конкретные страницы технического задания.
Также мы договорились о простом правиле: если задача не решается в течение двух часов, нужно обращаться за помощью к коллегам или тимлиду. Порог взяли достаточно большой, потому что срочных инцидентов по проектам было не так много.
Решения были простыми, но эффект оказался сильным. Производительность разработки в моей команде выросла примерно в два раза. После этого было принято решение распространить подход на весь отдел.
Так я стал тимлидом всей группы разработки.
Дальше стало серьёзнее
Но на этом история не закончилась. Дальше были внедрение Git, тестовые серверы, интеграции с 1С, обучение внутри команды и даже обучение коллег из соседнего направления — специалистов по 1С.
Были и тяжёлые моменты: первые увольнения, уходы нужных людей из команды, первые управленческие решения, за которые отвечаешь уже не только как разработчик.
Это был мой первый по-настоящему серьёзный опыт управления командой.
И именно с этого момента началась история не только про разработку, но и про процессы, людей и ответственность.
