Всем доброго времени суток! Меня зовут Лукьянов Кирилл. Около шести лет назад я пришел в 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 и могу заниматься любимым делом, приносящим пользу обществу, совместно с коллегами. Спасибо за интерес, всем до встречи.

Комментарии (11)


  1. PMVyatkin
    26.04.2018 10:41
    +1

    Спасибо за статью, интересно.
    Раньше я про Veeam не слышал, но увидил в ленте — это клево. Особенно нравится адекватных подход к дедлайном релизов :-)
    Все у вас клево — и офис, и культура, и продукты — одно не хорошо — вы не в Москве :-(


    1. Loxmatiymamont
      26.04.2018 13:07

      Вот нам так наоборот, очень хорошо, что мы не в Москве ))


      1. PMVyatkin
        26.04.2018 13:12
        +1

        Почему? ) В Мск — хороший транспорт, лучшие ВУЗы (ну ИТМО не считая), центры сертификаций, большой рынок труда.
        В СПб этого всего нету. Хочешь сдать экзамен РМР, предположим — едешь в Москву. Хочешь съездить на конференцию — скорее всего едешь в Москву. Заказчиков для русскоязычных компаний — тоже много именно здесь.


        1. Loxmatiymamont
          26.04.2018 13:17

          Слушайте, ну видите как вам там хорошо. Это прям отлично.
          А у нас видимо судьба такая, ходить пешком в церковно-приходские школы, да на судьбу столичных рмр (уж извините, не знаю что это за буквы такие) облизываться, без заказчиков и конференций.
          Так что ни в коем случае не надо в наш город приезжать! Тут только разруха, дожди, боль и страдание…

          P.S. Не сдержался и загуглил про рмр. Точно не приезжайте. Для эффективных менеджеров у нас тут никаких условий. Боль, разруха и дожди…


          1. PMVyatkin
            26.04.2018 13:31

            Я почему то считал чтоо наоборот (кроме дождей, конечно).
            Но, обычно у больший компаний офисы в Мск есть, и РМР не столько в Мск в почете, сколько за границей.


            1. polarowl
              26.04.2018 14:48

              Вообще-то у Veeam есть офис и в Москве (хоть и небольшой) в БЦ «Смоленский пассаж». Из технических специалистов там работают, например, системные инженеры. Хотя они нередко в разъездах, в офисе их можно и не застать.
              А хороший транспорт, приличные ВУЗы, отличное крафтовое пиво и т.д. есть в Праге :)


        1. proercontra
          27.04.2018 10:40

          ИТМО — а еще СПбГУ, Политех, ЛЭТИ. Куча отличных спецов вышла из военмеха.
          Рынок труда — в Питере весьма обширен.
          Экзамены — это вообще я не знаю, откуда вы придумали. Всё прекрасно в Питере сдается.
          Конференции — Joker, например.
          Транспорт — тут сложнее… мне. Потому что я не знаю, что лично вы считаете «хорошим транспортом».


          1. PMVyatkin
            27.04.2018 11:14

            В Москве тоже вузов хватает — Бауманка, МАИ, ВШЭ, Плехановка, МГУ в конце концов )
            Спорить кто лучше — можно долго, но рейтинги ВУЗов говорят в пользу Москвы.
            Да, экзамены есть — тут я ошибался (
            Конференции — тоже есть, но их меньше.
            С рынком труда — да, он есть и он обширен, но в Москве — он больше, намного больше — даже не в три раза.
            Метро на 200 станций по всему городу я считаю очень хорошим транспортом, а так же МЦК которая до 100 км час едет в реальности — я считаю хорошим транспортом.
            Паромы и трамваи считаю плохим транспортом, едут плохо, боятся снегопадов и пробок.


      1. angrydok
        26.04.2018 18:56

        Как в старом анекдоте.

        Две причины, по которым я не увидел Эйфелеву башню:
        1. Она не в Лондоне
        2. Я не в Лондоне


  1. werklop
    26.04.2018 11:35

    Пф… бла… бла… бла…
    Вы скажите конкретно, сколько денег платите? Всякие «печеньки» никакому профессиональному разработчику не нужны, оставьте это джунам


  1. bocharovf
    26.04.2018 18:05
    +1

    Спасибо, конечно, но хотелось бы больше конкретики по сабжу — «от старшего разработчика до руководителя отдела»:

    • Что конретно читали / смотрели / пробовали по теме управления командой? (не выпасом котов же единым)
    • Что оказалось полезно, а что нет?
    • Какие ошибки совершили, как исправили?