«Я не успеваю писать код, но участвую во всех важных обсуждениях». Как работает руководитель разработки Яндекс.Практикума

Сайт за 300$

Мой путь в разработку начался ещё в школе, как хобби. Мы изучали Pascal, я периодически оставался после уроков в компьютерном классе, пробовал что-то программировать. Потом познакомился с C++.

Ближе к старшим классам дома появился интернет, и я начал интересоваться, что под капотом у разных сайтов, как они сделаны. Смотрел исходный код и разбирался, как всё устроено. Тогда было мало обучающих материалов, но мне удалось найти документацию и форумы, и так я познакомился с HTML, JS и PHP.

Тогда же, в последних классах школы, заработал на этом первые деньги. Я часто бывал в одном интернет-кафе моего района, и там мне по знакомству предложили сделать сайт для местной локальной сети. Заплатили 300$, разделил их с дизайнером.

Реально ли сейчас, ничего не зная, сделать сайт за деньги?

Вполне. Например, порог входа в вёрстку крайне низкий. Порой сложнее пользоваться «Вордом». Сайт можно сверстать незначительным набором HTML-тегов вообще без применения CSS или не владея современными техниками. Никуда не исчезла возможность сверстать сайт топорно «на таблицах», как это делали 20 лет назад, неискушённый заказчик вряд ли заметит разницу.

Череда первых работ

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

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

В начале 2010 года устроился в Авто.ру — первое стабильное место работы. Там я проработал полтора года, занимался бэк-офисом и рекламным движком.

Переход в сервис знакомств

Через полтора года я попал на собеседование в сервис знакомств Badoo. Работать в Авто.ру было вполне комфортно, но на новом месте предложили значительно более интересные условия. В итоге проработал там 7 лет, пришёл PHP-разработчиком и успел вырасти до тимлида небольшой команды.

7 лет в Badoo

В Badoo тогда было несколько команд: биллинг, платформа, антиспам и другие. Я работал на передовой — в команде Feature-team, которая занималась продуктовой разработкой. К нам приходили менеджеры продукта и говорили, какая им нужна функциональность: новая страница, сервис или письмо. Или просили внести изменения в то, что уже было.

Одной из базовых задач нашей команды было хранение и подготовка данных, из которых формируются клиентские страницы. Поначалу мы вставляли эти данные в HTML-шаблоны и отдавали в браузер. Звучит просто, но и в этом были нюансы: стоит учесть, например, что Badoo поддерживает 40 языков. Чтобы сформировать на каждом из них лексически правильную фразу вида «шатен, ростом 170 см, с голубыми глазами», было написано внушительное количество кода.

Со временем Badoo превратился в мультиплатформенный сервис: у нас была версия для веба, для мобильных устройств, приложения для iOS, Android и Windows Mobile. Помимо основного приложения Badoo, появились другие со своей аудиторией, но на той же платформе: Bumble, Chappy и Lumen. Ещё были white label приложения с той же аудиторией, но другим интерфейсом: HotOrNot, Huggle и Blendr. Процесс разработки преобразился. Мы начали разрабатывать API с использованием Google Protobuf, добавилась поддержка версий различных клиентов, научились делать A/B-тесты.

В Badoo я участвовал в разработке большинства крупных и важных проектов, застал компанию в начале её стремительного роста, принимал участие в становлении многих рабочих процессов. Например, в переходе с SVN на Git, трансформации сайта в Single Page Application, интеграции с американскими приложениями HotOrNot и Fiesta.

Специфика большого проекта

Badoo — популярный сервис с большой аудиторией. Это классический хайлоад-проект — на систему постоянно идёт высокая нагрузка, пользователи лайкают друг друга, общаются, регистрируются, загружают фотографии. Цена ошибки в таком случае велика, но результат того стоит: делаешь продукт, которым пользуются миллионы людей.

👉 Пример. Одним из значимых проектов, где чувствуется масштаб сервиса, была система групповых уведомлений. Пока пользователь отсутствует в сервисе, у него может накопиться много событий: появилась новая пара, кто-то посетил профиль, пришло сообщение. Пользователю не нравится, когда в почту валится куча писем, так что мы научились их объединять. В итоге приходит не десять сообщений, а одно, в котором десять новостей.

Для работы с уведомлениями разработали отдельную систему управления базами данных. Это приложение, которое хранит массив событий и в нужный момент отправляет новую партию уведомлений. Это одна из самых нагруженных систем в Badoo: в каждом из двух дата-центров на момент запуска работало по 4 таких приложения, чтобы справляться с нагрузкой — на пике тогда доходило до 25 тысяч запросов в секунду.

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

Порог входа в разработку Badoo нельзя назвать простым: нужно держать в голове кучу зависимостей и особенностей архитектуры, большую нагрузку и объёмы хранимой информации. Понимать, как правильно получать и обрабатывать данные.

Собственный фреймворк

Я был автором нового PHP-фреймворка Badoo. Он был нужен, чтобы упростить создание страниц сайта, в том числе быстро из коробки делать мобильные версии, а также избавиться от высокой связанности кода.

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

Из разработчика в тимлиды

Последние два года в Badoo я руководил небольшой группой разработчиков. Мы занимались проектом, связанным с рекламой: было много работы по биллингу, интеграции с соцсетями и взаимодействию с платёжными системами. К тому моменту я уже давно интересовался, как правильно управлять командой и выполнять менеджерские функции, читал соответствующие книги и статьи, поэтому эта роль для меня была изначально понятна и я осознавал, что нужно делать.

Мне обе роли нравятся, и разработчика, и руководителя. Кодить — увлекательный процесс, от этого не уйдёшь. Но и в руководстве есть свои прелести, когда ты силами большого числа людей можешь делать большие проекты. Когда у тебя есть команда — это крутое ощущение: «Ты не один, вместе вы можете сделать намного больше».

Переход в Яндекс

Со временем у меня появилось ощущение, что в Badoo я достиг потолка: сказался узкий стек технологий, не хватало развития. Также повлияла смена приоритетов развития компании. Поэтому я начал смотреть на предложения на рынке. В итоге оказался в проекте с рабочим названием «Яндекс.Навыки», который позже преобразовался в Практикум.

Когда я пришёл, в команде было два разработчика, один фронт и один бэк. Они уже сделали прототип первого тренажёра на Ruby, и стояла задача на его основе сделать боевую версию. Мы следовали продуктовому бэклогу релиза, который к тому времени был уже сформирован.

Первое время я активно вникал во внутреннюю инфраструктуру Яндекса и участвовал в разработке бэкенда на Django. Мы добавляли новые модели, проектировали базу данных: профессии, курсы, уроки, задания, сохранение решений, вычисление прогресса студента. С ростом команды у меня начало прибавляться менеджерских функций и на код оставалось всё меньше времени.

Из тимлида в руководителя службы

Команда постепенно выросла до 10–12 человек, стало ещё больше внутренних заказчиков. Менеджерской работы стало значительно больше, чем технической. Мой фокус сместился от программирования к организации команды, управлению процессами, большему погружению в продукт и налаживанию взаимодействия с другими отделами.

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

👉 Одна из моих главных задач — поддерживать комфортную атмосферу в коллективе и работать с талантами. Зачастую поставить цель разработчикам не так-то просто. Кому-то больше подходят глобальные архитектурные задачи — закопаться в код, перебрать всю систему. Кому-то — менеджерские, например, договориться со всеми и правильно выстроить работу. И тут надо быть очень аккуратным, чтобы верно направить человека и помочь ему с ростом, а не вогнать его в уныние.

Интересно, что софт, который я использую как руководитель, не сильно поменялся: Яндекс.Трекер для задач, Trello для заметок, WebStorm и PyCharm для кода, чаты в Telegram. Но намного активнее стал использовать календарь — такого количества встреч раньше не было.

Работа в Практикуме

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

В каждой команде есть свой тимлид и свои процессы. Так что я совсем не лезу в микроменеджмент: не говорю никому, какую брать задачу и как её решить.

У нас нет выделенных проектных менеджеров в разработке, их роль на себя берут разработчики, которым это интересно. Для них это такая точка роста — не только пишут код, но и могут расширить свою зону ответственности: общаются с продактами, декомпозируют задачи, следят за жизненным циклом проектов.

Мы стараемся разрабатывать решения, которые можно использовать много раз. Например, наша платформа позволяет быстро создавать курсы и добавлять новые интерактивные тренажёры разного плана. Это даёт возможность в сжатые сроки собирать новые профессии и начинать обучение студентов — не нужно разрабатывать каждый раз с нуля.

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

Чтобы все были в курсе, как дела в разработке, каждая команда проводит ежедневные стендапы по 15 минут. Еженедельно проводим встречи по текущим и будущим проектам. В конце спринтов проводим ретроспективу и обсуждаем, что можно изменить в процессах. У всей команды Практикума ещё есть регулярное демо, где все показывают результаты за последнее время.

Развитие и перспектива

Прелесть IT в том, что всегда есть куда развиваться. Это настолько большая сфера, что быть специалистом во всём невозможно. Я, например, силён в разработке, но не так силён в data science. Тут у меня огромное поле для роста.

Есть возможности для развития и в проектах, которые мы делаем. Наши заказчики пользуются инструментами, которые было бы здорово заменить или доработать, и мы им предлагаем своё решение. Например, делаем свою удобную CMS и продвинутые диаграммы Ганта, чтобы улучшить общее планирование.

В свободное время я стараюсь подтягивать недостающие навыки. В том числе изучаю наши курсы, недавно подтянул знания по Node.js. Получается двойная польза: получаю новые знания и отправляю команде баг-репорты.