Александр Обухов: «В сотруднике главное – персональная ответственность, нацеленность на результат, проактивность»

Александр Обухов:
«В сотруднике главное – персональная ответственность, нацеленность на результат, проактивность»

На вопросы «Системного администратора» отвечает Александр Обухов, тимлид backend-команды разработки LinguaLeo

Александр Обухов, тимлид backend-команды разработки LinguaLeo. Закончил МГТУ им. Н.Э. Баумана по специальности «Вычислительные машины, комплексы, системы и сети». В сфере разработки ПО с 2006 года. В LinguaLeo работает три года. Начинал backend-разработчиком в команде курсов, потом был тимлидом команды контентной платформы, теперь команды Backend

– Что входит в обязанности тимлида в вашей компании? Что можно отнести к особенностям?

– Тимлид backend, веб или мобильной команды – это некий «интерфейс» механизма работы этой команды. Он участвует в коммуникации или организует встречи членов его группы с представителями смежных подразделений. Мне чаще всего приходится общаться с менеджерами по продукту, уточнять их требования к задачам, прогнозировать сроки готовности той или иной функциональности. Также я часто контактирую с тимлидами веб- и мобильных команд, обсуждаю контракт по взаимодействию частей нашего продукта, за которые каждый из нас отвечает, протоколы обмена данными или принципиальные моменты, например, на чьей стороне лучше реализовать функцию. Иногда подобные вопросы сотрудники решают в обсуждениях без моего участия, но я стараюсь по возможности помогать.

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

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

– Сколько человек работают под вашим руководством?

– Не очень люблю использовать слово «руководство» в данном контексте. Лучше скажу, что в команде, с которой я работаю в настоящий момент, кроме меня, пять человек.

– Какими принципами вы руководствуетесь при отборе сотрудников в свою команду?

– При подборе сотрудников в LinguaLeo в первую очередь смотрим на уровень технической подготовки. Кандидаты проходят достаточно сложное техническое интервью, решают практические задачи и отвечают на теоретические вопросы, ответы на которые не всегда лежат на поверхности. Личные качества также очень важны. В сотруднике главное – персональная ответственность, нацеленность на результат, проактивность, когда при возникновении проблемы первая мысль– как можно ее решить и не допускать в будущем. Умение искать альтернативные пути, видеть проблему под разными углами. Также важны командные качества – уважение к коллегам, готовность выслушать их и оказать им поддержку. Ценю легкость в общении и чувство юмора.

– Какие технологии (программная архитектура) используются в LinguaLeo?

– Используем достаточно стандартный стек технологий: PHP, MySQL, Memcache, Redis, RabbitMQ, Sphinx, Composer для управления зависимостями, множество открытых библиотек и компонентов. Используем облачную платформу EC2от Amazon и некоторые из их сервисов – Cloudfront, S3.

– Есть ли у вас API для разработчиков? Если да, то что позволяет делать?

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

– Какие методологии разработки используются в LinguaLeo? Почему выбор был остановлен именно на них?

– Используем гибкие методологии. В основном Scrum внутри команды и частично Kanban для взаимодействия между командами. Конечно, нельзя сказать, что у нас чистый Scrum, хотя мы используем большинство техник из него – спринты, относительные оценки в стори-поинтах, дейли-митинги, ретроспективы. Однако мы отказались от кросс-функциональных фичевых команд в пользу функционального деления. Это позволило более системно работать надпродуктом и инструментарием. Повысило уровень требований к документации и описанию контрактов взаимодействия между модулями системы. Оверхэд на разработку окупается побочным продуктом такого процесса – документацией нареализацию тех или иных задач.

– Как в вашей компании на уровне разработки организован процесс интеграции с внешними сервисами? С какими?

– Мы используем некоторые внешние сервисы, как языковые со своим API для переводов слов и фраз, их озвучки и транскрипции, так и бизнесовые инструменты, в первую очередь связанные с оплатами, маркетингом, почтовыми рассылками. С точки зрения процесса разработки это обычная задача с высокой степенью неопределенности. Интеграция происходит следующим образом. Сначала идет этап исследования и выработки технического решения, онпредставлен в виде документа или набора тикетов в Jira. Затем приступаем к реализации. Наиболее критичные для нас внешние сервисы включены в наш внутренний мониторинг, так как качество любого из компонентов наряду с нашим собственным кодом составляет качество нашего продукта в целом.

– Возникали ли сложности в этом процессе интеграции? Может, приходилось даже отказаться от интеграции с тем или иным сервисом?

– В процессе интеграции такого не припомню, но в процессе эксплуатации возникают проблемы по ряду причин. Иногда качество сервиса, который мы хотим внедрить, не соответствует ожиданиям, особенно это касается языковых сервисов и text-to-speech и speech-to-text-технологий. Другой причиной отказа от интеграции является производительность сервиса. Наш проект проецирует свою нагрузку на сервисы, с которыми интегрирован. Именно в связи с этим мы отслеживаем периоды простоя и общий процент необработанных запросов. Есть прецеденты отказа от одного сервиса в пользу другого именно в связи с недостаточной стабильностью первого.

– Как организован процесс тестирования? Его особенности?

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

Сам процесс реализации задачи состоит из нескольких видов тестирования. Разработчики всегда пишут unit-тесты. Если какой-то из тестов сломался, задача не может уйти даже на ревью. Наш CI-инструмент автоматически проводит инспекции, включающие прогон автотестов и контроль соответствия кода стандартам оформления. После ревью каждая задача тестируется вручную на своем стенде, до включения в основную версию кода. Затем повторно тестируется релизная сборка на предмет регресса и ошибок интеграции разных фич.

– В каких проектах принимали участие? А в Open Source-проектах? Какой вклад внесли в последние?

– Когда только начинал работать в компании LinguaLeo рядовым разработчиком, запускалиcь курсы, потом авторская платформа для них же. Делали улучшения в джунглях, связанные как с UGC и авторскими механиками, так и синтеграцией с поставщиками контента. Реализовывал интеграцию с TED. Запустили и перезапустили дашборд, еще когда у нас было фичевое деление команд. В последнее время участвую в той или иной степени во всех проектах LinguaLeo, где требуется разработка серверного приложения, но теперь больше занимаюсь проработкой требований и технических решений к задачам, а не их реализацией.

В Open Source-проектах я лично участия не принимал, но LinguaLeo в целом может похвастаться своим вкладом в Open Source-движение. Некоторые компоненты, которые мы писали для себя, выпустили под открытой лицензией MIT. Например: свой DI-контейнер, простые библио­теки – для работы с базой данных, с кэшированием, отложенным выполнением; реализации клиентов к API сервисов, с которыми работаем. Я сделал свой скромный вклад в это богатство – инструмент просмотра отладочных email-сообщений, назвал его fakemail. Но в связи с переездом на ESP мы им больше не пользуемся. Все можно увидеть на странице нашего аккаунта в Github: https://github.com/LinguaLeo.

– Какой программный инструментарий используете?

– Внутри команды используем продукты Atlassian для организации процесса, в основном это JIRA и Confluence, hipChat для оперативного общения. Для контроля версий, как вы, наверное, уже поняли, – Git. В качестве CI-сервера используем Teamcity, для автоматизации процессов у нас собственное решение, интегрирующее воркфлоу JIRA с Teamcity и github. Из популярных инструментов разработчика используем phpStorm, Sublime, Sequel Pro, Vagrant, консоль.

– Как выглядят аппаратные предпочтения?

– Среди сотрудников LinguaLeo популярнее всего макбуки, я лично пользуюсь MacBook Pro late 2013. Из важных плюсов – большое время автономной работы и привычная, подобная Linux, среда.

– Используете ли социальные сети, веб-сервисы? Для каких целей?

– Использую Facebook для общения и отслеживания отраслевых новостей (подписан на тематические страницы и сообщества). Слушаю музыку в Google Music по подписке. Читаю книги на Bookmate. Храню важную информацию вEvernote, лонгриды откладываю в getpocket.com. Активно пользуюсь сервисами Google – почта, календарь, диск, фото. На YouTube подписан более чем на 110 каналов, от развлекательных до новостных из области технологий (Droider, Rozetked) и научно-популярных (Vsauce, AsapSCIENCE).

– В каких ИТ-мероприятиях принимаете участие (конференции, лекции и т.п.)?

– Посещал Highload, тематические конференции по технологиям (Zend framework). Прошел курс лекций в центре «Специалист» при МГТУ им. Н.Э. Баумана по управлению проектами («Управление проектами на основе стандарта ANSI PMI PMBoK v.5», «Управление командой проекта. Инструменты и мотивация»).

Беседовал Игорь Штомпель

Комментарии могут оставлять только зарегистрированные пользователи