Всем доброго времени суток! Меня зовут Лукьянов Кирилл. Около шести лет назад я пришел в Veeam на позицию старшего разработчика и за это время вырос до руководителя проектов. Сейчас Veeam активно расширяется, и я решил написать о своем развитии в компании и о том, как она работает. Чтобы вы знали, чего ожидать, и чувствовали себя уверенно, если соберетесь на собеседование.

Шаг 1. Собеседование

Решение о смене работы мне далось нелегко. Но задержка зарплаты на предыдущем месте работы приближалась к трем месяцам, при том что проект был в целом завершен. Я решил, что самое время выставить резюме на HH. Собеседование в Veeam было для меня вторым.

О компании я тогда знал немного, но на собеседовании менеджеры четко обрисовали и сферу деятельности в принципе, и круг моих задач. Сейчас направлений много, а в те годы основных было два — бэкап для VMware и бэкап для Hyper-V. С виртуализацией я был знаком на уровне пользователя, а с защитой данных был на «ты», хоть и немного с другим ее аспектом.

Тогда я шел на вакансию Senior C++ Developer, несмотря на то, что до этого в коммерческой разработке моим основным был С. С++ я изучал для себя. Страуструп, Саттер, практика по вечерам, изобретение велосипедов и многочисленные шишки от «тех же граблей». Но все оказалось не зря. Как минимум, я смог вести диалог о простых вещах — контейнерах, итераторах, примитивах ООП и том, что лучше не делать.



Спрашивали не только о профессиональном опыте, но и об увлечениях — программирую ли в свободное время. Как и многие коллеги, с помощью программирования я еще и отдыхаю. Рассказал о том, что писал для себя, какие задачи решал, дал ссылку на свой SVN-сервер и предложил ознакомиться с кодом некоторых своих проектов. Возможно, в моем случае эта факультативная деятельность и сыграла ключевую роль.

Сейчас я сам участвую в наборе людей. Для Veeam по-прежнему важен огонь в глазах потенциального сотрудника.

Помимо увлеченности, требуется и понимание в сфере параллельного программирования, отсюда и входное тестовое задание, которое позволяет проверить эти навыки и не менялось с момента моего прихода в компанию. Сейчас параллельное программирование — это краеугольный камень всей отрасли, без него не написать конкурентоспособных приложений для массового обслуживания. Приходя в Veeam, человек должен быть готовым к тому, чтобы работать в этой парадигме. И, вместе с этим, в Veeam готовы собеседовать кандидатов по несколько раз, так что, в случае неудачи, можно подтянуть скиллы и попробовать снова. Есть примеры, когда через год-полтора после первого собеседования кандидаты приходят снова и получают работу.

Шаг 2. Неизведанный C#

Я пришел в Veeam шесть лет назад, и уже тогда продукт был объемнее всего, с чем я работал ранее. Первые две недели голова кипела просто от того, что я разбирался в коде, с которым придется работать. Нет, не потому что код плохой, а потому, что его было действительно много. Первую неделю я сидел и рисовал UML-диаграммы, чтобы охватить все аспекты архитектуры, которую нужно было расширить. Раньше такого делать не приходилось.



На испытательный срок мне дали задачу, требующую знание C#, — а серьезный опыт у меня был только с C/C++. Я сел разбираться и к концу третьего месяца реализовал рабочий прототип своей первой фичи в продукте — Instant VM Recovery для Hyper-V. Она умеет за считанные минуты поднимать машины любого объема без перекачки данных. В критических ситуациях это может быть очень важно.

С некоторыми оговорками можно сказать, что это была full stack задача — от графического интерфейса пользователя до низкоуровневой интеграции с драйвером. Снизу был драйвер для виртуализации файлов на файловой системе — его написал мой коллега. Далее С++ код должен был получать запросы на чтение и перенаправлять их в наши репозитории. С другой стороны, в С# части продукта необходимо было запрограммировать бизнес-логику и сделать какой-никакой графический интерфейс фичи — правда, методом copy-paste, потому как UI-команда была тогда занята, а для прототипа многого не требовалось. Впоследствии интерфейс, конечно, доработали.

Решить такую задачу помог не только энтузиазм, но и коллеги, которые с радостью отвечали на вопросы и давали информацию о тех частях продукта, которые я еще не знал. Думаю, с помощью такого комплексного квеста руководитель прощупывал мои скиллы, определял место в дальнейшей работе. В итоге испытательный срок я прошел, а та фича до сих пор является частью продукта и развивается вместе с ним. Это приятно.

Шаг 3. Изучение и погружение

В Veeam, в целом, хорошо налажена передача опыта «из уст в уста». Так что никто не остается наедине с проблемой и может быстро получить нужные ответы. На начальном этапе я в основном общался со своим руководителем. Затем возникли вопросы об организации UI — я пошел к другим, профильным руководителям. По мере дальнейшего развития в такие коммуникации вовлекалось все больше коллег.

Я в курсе, что делают соседи

В Veeam мне особенно понравилось, как команда объединяется вокруг продукта. По сути у нас есть один большой проект, который является основным для нашей команды — это Veeam Backup & Replication. Задачи по развитию продукта разделены по направлениям, которые в итоге привносят в готовую версию целый пласт фичей.

Одной фичей, как правило, занимается одна команда. Однако, бывают такие epic-фичи, где задействовано больше команд. Тогда они активно общаются друг с другом. Проводятся current state встречи, на которых мы синхронизируем нашу деятельность. Чтобы все понимали, чем занимаются коллеги, проводятся внутренние вебинары по продукту. Помимо этого, мы ездим на профильные конференции — изучаем и планируем их на год вперед после новогодних каникул.

Я знаю, куда идти

На предыдущем месте работы, в основном, я был предоставлен сам себе. Это полезно, учит самостоятельности и ответственности. Обычно я получал большую задачу и уходил в свободное плавание решать ее. Контролировали выполнение задачи больше по ситуации, а не регулярно.

В Veeam все не так. Если меняются требования или какие-либо условия, все реагируют на это быстро и продолжают двигаться в правильном направлении. Если я не могу сам найти ответы на какие-то вопросы, то знаю, к кому идти. При этом микроменеджментом здесь никто не занимается — соблюдается баланс.

Я не угораю по дедлайнам

А вот что сразу бросилось в глаза: в Veeam нет сверхжестких требований к срокам. Мы можем отступить на неделю-другую от дедлайнов, если от этого выиграет продукт. После реализации какой-нибудь новой фичи мы тратим много времени на то, чтобы довести ее до ума со всех сторон. В этом процессе участвуют все: разработчики, тестировщики, аналитики, технические писатели, сотрудники отдела поддержки и продаж, которые предоставляют нам обратную связь от наших клиентов. Если у кого-нибудь появляется идея, как сделать продукт лучше, он имеет возможность донести ее до руководства. После разговора с лидом и проверки идей на устойчивость, их выносят на всеобщее обсуждение — они имеют все шансы стать фичами в будущих версиях.

Мы отмеряем раз семьдесят и, может, даже не отрежем

Бежать к новым стандартам и инструментариям разработчика мы не спешим. Все оцениваем через специфику продукта, есть жесткие ограничения рынка и клиентов. Замена того же фреймворка .NET у разработчиков обычно не вызывает проблем — он пишется с учетом совместимости. Но в новых версиях могут обнаружиться ошибки, из-за которых поплывет что-нибудь в нашем продукте. Так что при замене фреймворка нужно на предмет совместимости протестировать весь продукт заново.

Тем не менее, мы стараемся, чтобы наш стек не запылился: сейчас вот готовимся перейти на C++11 и решаем последние проблемы с поддержкой в устаревших Linux-системах. Иногда к прогрессу подталкивают другие факторы. Например, у партнера вышла новая версия продукта которую мы должны поддержать, а для этого нужен более новый .NET.

Шаг 4. Из разработчиков в тимлиды

Вернемся к моей истории. Примерно через 8-9 месяцев работы мне предложили стать тимлидом: возглавить Hyper-V направление и взять пару человек в помощь. Кое-какой опыт у меня остался с предыдущего место работы, но там я был сам себе начальник: сидел один в своем собственном отделе и писал код. Только когда проект был на 95% готов, мне наняли в помощь пару человек. Потом я еще год неуверенно набивал руководительские шишки, точно не зная, как развиваться дальше. Прочитал популярную книжку «Как пасти котов», но вынес из нее только положительные эмоции. Когда я осознал, что работе с людьми нужно учиться, как раз пришлось менять работу. Вот такой лидерский багаж был у меня, когда я согласился попробовать себя в роли руководителя в Veeam.



Вообще у разработчика есть два варианта развития — в техническом или в административном направлении. По моим ощущениям, на рынке есть определенный дефицит последних. Немногие этого хотят, а те, кто хочет, вырастают в тимлидов или проджект-менеджеров медленнее, чем развивается бизнес.

Часто компании закрывают позиции тимлида не нанятым со стороны сотрудником, а собственным бывшим разработчиком. Мне тоже предложили попробовать и при этом остаться на позиции senior-разработчика. Если понравится — мне была открыта дорога в административном направлении. Если нет — я мог бы спокойно продолжать развитие в технической ветке.

Тонкости административной ветки только по книгам и статьям изучить сложновато, так что компания направляла меня на различные тренинги по soft skills. Которые для тимлидов переходят в hard skills. Было много разных программ, больше всего запомнились тренинги двух компаний — международной онлайн-школы менеджеров Стратоплан и LiCO.

В Veeam налажен обмен опытом по решению не только технических, но и административных задач. Я старался развиваться и здесь, узнавать как можно больше различных точек зрения — чтобы в различных ситуациях иметь больше инструментов для решений. Остальное приходит с личным опытом. Сталкиваешься с конкретной проблемой, решаешь ее и в дальнейшем стараешься не допускать подобного или использовать уже наработанные решения.

Шаг 5. Административное vs техническое

За шесть лет в Veeam я вырос до руководства отделом разработки программного обеспечения по направлениям Hyper-V и Agent Management. В прямом подчинении у меня семь человек, от junior-ов до senior-ов. И мы занимаемся всеми вопросами, связанными с поддержкой Hyper-V: бэкапы, репликации, ресторы всех возможных вариантов, интеграция с гипервизором и т.п.

Радует, что, несмотря на карьерный подъем, я все еще погружен в техническую сторону продукта. В Veeam код пишут все, даже проджект-менеджеры иногда заглядывают. Хотя их вовлеченность много меньше, чем у самих разработчиков. Тимлиды участвуют в разработке постоянно. В Veeam нет жестких требований к тому, какое количество кода должен писать лид, сколько времени заниматься административными задачами, синхронизацией работы других людей и т.п. Важно лишь что команда в целом будет достигать успеха.

Как и везде, баланс иногда нарушается. За шесть лет моя команда дважды разделялась: в ней вырастали люди, которые сами становились лидами в рамках новой темы. Бывает, что члены команды, которые закрывали определенные задачи, переключаются на другие вопросы. В такие моменты приходится больше времени уделять технической части, и при этом не должна «поплыть» административная — отличная встряска получается. За шесть лет не было таких критических ситуаций, из которых мне не помогли бы выбраться коллеги и руководители.

В Veeam постоянно набирают сотрудников, команды быстро пополняются. Это связано с ростом команды в России и с открытием европейского R&D центра в Праге. Туда могут поехать разработчики, решившие сменить место жительства и продолжать карьеру в Veeam.

А после того, как новые сотрудники набраны, начинается уже моя работа — обучить людей, чтобы все вернулось в нормальное русло.

Шаг 6. Новые тимлиды

Мой путь в Veeam не уникален. В компании стараются создать все условия, чтобы люди постепенно росли в интересном для них направлении. Понятно, что происходит это не мгновенно. В управленческой ветке путь с позиции middle-разработчика до тимлида с прохождением всех промежуточных стадий (experienced developer, senior developer, junior team leader) в среднем у нас занимает 3,5-4 года.



Поэтому на работе одна из основных моих задач – выращивать себе замену. Шучу. Растить подчиненных, на которых можно положиться в работе как на самого себя. Я не против, если рано или поздно все сотрудники, которые сегодня находятся в моем подчинении, станут лидами или архитекторами, обретут самостоятельность и возглавят свое направление.

Напоследок расскажу немного про «внеклассную» активность. Помимо обычных праздников, несколько раз в год мы проводим мероприятия, которые выбираем сами. Компания выделяет бюджет на такое мероприятие, и мы можем его освоить по своему усмотрению. В такой момент безучастных почти не остается, вся команда выбирает между баром, боулингом или чем-то новым. Есть и массовые активности, когда ~150 человек едут на турбазу кататься на квадроциклах и жарить шашлыки.

Еще в компании есть масса «клубов по интересам», например, любители киберспорта могут объединиться и устроить корпоративный турнир по «Контре». Почти на все виды досуга есть свой кружок единомышленников, их уже больше десяти.

Сейчас в Veeam более 100 разработчиков — это в 4 раза больше, чем когда я пришел в компанию. Теперь HR периодически проводит массовые опросы о том, чего нам не хватает. По итогам таких опросов появились вебинары, штатный преподаватель английского языка и посещение конференций.

Полгода назад мы запустили проект Veeam Academy — для тех, кто собирается связать свою жизнь с программированием, однако еще не имеет большого опыта. В ней можно пройти интенсивный курс обучения и освоить наиболее востребованные на рынке технологии, получить опыт работы над проектом по Agile-методологии. В Veeam Academy я выступаю в качестве приглашенного лектора и code reviewer’а. При успешном окончании академии все слушатели курса могут пройти собеседование и присоединиться к нашей команде. Но учиться в академии, чтобы начать работать в Veeam, конечно же, не обязательно.

Вот так сложилась моя карьера. Я рад, что в свое время попал в Veeam и могу заниматься любимым делом, приносящим пользу обществу, совместно с коллегами. Спасибо за интерес, всем до встречи.