Пролить SEM потов: карьерный путь от разработчика до software engineering manager
Меня зовут Аким Кротов, я Software Engineering Manager (SEM) в Kolesa Group, в продукте Krisha.kz. В этой статье хочу поделиться своим 12-летним опытом карьерного развития (историей успеха) от web-разработчика до SEM-а.
Что для меня успех (немного лирики)
Для меня успех — это когда ты приносишь пользу и получаешь от этого удовольствие. Что в этом сложного и особенного? У многих людей в силу разных причин — бюрократии, недоверия со стороны коллег или непонимания предметной области — образуются трудности. Им становится тяжело достичь чего-то значимого в своей работе и они начинают просто плыть по течению. Делают прилетающие задачи, не всегда понимая зачем они нужны.
Есть два пути развития разработчика:
а) продолжать плыть по течению, не особо вникая в собственные задачи;
б) дать работе проникнуть в твою жизнь так, чтобы любая задача стала личным делом и долгом.
Я бессознательно пошел по второму пути, так как первый вариант не ведёт к развитию. Далее советую идти по следующему сценарию: при выполнении задач изучайте весь смежный код проекта — так к вам со временем придёт понимание почти всей архитектуры. Благодаря этому в будущем вы сможете решать сложные кейсы и помогать коллегам.
Начало карьеры, работа в веб-студиях, 2010 год
Начинал с заказов на фрилансе, изучал PHP, читал книги, верстал. Учился на магистратуре в Московском техническом университете связи и информатики, специальность — связист.
Первым моим местом работы была контора, предоставляющая услуги 1С. У них был сайт на PHP, который мне нужно было поддерживать. Мне выдали полный карт-бланш на его развитие. Потихоньку я стал вникать в процессы работы, ко мне приходили люди с разных отделов со своими нуждами. Но счастье продлилось недолго: спустя 2 месяца работы на сайт совершили хакерское нападение и директор подумал, что это был я. Произошла дискоммуникация, руководство потеряло ко мне доверие и попрощалось со мной.
Уже через неделю нашел новое место работы — веб-студию. Там мне нужно было создавать сайты, беря за основу движок «index.php», где уже была заложена базовая логика работы. Также нужно было поддерживать существующие сайты. Проработал я в этой веб-студии всего 2 месяца, так как магистратура закончилась и я вернулся домой в Алматы.
Итог: первые два места работы, несмотря на суммарные 4 месяца труда, дали мне бесценный опыт:
1. Важную информацию, от которой зависит твоя дальнейшая судьба, нужно незамедлительно передавать человеку, принимающему решения, лично. Не ментору, а руководителю/директору.
2. От видов инструментов разработки очень сильно зависит качество производимого программистами софта.
Уже через 2 недели после возвращения в Алматы нашёл работу в веб-студии. Она была сильна технически: cистема контроля версии, таск-трекинг в гугл-доках и неплохой самописный фреймворк. И коллектив был хороший. Но были и минусы: серьёзные проблемы в менеджменте, задержки в выдаче зарплат, однообразие задач. С учётом всех этих проблем начал искать другую работу. Увидел вакансию разработчика на kolesa.kz — сайте бесплатных объявлений о продаже и покупке автомобилей в Казахстане. Из описания позиции понял, что задачи будут всегда разные, и отправил резюме.
Kolesa.kz. PHP-разработчик, 2011–2014 годы
Кратко об обстановке в продукте на тот момент: сервера не справлялись с нагрузкой, вызванной большим трафиком. Как следствие, сайт очень сильно тормозил по вечерам. Задачи у меня были разные: от вёрстки кнопок до написания запросов в базу данных MySQL.
Шло время, мне очень нравилось работать в компании, особенно разнообразие задач и кратный рост продукта от года к году. Помимо флагманского сайта Kolesa.kz был ещё один продукт — Krisha.kz. Это сайт бесплатных объявлений о продаже, покупке, аренде квартир, домов в Казахстане. И в 2014 году компания решила подкинуть угля в «Крышу».
Krisha.kz. Тимлид разработки, 2014–2020 годы
Мне повезло, что когда продукту Krisha.kz выделили 2 разработчиков, которым нужен был тимлид, у меня уже был релевантный опыт. Я хорошо понимал продукт и умел ладить с коллегами. Мой начальник, получив от меня согласие, ударил посохом по полу и сделал меня тимлидом проекта «Крыши». У продукта появилась сразу целая команда.
Шло время, я привыкал к новой для себя роли. В итоге, моя работа в качестве тимлида сводилась к:
- техническому развитию продукта: выполнению текущих задач, работой с CI\CD для деплоя, автотестирования кода;
- наём и увольнение сотрудников.
Тогда я посвящал коду 70% времени, «тимлидству» — 30%. В ту пору мы приняли ряд изменений, которые благоприятно повлияли на разработку:
• Внедрение дежурств для разработчиков для быстрой связи с линией поддержки.
• Внедрение «пятничных автотестов» — новшество, когда команда в пятницу занимается исключительно написанием автотестов. Так мы за пару месяцев нарастили тесты на ключевые функции сайта.
Это был успешный опыт, который перенимали и смежные команды.
Здесь важно уточнить, что это был 2014 год — тогда у компании не было опыта в развитии тимлидов. Мне приходилось самому в этом разбираться.
Условия смены роли «разработчик → тимлид»:
1. Нужно быть готовым к такому переходу функционально. Потому что между разработчиком, который просто выполняет задачи, и тимлидом, который работает с людьми и ведёт их за собой, большая разница.
2. Для того, чтобы стать тимлидом, прежде всего такая потребность должна возникнуть в самой компании.
Krisha.kz. SEM разработки, 2020 год — наши дни
Компания росла, команд становилось больше, как и людей в них. Потребность в тимлидах стала ещё более острой. В связи с ростом числа тимлидов стало сложнее их координировать. так как они тоже нуждаются в поддержке и помощи. Так в нашей компании зародилась новая веха в развитии управлении разработчиками — Software Engineer Manager (SEM). После введения этой должности мне предложили им стать, и я согласился. Так я стал SEM-ом «Крыши».
SEM в Kolesa Group — это доверенное лицо руководителя, которое управляет, помогает и упрощает жизнь тимлидам. А те, в свою очередь, координируют разработчиков и помогают им. Позиция SEM позволяет фокусироваться на улучшении процессов разработки и повышать качество выполняемых задач.
SEM-ам на написание кода остаётся минимум времени. Основное время уходит на решение каких-то невидимых для разработчиков задач или же очень сложных багов. А именно:
1. SEM следит за развитием всех направлений, которые закладывает бизнес. К примеру, тимлид/техлид смотрит за своей (одной) командой по конкретному направлению, например, за мобильной разработкой. SEM же помогает сразу нескольким командам: backend, frontend, mobile, QA. Работает с лидами и точечно бьёт по проблемным местам.
2. SEM работает непосредственно с руководителем. Через SEM-а происходит трансляция изменений в командах.
3. С продуктовыми задачами работает, в основном, тимлид, и благодаря этому у SEM появляется время подумать над улучшением процесса разработки. Это может быть новый процесс, улучшение старого или помощь другой команде.
Примеры задач SEM-a:
- продумывание и обсуждение стратегических планов разработки;
- движение архитектуры проекта в целом;
- создание для разработчиков более комфортных и менее стрессовых условий труда.
Позиция SEM — лаконичное и естественное продолжение развития разработчика, которому выпала судьба стать тимлидом.
Итоги
Большинство задач завершаются командой без багов на проде и в разумные сроки — это лучшее достижение для любой компании. По «Крыше» на данный момент такие цифры:
- количество сделанных задач без переоткрытий — 90%;
- новые фичи и улучшения — 80% от всех сделанных задач;
- баги — 20% от всех сделанных задач.
Но, конечно, это не моё личное достижение, это вклад каждого члена нашей большой команды Krisha.kz.
В заключение хочу дать несколько простых советов для эффективной работы разработчиком. Основано на ̶р̶е̶а̶л̶ь̶н̶ы̶х̶ ̶с̶о̶б̶ы̶т̶и̶я̶х̶ собственном опыте:
• Каждая рабочая задача — это ваша личная задача. Если это не так, то стоит задуматься почему;
• Делать пометки, затем выполнять их или удалять;
• Оправдывать ожидания руководства или уметь объяснять, если что-то пошло не так;
• Не закапываться в детали;
• Уметь делегировать;
• Читать почту.
