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

Узнать побольше про опыт Игоря, Антона и Валерии можно по ссылкам.

Шаг 1: Идея и планирование

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

Игорь Володин отмечает, что после разработки гипотезы ее нужно проверить. И здесь процесс тоже состоит из нескольких этапов:

1. Формулирование гипотезы. Определяем, что мы хотим проверить, описываем гипотезу и предполагаем, как она повлияет на продукт.
2. Создание прототипов. Разрабатываем прототипы или минимально жизнеспособные версии идеи для тестирования.
3. Проверка прототипов. Проводим тестирование, собираем обратную связь, проводим интервью с пользователями для уточнения и корректировки.
4. Анализ результатов. Сравниваем результаты тестирования с ожидаемыми эффектами, выявляем проблемы и дорабатываем идею.
5. Реализация и запуск. Если результаты тестирования положительные, продолжаем реализацию и мониторинг продукта.

Для сбора и анализа данных я использую разные инструменты: аналитические платформы, опросы, интервью и A/B тестирование. Все данные аккумулируются в единую систему, где мы их анализируем, выявляем паттерны и делаем выводы для дальнейших действий. Особенно важно учитывать как количественные, так и качественные данные для полноценного понимания потребностей рынка.

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

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

Этап 2: Дизайн и прототипирование

Один из самых важных этапов, поскольку именно от него зависит внешний вид и функционал конечного продукта. И ключевое здесь — грамотно организовать работу над MVP и проверить UX/UI прототип до разработки.

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

Работа над MVP начинается с четкого определения минимального набора функций, необходимых для проверки основных гипотез. И здесь важно сфокусироваться исключительно на них, чтобы избежать дополнительной нагрузки на команду. Для этого используют такие подходы, как Jobs to be Done или приоритизацию задач с помощью фреймворков вроде RICE, чтобы оценить как значимость идеи, так и её техническую реализуемость. Команда совместно оценивает объём работ и сроки, что позволяет сбалансировать нагрузку и избежать перегрузок.

Проверять UX/UI прототип нужно через разные виды тестирования на пользователях, близких к целевой аудитории. На ранних этапах это могут быть простые кликабельные макеты, которые тестируются через коридорные или юзабилити тесты. Пользователи выполняют ключевые действия на прототипе, а команда наблюдает за их поведением, выявляя проблемные области и потенциальные улучшения. В итоге важно получить честный и непредвзятый фидбек, чтобы внести необходимые изменения до начала разработки. Конечно, можно применять и более количественные методы, например, тепловые карты или A/B тесты, для проверки пользовательского взаимодействия на более широкой аудитории.

Этап 3: Разработка и тестирование

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

При расставлении приоритетов стоит учитывать несколько факторов:

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

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

Для автоматизации тестирования обычно используются инструменты, которые позволяют быстро и эффективно проверять основные сценарии работы продукта. Это могут быть как юнит-тесты, так и интеграционные тесты, покрывающие основные пользовательские флоу. Также применяется CI/CD, чтобы тестирование было встроено в процесс разработки и не задерживало выпуск продукта.

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

Этап 4: Обратная связь и улучшение продукта

Получение и анализ обратной связи от пользователей — ключевые элементы для успешного развития и улучшения продукта. Для этого используются различные каналы и инструменты — от форм Google Forms или NPS/CSAT до соцсетей. Аналитические инструменты помогают отслеживать поведение пользователей и выявлять проблемные места, что дополнительно усиливает понимание потребностей аудитории.

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

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

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

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

Этап 5: Запуск и поддержка

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

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

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

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

В первые 90 дней нужно активно проверять метрики — активации, вовлеченность и удержание пользователей. Если это новый продукт с нуля, ключевыми метриками будут связаны с началом воронки: онбординг пользователей, активация, оплата. А если продукт имеет более частотный характер, как, например, приложение для бронирования, то оценка возвращаемости пользователей может происходить быстрее — через 7, 14 или 30 дней. Важно понимать, какие метрики соответствуют бенчмаркам для конкретного типа продукта, чтобы адекватно оценивать результаты.

Вместо заключения: ретроспектива

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

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

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

После запуска продукта, работа над ним не заканчивается — постоянная обратная связь и регулярные улучшения помогут вашему продукту оставаться актуальным и полезным для ЦА. Основное — это адаптироваться, учиться на опыте и стремиться к улучшениям.

Если у вас остались вопросы или вы хотите получить подробную консультацию по вашему продукту — записывайтесь на встречу с одним из менторов на площадке Solvery.

Елена, расскажи с чего начался твой карьерный путь.

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

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

Потом работала в IT и рекламной сфере, а в Индонезии на острове Бали появилось мое агентство iliveglobally — мы занимаемся стратегическим маркетингом и коммуникациями. С 2022 года мы стали больше сотрудничать с российскими брендами. А в качестве ментора я помогаю предпринимателям выстраивать бизнес-стратегию, находить целевую аудиторию и выстраивать грамотное позиционирование.

Что такое креативные индустрии?

— Есть несколько способов это объяснить.

С одной стороны, есть очень интересный понятийный пласт, который идёт с Востока — он более философский. Здесь раскрывается, что такое индекс креативности и в принципе креативность в компаниях.

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

С точки зрения российского законодательства, креативные индустрии подсчитаны и сформулированы. На днях был подписан закон, который вступит в силу в 2025 году. Это экономическая деятельность, объединяющая 4 пласта индустрий: историко-культурное наследие, искусство, прикладное творчество и информационно-телекоммуникационные технологии. Это всё, что связано с интеллектуальным трудом, который в результате имеет некий уникальный продукт, обладающий экономической ценностью.

То есть всё, что люди создают, придумывая новое, инновационное — это и есть креативные индустрии. Например, архитектура, IT, компьютерные игры, СМИ, реклама, гастрономия, дизайн, театр и всё, что связано галереями, музеями и так далее.

Как технологии изменили креативные индустрии за последние 2-3 года?

— Технологии — это и есть креативная индустрия, так как они являются продуктом творчества людей.

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

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

Технологии ускоряют развитие всех индустрий, в том числе и самих себя.

Какие сейчас тренды ты видишь для работы?

— Сейчас самый мощный тренд — повсеместное использование искусственного интеллекта. Его развитие — настоящий бум. И креативные индустрии он тоже не обойдет стороной — с ним будут играть, экспериментировать и предлагать небанальные, неочевидные и очень практичные решения. Например, в архитектуре и моделировании зданий применяется BIM-технология*. Она помогает решить много вопросов при строительстве и обслуживании зданий.

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

*BIM-технология — виртуальная проектировка здания в 3D.

Как совмещают новые технологии в креативных проектах?

— В парке Зарядье открыли один из самых крупных орга́нов в Европе — в нём около 6000 труб. И ко всем этим трубам, которые были сделаны по средневековым технологиям, с помощью высокотехнологичных кабелей присоединена консоль. Так зрители могут видеть музыканта и наслаждаться качеством звука. Меня очень впечатляет, как с помощью высоких технологий появилась возможность объединиться с вековыми традициями.

Другой интересный пример — это K-pop. Это культура, которая была создана при поддержке правительства Кореи. Они создали классный бренд, чтобы о Корее узнали во всём мире, и придумали целую индустрию, культуру, музыку, героев, литературу. И эта культура захватила мир. По-моему, это отличный пример использования мощного потенциала креативных индустрий.

Какие технологии нужны в оптимизации бизнес-процессов?

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

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

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

Какие сложности возникают при интеграции технологий?

— Главное ограничение — это мышление предпринимателя или главы компании. Если он открыт к изменениям и понимает важность технологий, то сможет донести это до команды.

Есть статистика, что около 20-30% сотрудников полностью принимают новшества, около 40-50% относятся спокойно, а 10% категорически против.

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

Даже если это опытные сотрудники, которые принесли много пользы в прошедшие годы, нужно серьёзно задуматься — а можно ли идти с ними дальше?

Расскажу на примере одной большой финтех-компании. За весь прошлый год они провели большую работу — научили всех сотрудников так или иначе использовать искусственный интеллект. Было организовано много вебинаров, обучающих встреч, чтобы наглядно объяснить сотрудникам, что такое нейросети и как их можно применять. И потом было объявлен конкурс на лучшее решение по внедрению генИИ в рабочие процессы. Лучшие решения вошли в обновлённую стратегию компании. Разумеется, эти изменения лучше принимаются сотрудниками, ведь их придумали они сами.

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

Что важно знать при запуске стартапов в креативных индустриях?

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

С другой стороны, в креативных индустриях важен момент импакта — то есть степень воздействия на общество.

Я считаю, что очень важно иметь искреннюю и сформулированную миссию. Тогда и команда единомышленников найдётся, и инвестор, который в эту идею поверит.

Какие навыки считаешь мастхэв в креативных индустриях?

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

И отдельно хочется сказать про аутентичность — это умение быть собой и иметь внутренний стержень.

Как Лебедев, например. Он работает дизайнером 30 лет: все время создаёт что-то разное, то, что актуально и востребовано — от сайтов до архитектуры и айдентики городов. При этом он максимально аутентичный — в нём есть это желание и потом уже умение быть креатором и дизайнером.

Самость — это очень важное качество.

Какие ресурсы и инструменты посоветуешь начинающим предпринимателям?

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

Например, у меня есть менти из РУДН — студентка теперь уже второго курса. Она победитель олимпиады по технологии, и её проектом было создание физической одежды по эскизам Варвары Степановой, художницы начала XX века.

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

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

Как технологии могут ограничить или, наоборот, расширить креативность?

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

При этом могут ли технологии вообще как-то повлиять на развитие креативности у человека? Я не думаю.

Как найти баланс между технологиями и личной креативностью?

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

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

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

Одновременно с этим гуманистическим подходом мы действительно переживаем технологический бум. Развиваются и голосовые помощники, и машинное обучение, и искусственный интеллект, и NFT, и токены, и метавселенные. Но всё это имеет смысл, когда упрощает, улучшает жизнь людей.

Что будет в сфере в ближайшие 5 лет?

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

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

Какие книги, фильмы или подкасты порекомендуешь?

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

Также рекомендую классическую русскую литературу — там много ответов на разные вопросы. Просто читайте и наслаждайтесь.

Рекомендую послушать и подкасты ProMentoring от Клуба Менторов.

С Еленой и другими менторами вы можете познакомиться в Клубе Менторов. Специалисты помогут не только с карьерными вопросами, но и с вопросами ведения собственного бизнеса.

После закрытия Zenly мы вместе с коллегами Димой Трачуком и Марией Мышь (ранее работала в Zenly), собрались и начали обдумывать создание своего приложения. К нам постепенно присоединились и другие специалисты, и мы продолжили формировать команду.

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

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

Какие основные функции и возможности предлагает Blink пользователям? Можем ли мы «бампнуться» по-старинке или отправить смайлик другу на весь экран?

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

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

Кроме того, в Blink реализована усовершенствованная система чекинов. При отметке пользователя в определенной локации, его друзьям тут же приходит push-уведомление. В Zenly данная функция работала менее эффективно, поэтому мы приняли решение о ее полной переработке.

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

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

Выбор стека связан с наличием специалистов на рынке, задачами и с высокими хайлоадом. В качестве основного языка веб-разработки мы выбрали компилируемый Golang, это современный стандарт для стартапов.

Помимо Golang, в стек входит ряд других ключевых инструментов. Для обработки потоков данных в режиме реального времени используется Apache Kafka, надежный и производительный брокер, с которым уже была знакома команда разработчиков и DevOps/SRE. Выбор Kafka обусловлен необходимостью надежной маршрутизации гигабайтов геопакетов в секунду.

В качестве основной базы данных выбран PostgreSQL, известный своей надежностью, производительностью и возможностью масштабироваться. Для кэширования данных используется Redis, а ClickHouse – для аналитики и обработки больших объемов данных, в том числе для пост-процессинга геокоординат. На данный момент объем данных в кластере приближается к 30 ТБ, и ClickHouse справляется с этой нагрузкой.

Для мобильных платформ мы используем Swift для iOS и Kotlin для Android.

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

Перейдем к конкретным фичам. Какие алгоритмы и методы используются для определения местоположения пользователей в Blink? Как вы обеспечиваете высокую точность геолокации?

В основе нашей работы лежит сбор данных с устройств пользователей и применение технологий геофенсинга. Хотя мы не изобретаем революционных решений, поскольку действуем в рамках закрытых операционных систем (iOS и Android), тщательно обрабатываем полученные данные, чтобы обеспечить их точность и надежность. Как происходит процесс?

Все начинается с получения координат от пользователя. Эти данные проходят несколько этапов проверки. Мы анализируем, не произошел ли резкий скачок местоположения, например, перемещение из России в Австралию за короткий промежуток времени. Фильтр Калмана помогает сглаживать координаты, удаляя аномальные значения и улучшая точность.

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

Мы также проверяем, находится ли пользователь в знакомом окружении, например, в домашней сети Wi-Fi. Если данные указывают на аномальное перемещение, корректируем местоположение.

Стоит отметить, что в последнее время мы все чаще сталкиваемся с проблемами навигационных систем и GPS-глушилок. Поэтому разработали целый ряд фильтров и механизмов для обеспечения высокой точности геолокации. Кроме того, работаем над улучшением клиентской части, оптимизируя работу приложения для минимального потребления заряда аккумулятора. Blink в среднем потребляет всего 1% заряда в сутки, что является отличным показателем. Мы потратили много времени на это улучшение, и теперь приложение практически не тратит заряд, хотя работает в фоновом режиме.

Как реализована система хранения и обработки больших объемов геоданных в приложении? Какие технологии и подходы задействованы?

Мы внедрили два ключевых решения: Apache Kafka и ClickHouse.

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

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

Стоит отметить, что объем накопленных нами данных уже превышает 30 терабайт. Это огромный массив информации, который требует применения современных Big Data решений, таких как Kafka и ClickHouse. Благодаря этому мы можем эффективно управлять и анализировать все эти данные, извлекая ценные инсайты и предоставляя полезный сервис нашим пользователям.

А что насчет самих пользователей? Как вы подходите к вопросам безопасности и конфиденциальности данных в Blink? Какие меры предприняты для защиты личной информации?

Мы применяем комплексный подход, сочетающий в себе передовые технологии шифрования и строгие меры контроля доступа.

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

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

Какие методы и инструменты применяются для анализа поведения пользователей, их передвижений и активности в приложении? Как вы используете эти данные для улучшения сервиса?

У нас есть два основных направления аналитики: клиентская и серверная.

Для клиентской аналитики мы используем как бесплатные, так и платные трекеры для отслеживания активности пользователей. Одним из ключевых инструментов является Amplitude, позволяющий собирать и анализировать данные о взаимодействии пользователей с приложением.

В части серверной аналитики:

• Все события, связанные с действиями пользователей, собираются и отправляются на наш сервер, где хранятся в базе данных ClickHouse. Это касается как клиентских, так и серверных событий.

• Собранные данные затем передаются в BI-системы, такие как Redash и Superset, для визуализации и построения дашбордов.

• Наши аналитики проверяют гипотезы и анализируют поведение пользователей. При этом данные обезличены, чтобы не нарушать конфиденциальность.

Один из последних кейсов:

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

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

С какими основными трудностями и вызовами вы сталкивались в процессе разработки и масштабирования Blink? Как вы их преодолевали?

Несмотря на стремительный рост, мы столкнулись с несколькими серьезными техническими вызовами:

1. Изначально, с нагрузкой в 10 тысяч онлайн-пользователей, наши го и легковесные горутины, а также оптимизированные веб-фреймворки справлялись с нагрузкой. Однако с ростом аудитории до 100 тысяч возникли проблемы на сетевом уровне, которые нашим инженерам удалось решить за счет переконфигурирования балансеров (nginx + sysctl).
2. Для хранения географических данных мы выбрали PostgreSQL, но со временем объем этих данных превысил 1 ТБ, что привело к существенному падению производительности. Попытки горизонтально масштабировать PostgreSQL оказались малоэффективными, и в итоге мы перешли на Clickhouse, который гораздо лучше справился с этой задачей. Перевод на Clickhouse занял около недели, но куда больше времени потребовалось на миграцию данных из PostgreSQL.
3. Недостаток мониторинга приводил к тому, что о проблемах мы узнавали уже тогда, когда они становились критическими и вызывали простои сервиса. Несколько бессонных ночей наглядно продемонстрировали важность использования инструментов вроде Grafana.

Несмотря на эти трудности, нам удалось преодолеть их и продолжить успешное развитие Blink. Опыт, полученный в ходе решения этих задач, стал для нас бесценным.

Каковы ваши планы на дальнейшее развитие приложения? Над какими новыми функциями и возможностями сейчас работаете?

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

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

Кроме того, мы разрабатываем собственную карту Blink Maps, которая будет интегрирована в приложение уже через несколько месяцев для некоторых устройств на Android. Это наша собственная 3D-карта, позволяющая решить технические ограничения, с которыми мы сталкиваемся при использовании платформенных карт, по типу Google Maps. Например, сможем более эффективно отображать больше пинов без задержек и сбоев. Карта будет регулярно обновляться, что позволит избегать проблем с устаревшей информацией. У нас свой движок, построенный на видеопроцессоре GPU, который на основе данных OpenStreetMap делает магию. Основу мы берем из OSM и поверх накручиваем все свои изменения.

Как вы считаете, какие тенденции и инновации будут определять развитие мобильных приложений для отслеживания местоположения в ближайшем будущем?

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

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

Однако, в свете этих тенденций, стоит учитывать, что Apple и Google, например, продолжают усложнять работу с геолокацией для сторонних разработчиков. Несмотря на наличие встроенных решений, таких как Find My Friends у Apple, ограничения и новые требования для работы с геоданными становятся все более жесткими. Это создает дополнительные вызовы для разработчиков, которые должны адаптироваться к меняющимся условиям и искать альтернативные пути стабильной работы своих приложений.

Что такое LeadHub и как эти встречи появились

Идея организовывать встречи для тимлидов Сравни появилась в 2021 году. Тогда технический директор, Дмитрий Парфенов, собрал лидеров команд, чтобы рассказать, как будет развиваться IT-направление. Изначально это была полностью односторонняя история — CTO говорит, а остальные слушают.

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

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

Помимо дилеммы «онлайн VS офлайн», нужно было определиться с частотностью мероприятий.

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

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

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

После каждой Leadhub-встречи проводится опрос среди тимлидов: что понравилось и что стоит улучшить. С помощью опроса получилось определить для себя требования к помещению. Так выяснили, что столы для работы в группах — must-have.

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

Как выстроили рабочие процессы внутри

В Сравни больше 300 IT-специалистов — 39 команд. Каждая сосредоточена на своей специализации: например, команда, в которой три бэкенд- и четыре фронтенд-разработчика, занимается только продуктом ОСАГО (продажа электронных полисов). Глобально компания придерживается принципов Agile, а разработка строится на базе микросервисной архитектуры.

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

В ИТ-команде Сравни нет строгой иерархии: компания отказалась от классической вертикальной модели подчинения.

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

Одной из центральных тем на недавней встрече в формате Leadhub был вопрос про внутренние коммуникациях.

Вот примеры сложностей в коммуникациях, которые обсуждали участники.

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

Мы не можем к каждому из 40 человек ходить в «личку» и задавать вопросы, поэтому ставим общие теги, но не все реагируют. Некоторые просто не обращают внимания, а до тех пор, пока не случится ответ, мы можем не понимать, есть или или нет проблема, о которой спрашиваем. Думая, что все в порядке, запускаем в работу, а оказывается, что есть ошибка. И сразу прилетает вопрос от тимлидов: а почему вы не сказали?

Задача 2. При возникновении общих вопросов команда сталкивается с низкой активностью в ответах на них, которая обычно составляет всего 5-10%. Встал вопрос: как увеличить количество оперативных откликов на эти запросы?

Задача 3. Внутри команд есть нюансы в управлении людьми и общении. Не все тимлиды следят за одними и теми же метриками и коммуницируют напрямую со всеми сотрудниками. Случается, что тимлид, который уже четвертый год руководит командой, ни разу не проводил one-to-one с ребятами из своего юнита, руководствуясь принципом «работают и работают».

Портрет идеального тимлида

В бэклоге типичного тимлида в Сравни разработка своими руками — это порядка 10-20% от всех задач. Остальное время — people-менеджмент и задачи на стыке разработки и бизнеса, а также исследование новых инструментов и проработка архитектурных решений. Чтобы команда достигала целей по метрикам, а внутри у ребят было все нормально с мотивацией, важно давать лидам навыки и инструменты для работы с командой по разным направлениям — от коммуникации до стратегического планирования.

Тимлид — Kubernetes среди людей.

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

Важной темой недавней Leadhub-встречи была матрица компетенций тимлида. Ребята попробовали сформировать требования к самим себе и соответствующим компетенциям. Тимлиды разбирали все скиллы, присущие «настоящему» лиду, и обосновывали свои идеи: что именно нужно развивать. Они собирались в команды, делали наброски компетенций, давали друг другу обратную связь, а затем выбирали из них наиболее важные.

Вот несколько инсайтов из этого обсуждения. Тимлид должен:

1. Быть молодцом
2. Уметь читать и писать
3. Завязывать шнурки

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

Итак, обязательный стартер-пак тимлида

• Тимлид должен обладать сильными техническими навыками. Может звучать как продолжение списка про «завязывать шнурки», но это действительно важная история. В задачи лида, как минимум, входит написание кода — коллега должен быть на уровне, чтобы он как руководитель мог помочь и брать на себя ответственность за архитектурные решения.
• Тимлид должен управлять командой. И отлично управлять. В его задачи входит: подсвечивать приоритеты от бизнеса, знать сильные и слабые стороны команды, управлять временем команды. А еще — уметь делегировать, потому что невозможно тащить все на своих плечах.
• Тимлид должен быть инициатором. Например, в одной команде долго не хотели писать юнит-тесты, но затем пришел тимлид, который сам взялся их писать и зарядил всю команду.
• Тимлид должен обладать хорошими навыками коммуникации. Внутри команды и вовне. Должен быть открытым и дружелюбным, чтобы к нему могли обратиться за помощью, и чтобы ему не «боялись» ее оказывать. Нужно проводить частые one-to-one: узнавать у сотрудников, как они себя чувствуют, не нагружают ли их задачами сверх возможностей — те самые «разговоры у кулера».
  

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

• Тимлид должен быть адаптивным. Это касается как софт-скиллов (например, находить компромиссы, воспринимать критику, расставлять приоритеты, признавать свои ошибки), так и хард-скиллов — обладать широким техническим кругозором, чтобы выбирать правильные технологии.
• Тимлид должен грамотно ставить задачи команде. История про бизнес-логику, выделение типовых и системных решений, декомпозицию, знание ресурсов и зависимостей (внутри и вовне команды), высокое погружение в проект и знание текущих трендов.
• Тимлид должен помнить о бизнесе. Любой компании важно регулярно получать прибыль и растить ее, поэтому тимлид должен держать это в голове, чтобы продукт на выходе был крутым с бизнесовой точки зрения. Здесь ключевыми являются метрики сервиса, контроль качества и финансовое планирование, а еще тимлид должен уметь выступать в роли заказчика.
• Тимлид должен быть самостоятельным. Организовывать встречи, выбирать технологии (например, изменить фреймворк), управлять процессами найма и увольнения. Тимлид не должен работать только в рамках бэклога и отчитываться перед фаундерами, а скорее должен воспринимать проект как свое детище и понимать точки развития.
• Тимлид должен погружаться во внешние коммуникации. Статьи, доклады, выступления. Это здорово, когда лидер может проявить инициативу и рассказать внутри компании или широкой аудитории о новом сервисе и выступить экспертом.

Это именно те навыки, над которыми тимлиды Сравни будут работать в дальнейшем. Что из этого получится — узнаем на следующей встрече в формате Leadhub.

Leadhub: про людей от людей

У нас в компании нет карго-культа. Процессы, которые придумываются в другой компании, закрывают ее боли и задачи, и нам они могут не подходить. Наша идея фикс — отталкиваться от людей и верить в них. Когда я пришел в Сравни, здесь было 50 человек. А сейчас нас 600. Компания сильно выросла, я видел, как меняются люди, эпохи. И сотрудники, которые могут драйвить процессы, заряжают на это других людей и мотивируют компанию расти дальше, поскольку мы видим результат. Поэтому мы делаем акцент именно на людях, и, конечно, на тимлидах, от которых зависят не всегда большие, но крайне важные улучшения для команд.

Если хотите побольше узнать о команде Сравни и их корпоративной культуре, можно почитать телеграм-канал компании и посмотреть YouTube.

— Расскажите о вашем стартапе My Voice и идее, которая легла в его основу. Что вдохновило вас на создание этого продукта?

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

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

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

Дисциплину защитили, затем подали свою идею на грант «Умник» от Фонда содействия инновациям. Прошли заочный этап, а затем защитили проект очно в Ханты-Мансийске. Это был важный момент, который позволил нам в течение двух лет работать над проектом в рамках гранта.

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

— Каково назначение вашего устройства и как оно работает?

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

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

Затем синтезатор преобразует слова в звуковую речь. Таким образом, я, как собеседник, точно пойму, что мне показывают.

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

Интересно, что всё это происходит в реальном времени, обеспечивая комфортный диалог.

— Расскажите подробнее о вашем MVP. Какие ключевые функции и возможности устройство уже имеет?

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

Сейчас наша нейронная сеть, лежащая в основе распознавания, достигла впечатляющей точности в 99,5% для букв дактильного алфавита. Она не только распознает жесты, но и автоматически собирает их в слова, исправляя ошибки, и преобразует в синтезированную речь. Это ключевая функция нашего MVP.

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

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

— Каковы основные технические характеристики MVP, и каким образом продукт взаимодействует с пользователем? Какие сенсоры или датчики используются в устройстве?

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

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

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

— Какие данные вы использовали для обучения нейросетевой модели? Была ли нехватка данных, и если да, то как вы решали проблему?

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

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

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

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

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

— Как вы тестировали и оценивали работу MVP? Какова точность и эффективность перевода с помощью вашей нейросети на данный момент?

Мы в первую очередь оценивали метрики самостоятельно в ходе разработки, поскольку как инженеры должны были убедиться, что все работает правильно. Наши показатели точности составили 99,5%.

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

Таким образом, мы использовали как собственное тестирование, так и привлекали внешних экспертов, чтобы убедиться в высоком качестве технологии.

— Как вы производили тестирование MVP с участием пользователей из целевой аудитории? Какие важные инсайты или обратную связь вы получили в ходе тестирования?

Я могу сказать, что мы действительно столкнулись с серьезными техническими сложностями при разработке системы. Изначально ориентировались на классический жестовый язык (где задействованы две руки, наклоны и мимика), предполагая, что это будет проще распознать. Однако, как выяснилось в ходе работы с фокус-группой, жестовый язык оказался весьма диалектным: одни и те же жесты могут иметь разное значение в разных регионах или даже семьях. Это не позволяет нам собрать некий эталонный набор, а вынуждает либо переучивать пользователей, либо мириться с менее точным распознаванием.

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

— Какие критерии вы использовали для оценки готовности MVP к тестированию и выходу на рынок? Как определили, что продукт достиг минимально необходимого функционала?

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

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

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

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

— Расскажите о вашей команде разработчиков. Какие компетенции и экспертизу вы искали при формировании команды для создания MVP?

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

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

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

— Что вы видите в качестве основных преимуществ вашего продукта перед конкурентами?

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

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

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

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

— Каковы ваши дальнейшие планы по развитию стартапа My Voice? Расскажите о вашем видении будущего этого проекта.

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

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

В прошлой статье разбирали, как тестировщикам проходить собеседования. В этом интервью вместе с платформой развития карьеры в IT через менторство Solvery.io, обсудим опыт Анны Третьяковой — QA-лида в Яндексе. Анна помогает обучаться тестированию с нуля, переквалифицироваться в QA Lead и строить отдел тестирования.

Анна прошла путь от стартапа до работы в крупной компании, поэтому поделится инсайтами о том, как подготовиться к собеседованиям, какие технологии и навыки важны в текущем рынке, а также как справляться с профессиональными вызовами и выгоранием на работе.

Расскажи о самом интересном проекте, в котором ты участвовала

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

Есть ли в твоей карьере момент, который изменил твою жизнь?

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

Какие новые для тебя вопросы или задания встречались на собеседованиях?

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

Бывают, конечно, и скучноватые собеседования, но обычно из каждого можно вынести что-то полезное, например, когда задаёшь ответные уточняющие вопросы, а интервьюер сам начинает путаться :)

Как лучше всего структурировать свое портфолио, чтобы заинтересовать крупные компании, в том числе Яндекс?

Про умения и опыт стоит рассказать. Я за честность.

Если не было опыта, не стоит о нем и говорить, все равно станет понятно на собеседовании всё. Достаточно постараться детально и максимально релевантно описать задачи под опыт тестирования, если это возможно.

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

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

Как организована работа в твоей команде? Какие практики помогают поддерживать эффективное решение задач?

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

Как вы решаете спорные моменты или несогласия внутри команды?

Для этого есть ретро, где можно выразить свои мысли, если не согласны, и обсудить их. Иногда вопросы обсуждаются на дейлике, формируются договоренности и фиксируются в постмитах или документации процесса.

Какие новые технологии или инструменты ты добавила в свою работу за последние годы?

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

Можешь рассказать о самых интересных рабочих задачах, с которыми ты сталкивалась в Яндексе? Как решила и какой совет можешь дать другим?

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

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

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

В Драйве нужно было тестировать физические модули (тачки). Когда смотришь не только ПО, а переходишь в оффлайн тест — тестирование открывается с новой стороны. Да, принцип везде одинаковый, но интереса больше.

Какие навыки и технологии стали наиболее востребованными для джунов в последние годы?

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

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

Как ты думаешь, какие изменения нас ждут на рынке труда для IT-специалистов в ближайшие пять лет?

Когда-нибудь AI точно будет в рутинной работе, но пока сложно представить, как именно это будет происходить. Можно только фантазировать об идеальном мире.

Какую роль играют наставники в развитии карьеры джунов? Как найти хорошего ментора?

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

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

Как ты считаешь, насколько важно для джунов участвовать в хакатонах и других соревнованиях?

Никогда не участвовала, хотела, но до сих пор никак не дойду. На них можно найти полезные контакты, но в обучении это вряд ли поможет.

Какие книги, курсы или ресурсы дали наибольшее влияние на твое профессиональное развитие?

Советую книги от Куликова и Савина. В целом, обучение других людей очень помогает обучиться и самому.

Как ты справляешься с профессиональным выгоранием? Можешь поделиться своими методами?

Сложная тема, очень сложная. Вот что помогает мне:

1. Оптимизация работы и рутины.
2. Разноплановые задачи и рост.
   
3. Спорт и хобби, тут же work/life balance. Не забывать, что не одной работой мы живем.
   
4. Путешествия, в том числе совмещая с работой. Смена обстановки лично для меня положительно влияет на продуктивность.
   
5. Стараться «не уставать» свой мозг. Например, делать пятиминутки: суставная гимнастика, упражнения для глаз, побрынчать на гитаре, почесать котика за ушком. Нужно переключаться ненадолго. Своего рода перекуры.
   

Как ты считаешь, какие ошибки могут быть полезными для новичков и почему?

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

Что ты считаешь самым важным фактором для тестировщика в IT?

Уметь думать. Уметь самообучаться. Не бояться непонятных задач.

Опиши кратко максимально общий портрет топового QA для топовых компаний, с учетом всего того, что обсудили на подкасте и в статье?

• Быть активным, уметь самостоятельно искать задачи

• Быть честным и в резюме, и на работе с коллегами, уметь признавать ошибки

• Ошибаться, но делать все возможное, чтобы предупредить ошибки, выносить опыт и больше их не допускать

• Не жить только работой, тут как и везде. Прогулки, спорт, хобби. Работа должна быть только сферой, а не целым миром. Иначе быстрое выгорание обеспечено

Кстати, вышел самый полезный подкаст его нужно смотреть и смешивать в плане информации со статьей — Как НЕ Завалить Собеседование в Яндекс: советы QA Team Lead Яндекса | Подкаст «Так можно было». Лайки, шеры и подписки на канал — плюс в карму!

Из 100 кандидатов, претендующих на позицию тестировщика в топ-компании только 5 доходят до финала и получают оффер. Более 60% кандидатов испытывают трудности на технических собеседованиях и интервью с HR. Это значит, что нужно серьезно подготовиться и понимать все этапы найма.

Вместе с сервисом по подбору менторов Solvery и QA-наставниками мы собрали самое объемное руководство для тестировщиков с практическими советами и рекомендациями от экспертов, чтобы они смогли пройти собеседования в топ-компании России.

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

Основные этапы прохождения собеседования

Больше всего востребованы QA-специалисты уровня Middle и Senior, особенно с опытом написания автотестов. Важными навыками остаются понимание работы CI/CD-систем, умение работать с Docker и базами данных, а также хорошие коммуникативные способности.

Практически (и теоретически) можно выделить шесть стандартных этапов:

Этап 1. Подготовительный

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

Ключевые пункты в резюме любого тестировщика, чтобы зацепить внимание HR

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

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

Обновите свои знания в языках программирования, фреймворках и инструментах, включая Docker, CI/CD, SQL или NoSQL базы данных, Linux.

Этап 2. Поиск вакансий

Образовательная платформа GeekBrains в 2021 году провела ресерч, чтобы выяснить, где айтишники чаще всего находят вакансии или новые проекты. Вот, что у них получилось: 50% респондентов используют HeadHunter для поиска работы. 47% подписаны на отраслевые Telegram-каналы. 37% ищут работу через нетворкинг (друзья и знакомые). 27% используют LinkedIn (заблокирован в России). 16% используют Facebook. 13% используют Habr Карьера.

Генеральный директор GeekBrains Александр Волчек отметил, что тренд останется прежним, пока дефицит опытных IT-специалистов не сократится: junior-разработчики будут искать вакансии на job-сайтах, а опытных специалистов будут перехватывать раньше, чем они дойдут до специализированных сервисов.

Этап 3. Первичный скрининг

На этом этапе происходит первый контакт с HR-специалистами, который проходит в два последовательных этапа или только один из них:

1. Чат или телефонное интервью — обсуждаются мотивация кандидата, его опыт и базовые знания по теории тестирования.
2. Тесты на знание теории и языков программирования — HR просят выполнить небольшие тесты для проверки базовых навыков.

Как лучше всего подготовиться к первичному скринингу

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

На первом этапе собеседования HR задаёт несколько технических вопросов. Это могут быть простые вопросы по основным технологиям. Если вы с ними работали, ответить будет несложно. Однако лучше заранее изучить все требования вакансии и освежить свои знания по тем пунктам, в которых не уверены.

Будьте уверены в себе и открыты. Позитивное впечатление иногда помогает компенсировать отсутствие знаний по некоторым технологиям.

Этап 4. Техническое интервью

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

1. Решение кейсов и практических задач — это могут быть задачи по объектно-ориентированному программированию, SQL, Docker, Linux и CI/CD.
2. Написание кода (лайвкодинг) — демонстрация логов и объяснение своего подхода к решению задач.

Типичные технические вопросы, которые задают на интервью

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

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

Какие задачи по автоматизации тестирования можно ждать на интервью

По поводу задач — предлагают интеграцию тестов в CI/CD pipeline, а также решение алгоритмических задач, проверяющих навыки логического мышления и умение эффективно работать с кодом.

Ресурсы и платформы для подготовки к техническим интервью

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

• LeetCode/HackerRank/Codewars: предлагают много задач разного уровня сложности, включая алгоритмические задачи, которые могут быть полезны для подготовки.
• Test Automation University: платформа с бесплатными курсами по автоматизации тестирования от экспертов.
• YouTube: на YouTube вы можете найти много видео с разбором тестовых интервью. Они помогут вам лучше понять, какие вопросы могут вас ожидать, как нужно и не нужно на них отвечать.
• https://sql-ex.ru/: тренажер для практики SQL запросов.
• Треугольники Майерса: популярная задача с собеседований

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

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

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

Этап 5. Интервью по soft skills и встреча с менеджером

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

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

Топ-7 мягких навыков, или почему нам кажется, что софты менее важные, чем харды

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

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

Вместе с менторами Solvery собрали список мягких навыков для QA-специалистов:

1. ​​Коммуникация и межличностные навыки: способность ясно излагать результаты тестирования и работать в команде.
2. Аналитическое мышление и решение проблем: умение критически мыслить и находить решения для сложных задач.
3. Внимание к деталям и точность: важно быть внимательным и аккуратным.
4. Адаптивность и гибкость: быстрая адаптация к изменениям в проектах и технологиях.
5. Креативное мышление и инновации: генерация новых идей и подходов в тестировании.
6. Управление временем и расстановка приоритетов: эффективное использование времени для достижения целей.
7. Эмпатия и ориентированность на пользователя: понимание нужд и проблем пользователей.

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

Этап 6. Долгожданный оффер (или нет)

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

Если вы получили оффер, советуем познакомиться с прогнозами по зарплатам в IT-сфере на 2024 год. В 2023 году зарплаты тестировщиков выросли на 17% по сравнению с предыдущим годом. Средняя зарплата тестировщика увеличилась с 107,000 рублей в 2022 году до 125,000 рублей в 2023 году.

На начало 2024 года, по данным исследования QA Studio, спрос на услуги тестировщиков увеличился практически на 60%. Таким образом, сегодня зарплата тестировщика в России варьируется от 43,000 рублей в месяц для джунов до 265,000 рублей для лид-тестировщиков.

Что делать, если вы не получили оффер:

1. Запросите обратную связь: попросите у работодателя фидбэк о вашем собеседовании. Это поможет вам понять, какие аспекты необходимо улучшить.
2. Проанализируйте свои ошибки: проанализируйте, какие вопросы вызвали у вас затруднения, и поработайте над этими областями.
3. Продолжайте искать: не останавливайтесь на достигнутом. Используйте полученный опыт для улучшения своих навыков и продолжайте искать новые возможности.
4. Подготовьтесь к следующим собеседованиям: используйте полученные знания и обратную связь для подготовки к будущим интервью. Пройдите дополнительные курсы или практикуйте технические задачи, чтобы улучшить свои навыки.

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

Советы для начинающих QA-специалистов

Мы обратились к Татьяне Гондаревой, QA Engineer из Самоката и ментору Solvery, чтобы узнать, какие базовые знания и навыки необходимы для прохождения собеседования, как лучше подготовить резюме и портфолио, а также как справиться с техническими вопросами.

Поехали, короткий блиц!

Какие задания могут дать на тест-дизайн для кандидата без опыта?

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

Какие вопросы могут задать, чтобы проверить понимание технологий?

— Часто проверяют знание технологий, таких как веб, REST API, микросервисная архитектура. Например, классический вопрос: "Вы заходите на страницу в браузере, вводите логин/пароль и нажимаете 'отправить' — что происходит дальше?"

Насколько важно задавать вопросы самому кандидату?

— Очень важно, чтобы кандидат не боялся задавать вопросы, уточнять и разбираться в непонятных вещах. Это показывает вашу проактивность и желание разобраться в деталях.

Как выделить свои достижения при малом количестве опыта?

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

А что делать, если коммерческого опыта нет совсем?

— Если коммерческого опыта пока нет, можно “добрать” его с помощью стажировок, участия в крауд-тестинговых проектах, таких как проект “Хомячки”, или создать свой пет-проект.

Как лучше оформить портфолио?

— Оформляйте портфолио структурно и тезисно. Если у вас есть проекты на GitHub, добавьте ссылку — это будет большим плюсом!

Мы собрали все советы от QA-экспертов, которые помогут вам пройти собеседование в топ-компании России. Если у вас остались вопросы или вы хотите получить дополнительные навыки — записывайтесь на встречу с одним из менторов на площадке Solvery.

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

Расскажите о себе и своём пути

Я родом из Челябинской области. Окончил Челябинский государственный университет, а затем Стокгольмскую Школу Экономики (ЕМВА).

Вся карьера после университета была посвящена телеком-отрасли. Сначала запускал бренд Теле2 в России, потом долгое время работал в МТС на Урале в должности Коммерческого Директора Макро-региона.

В 2014 году ушёл из корпоративных стен в предпринимательство. Строили с женой семейный бизнес. Создали международную кондитерскую школу, а затем кондитерский бутик, который впоследствии перерос в полноценное пищевое производство.

Сейчас наша компания работает на Урале. Мы производим десерты и японскую еду для b2b-клиентов. Развиваем производственный франчайзинг в сегменте ультрафреш-продукции.

Оборот бизнеса:

2021 — 20 млн руб

2022 — 100 млн руб

2023 — 500 млн руб

Цель на 2024 — 1 млрд руб

Что случилось, почему решили заняться предпринимательством

В какой-то момент, находясь внутри большой корпорации, я понял, что я не хочу работать в системе, где кто-то извне определяет правила. Я понял, что я хочу сам создавать систему и задавать правила, строить команду и делать продукт.

Конечно, я понял это не сразу. Сначала не получалось сфокусироваться на выборе сферы компании. У меня был рекламный бизнес — я издавал журнал, — была сеть салонов сотовой связи, а в итоге сейчас бизнес по производству пищевой продукции.

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

У меня одна стратегия — люди и финансовый план.

Если одного из этих факторов не будет, все может сломаться в пути. Важно считать деньги, ставить цели и контролировать исполнение.

Какие значимые решения привели к росту бизнеса

Думаю, одним из успешных бизнес решений было принять тот факт, что я плохой операционный менеджер, и нанять людей.

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

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

Как понимаете, что бизнесу нужно расширяться, как определить застой

Рынок очень динамичен. Главное, на мой взгляд, не бояться экспериментов, пробовать разные гипотезы и чётко отрабатывать все клиентские возражения, которые нацелены на улучшение продукта. Это позволяет оценить потенциал рынка в момент запуска идеи.

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

Как управляете рисками в бизнесе

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

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

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

Третий фактор — это прогнозирование. Важно научить людей смотреть вперед, а не назад. Все по привычке анализируют прошлое и ковыряются в том, что уже прошло. Первое, что мы сделали в бизнесе — внедрили прогноз выполнения задач месяца к 25 числу. Поэтому 25 июня мы уже знаем результат с погрешностью 5-7%.

Какую роль в успехе играет диверсификация продуктов или услуг компании

О! Это критическая точка — прямо в цель. Мы стартовали в 2022 году с одним клиентом и росли с ним вместе. Но в 2024 году в мае у клиента возникли проблемы, и мы на месяц остановили 100% нашего производства. Потери чудовищные, стресс у команды, кассовый разрыв.

Поэтому диверсификация портфеля (клиентов, продуктов, услуг) — это must have для всех предпринимателей.

Какие бизнес-инструменты и технологии считаете полезными для управления и роста бизнеса

Однозначно есть несколько вещей, которые необходимы:

• Планирование. Отсутствие финансовых показателей приводит к чувству неопределённости у команды и непониманию собственника, что ждёт его впереди.
• Мотивация. Люди должны понимать, что они делают и что будет дальше. Тут, конечно, не последнюю роль будет играть лояльность персонала.
  
• Метрики. С недавних пор я верю в метрику North Star для всей команды. Это показатель, который позволяет объединять людей и синхронизировать личные цели и цели бизнеса.
  
• Управление оборотным капиталом. Практически все проблемы в бизнесе — от непонимания структуры оборотного капитала и cash flow.
  

Как используете современные технологии, чтобы улучшить стратегию

Пока элементы современных технологий в области ИИ для нашего бизнеса не являются «коробочными», поэтому сейчас нам приходится только примерять новые инструменты.

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

Как мотивируете себя и остаётесь сосредоточенным на достижении бизнес-целей

Наверное, это моя страсть к цифрам и планам. Я не могу без четкой стратегии и аналитики.

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

Самомотивация — это сложный кейс :)). Материальные аспекты перестали зажигать, они стали скорее базовыми потребностями.

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

Какие книги, курсы и подкасты нужно изучить начиющим предпринимателям

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

Мне помогает общение с моим ментором и другими коллегами в клубе. Это наполняет новыми идеями и практиками.

Подкасты не слушаю — совсем не мой формат. Книги чаще художественные. Обожаю фильмы на тему квантовой физики :)

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

Я уже не помню, сколько я прошёл обучений и курсов. Образование — моя страсть.

Вообще считаю, что самый главный ограничитель роста — это остановленное саморазвитие! Поэтому учиться всегда и везде!

Нужны ли профессиональные консультанты в стратегиях

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

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

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

Какие советы бы дали начинающим предпринимателям и тем, кто хочет удвоить свои доходы

Путь, который вы выбрали — очень интересный, но сложный.

Самое важное — команда, продукт и продажи.

Идите продавать даже сырой продукт. Если он будет востребован, то доделанный до ума будет востребован в разы сильнее.

Не увлекайтесь «улучшайзингом» продукта. Выбирайте две-три ключевые фичи, которые умеете делать лучше всего, остальное в топку. Иначе в процессе постоянного усовершенствования получите расфокусировку.

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

Пока не получили подтверждение своих гипотез на одном рынке, нет смысла бежать в увеличение географии. Затраты, контроль и инвестиции. Нужно быть очень уверенным в том, что всё посчитали.

Мы открыли один филиал в 2000 км от основного офиса. В итоге структура получилась слабо управляемой, и прибыли мы там так и не увидели.

Про финпланирование я уже говорил выше. Сделайте хотя бы одностраничный P&L, чтобы примерно посчитать свою гипотезу.

Что касается стратегии, то, получив свой опыт, я могу сказать, что сформировать стратегию на старте не всегда получится. На старте займитесь командой и продажами, а когда встанете на устойчивый финансовый поток, можно начинать писать стратегию.

Какие изменения в бизнес-среде и экономике предсказываете в ближайшие годы

Это дело крупных бизнес-аналитиков. Задача бизнеса — быть гибкими, чтобы уметь адаптироваться к изменениям.

Единственное, что скажу — мир ускоряется, и изменений будет много.

Как, по вашему мнению, изменятся подходы к управлению бизнесом в будущем

Думаю, что в России будет больше прозрачности в расчётах с налоговыми органами. Мы страна, где налоги на бизнес далеко не самые высокие.

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

Какие основные ошибки, по вашему мнению, допускают люди в управлении своими бизнесами

1. Люди не продают.

2. Долго пилят продукт.

3. Не считают деньги.

4. Боятся строить прогнозы про свой бизнес.

5. Не хотят нанимать людей.

В целом никаких других ошибок нет. Всё крутится вокруг этих моментов.

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

Верьте в себя и не опускайте руки, даже если не получилось в тысячный раз.

Сегодня у нас в гостях Евгений Антонов — старший технический менеджер проектов в Yandex Infrastructure, IT-консультант, автор телеграм-канала «Тимлид Очевидность» и ведущий подкастов «Кода кода» и «Три тимлида заходят в бар».

Как прошла неделя? Над чем работаешь в последнее время?

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

Из не рутинного:

• У нас в службе происходит реструктуризация, и я помогаю готовить планы, как пройти через неё с меньшим количеством боли и вреда для людей и для производительности труда. А в идеале даже ещё получить удовольствие и профит.
  
• Моя команда – инфраструктурная, и занимается она работой с опенсорсом, поэтому я был озабочен новыми потребностями некоторых команд по интеграции внутреннего репозитория и опенсорса.
  
• Подготовил контент для двух докладов: первый – «Должен ли тимлид писать код?» Второй – «Как тимлиду найти синергию с рекрутером».
  
• Делал посильный вклад в ИТ-сообщество. Помогал в организации митапа и конференции, писал со своими товарищами новые выпуски подкастов для тимлидов.

Какая из последних IT новостей запомнилась тебе больше всего? Почему?

Мне было интересно прочитать про то, что Microsoft закрыл свой проект Natick по расположению дата-центра под водой.

Интересно ещё и то, что он был более отказоустойчивым в сравнении с наземными. Но закрыли не со словами «не работает, отменяем», а с чем-то, показавшимся мне более обтекаемым (каламбур, фьють-ха): «While we don’t currently have data centers in the water, we will continue to use Project Natick as a research platform to explore, test, and validate new concepts around data center reliability and sustainability, for example with liquid immersion.»

С какой сложной задачей ты столкнулся в последнее время и как решил?

Как менеджер, я сталкивался с двумя типами сложных задач:

1. Кросскомандные проекты, которые нужно координировать и доводить до нужного результата. Тут простой совет – контроль и дисциплина.
2. Очень много задач в целом. Тут простой совет – приоритизация и делегирование части задач.

Что слушал на неделе? Поделись треками или подкастами

Я люблю слушать много аудио-подкастов (в подписках около 30 разных). Вот тут я делился скрином и списком в телеграме.

Из музыки либо какой-то лаунж для сосредоточенной работы, либо что-то более динамичное типа Billy Idol, 69 Eyes, Black Sabbath, Ozzy Osbourne.

Что советуешь почитать?

Сейчас читаю книгу Анны Старобинец «Лисьи броды». Эдакая мистика, фэнтези, триллер. Очень нравится. А на букмейте ещё и круто озвученная аудиокнига имеется.

Недавно закончил читать «Замок» Кафки. Это было очень странно и нудно, но одновременно любопытно и необычно.

Из нон-фикшена читаю «Искусство спора» Поварнина. Ранее у него читал книгу про то, как читать книги. Развивающее и структурирующее чтиво, рекомендую.

А еще люблю рекомендовать «Дом, в котором», «Ложная слепота», «Рифтеры» и «Задача трех тел».

Окей, а что посмотрел и можешь порекомендовать?

Только закончил смотреть сериал «Олененок». Очень напряжённый и драматичный сериал с довольно интересной концовкой.

Недавно еще посмотрел «Идеальные дни». Совершенно чудесный, умиротворяющий и мотивирующий к созерцанию жизни фильм.

«Все страхи Бо» тоже понравился, особенно сразу после прочтения «Замка» Кафки. Есть в этом какая-то криповая синергия.

Твой топ-3 приложения

Telegram – очень много общения там + мой телеграм-канал.

Todoist – невероятно нужная штука, которая помогает держать много контекстов, не терять кучу дел и дисциплинированно их выполнять.

Букмейт – люблю читать. А еще там есть удобная функция бесшовного переключения между текстом и аудио.

Планы на выходные: как планируешь проводить и что посоветуешь нам?

В субботу я обязательно отдыхаю и не делаю ничего, связанного с работой, или общественной деятельностью про IT (канал, подкасты, доклады, конференции и митапы). Ходим с женой на завтрак в кофейню, гуляем по городу, разговариваем. Куда-то можем сходить (в прошлую субботу ходили на флоатинг), что-то посмотреть, во что-то на компьютере поиграть вместе и т. д.

Воскресенье вбирает в себя всякие заботы по домашним делам и часть про доклады, подкасты и прочую подобную деятельность.

Как итог — любимый IT-мем недели!

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

Следите за новыми выпусками «Ретроперспективы недели» на Tproger — будет ещё больше интересного! Если у вас есть идеи, кого бы вы хотели видеть в следующем выпуске, дайте нам знать!

Мы поговорили с Александром Дворниковым о том, чем он занимался в лондонском Facebook и почему решил вернуться и присоединиться к Яндексу.

— Александр, расскажите, как вы оказались в Лондоне?

— Мне всегда было интересно узнать, каково это — жить и работать в другой стране. И вот в 2017 году появилась возможность переехать в США или Великобританию. В Штаты я проиграл визовую лотерею H-1B, поэтому мы с супругой выбрали Лондон. После успешного прохождения всех этапов интервью меня приняли в Facebook, где я продолжил заниматься мобильной разработкой. Если до этого я специализировался на iOS, то на новом месте начал работать над кроссплатформенным ядром React Native.

Переезжали с супругой, плюс кошка. Перед переездом нужно сдать тест IELTS по английскому языку, у меня подготовка заняла 1–2 месяца. Я сдал его до того, как прошёл собеседование — заранее рассматривал возможность переезда и решил немного облегчить себе задачу. Если бы я так не поступил, процесс мог бы затянуться.

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

— И вот вы оказались в Facebook и начали вливаться в рабочий процесс. Что можете рассказать про условия работы и атмосферу в компании?

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

В Facebook сильно развита автономность: менеджер принимает участие в твоей работе, но скорее как консультант, а не как человек, который непосредственно ставит тебе цели и задачи. Индивидуальные цели достаточно гибкие — ты можешь поставить себе в начале одну цель, а дальше, уже по ходу полугодия, прийти к чему-то, возможно, совершенно другому, но не менее важному. Главное — измеримый результат.

Я попал в очень сильную команду — собрался коллектив разработчиков с разносторонним опытом. Кто-то до этого работал в Apple над ядром iOS, кто-то получил PhD, проводя исследования в области компиляторов. Я многому научился у коллег, за что им очень благодарен.

— А можете поподробнее рассказать про то, чему вы научились, работая в Facebook?

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

Эта особенность проявляется уже с первых дней. Для нового сотрудника работа в Facebook начинается с шестинедельного интенсива, цель которого — познакомить тебя с инфраструктурой компании и дать понять, как всё устроено внутри. Ты можешь прийти на должность разработчика, дата-инженера или менеджера, но в ходе интенсива тебе, возможно, придётся решать задачи, не связанные с твоей специализацией напрямую. Это здорово расширяет горизонты. Бывает, что после этих шести недель человек решает дальше работать в совершенно новой для него области — просто потому, что она его заинтересовала.

Главное тут — желание и умение быстро учиться. Более того, горизонтальные перемещения внутри компании всячески поощряются. Абсолютно нормально, когда по истечении четырёх лет у сотрудника за плечами есть опыт работы как над продуктами, так и над инфраструктурными задачами в бэкенде, вебе, на мобильных.

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

— Судя по тому, что вы рассказываете, вам нравилось работать в Facebook. Почему тогда вы приняли решение уехать из Лондона?

— Лондон — интересный город, но через пару лет мы стали от него уставать. Это огромный, шумный и густонаселённый мегаполис, в котором мы с супругой чувствовали себя неуютно. Начали перебирать варианты: переехать в Штаты в рамках Facebook, посмотреть что-то ещё в Европе или вернуться в Россию. Я уже работал в Яндексе в 2013 году, ещё до переезда в Лондон, мне там нравилось, поэтому этот вариант был одним из очевидных.

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

— Какие конкретно задачи вы решаете в Яндекс.Почте?

— Почтовый сервис — это достаточно понятный инструмент, к которому все давно привыкли. Но к моменту моего возвращения в Яндекс.Почте собрался дружный и сильный коллектив с интересными и смелыми идеями, как сделать продукт лучше.

Задач очень много. Есть задачи, традиционные для мобильных: например, ускорение перформанса и работа с пушами. Есть более специфичные штуки, которые связаны с технологиями Яндекса. К примеру, в Почте появился переводчик, совсем недавно добавили поддержку SpeechKit’а и технологий голосового ввода, прямо сейчас коллеги занимаются автоматизацией тестирования с применением ИИ и нечётких алгоритмов. Результаты необходимо посчитать и проверить, насколько подтвердилась та или иная гипотеза. Для этого мы используем A/B тестирование и мощные инструменты для работы с аналитикой. По сути, каждый разработчик в команде — немного data scientist.

Что касается меня, то я продолжаю заниматься тем, что меня так увлекло в Facebook, — инфраструктурными задачами на iOS и Android. Прямо сейчас мы с коллегами работаем над объединением логики ядра синхронизации на мобильных. Понятно, что нужно учесть особенности каждой из платформ. Задача усложняется тем, что необходимо поддержать все последние оптимизации, связанные с ускорением производительности приложения. А ещё не забыть про работу с офлайн-операциями, которые являются одной из ключевых особенностей мобильной почты. Для кроссплатформенности был предложен новый подход, который уже применяется для решения других задач, например в области автоматизации тестирования. Мы рассказывали о самой технологии на одном из предыдущих докладов Mobile Party и планируем в дальнейшем рассказать ещё.

Вы говорили, что в 2013 году, ещё до релокации в Лондон, уже работали в Яндексе. Как вам кажется, компания сильно изменилась с тех пор?

Безусловно, за эти годы компания очень выросла. Это касается многих вещей. Когда я присоединился к Яндексу в 2013 году, команда мобильной разработки была совсем небольшой. Сейчас мобильные технологии — одно из ключевых направлений для компании. Огромное количество людей из офисов Яндекса в разных частях России работают над несколькими десятками приложений, которые составляют единую экосистему. Подобному росту способствовало появление и развитие мощных инструментов внутренней инфраструктуры, аналитики, коммуникации и тестирования. Они ускоряют процесс разработки, делают его удобнее и открывают возможности для новых экспериментов.

Изменились и внутренние процессы. Сейчас новые разработчики в поисковом портале Яндекса проходят через Буткемп — интенсив, во многом схожий с тем, который внедрён в Facebook. Ребята в течение восьми недель пробуют себя в разных командах и узнают компанию изнутри, а потом выбирают, в каком коллективе и над какими задачами им хотелось бы работать в дальнейшем. Это отличная возможность расширить кругозор и познакомиться с разными людьми и подходами.

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

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

— Я успел посмотреть, как устроен процесс найма разработчиков в обеих компаниях и снаружи, и внутри. На мой взгляд, у собеседований в Яндекс и Facebook очень много общего. Процесс начинается с общения с сотрудником HR. За ним следует одно или несколько скрининг-интервью по Skype с написанием кода. Если всё прошло хорошо, то кандидату предлагают onsite-интервью, которое обычно состоит из 4–5 секций. На секциях обязательно будут как алгоритмические, так и архитектурные задачи.

Есть и небольшие отличия. У мобильного разработчика на собеседовании в Яндексе обязательно будет отдельная секция по платформе. На ней проверяют, насколько глубоко человек понимает язык, фреймворки и особенности iOS и Android. В Facebook уделяют внимание скорее общим познаниям в области Computer Science, но при этом есть отдельная секция Cultural Fit Interview — на ней задают вопросы о предыдущем опыте и роли в команде. В целом собеседования в обеих компаниях устроены очень похоже. Главный совет — хорошо готовиться и усердно тренировать решение алгоритмических задач.

Если сравнивать работу в обеих компаниях, есть ли что-то такое в Яндексе, чего вам раньше не хватало в Facebook?

Вернувшись в Яндекс, я осознал, насколько для меня, оказывается, важно, чтобы вся команда и коллеги находились рядом. В Facebook я участвовал в проекте, над которым мы работали совместно со смежными командами в США. Разница во времени между нами была 8 часов. Это создавало определённые сложности, связанные как с асинхронной работой и коммуникацией, так и с work-life balance. Наиболее тёплые воспоминания у меня связаны с теми моментами, когда мы приезжали друг к другу в гости в командировку. Трудясь бок о бок, удавалось в короткие сроки добиться гораздо большего.

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

Про старт карьеры в CG в 90-е

Я на самом деле поздно пришёл в компьютерную графику, в 30 лет. Это был 1996 год. Сначала я работал в традиционном IT — писал базы данных, работал в технической поддержке компании Steepler. Там был и программистом, и всеми, кем угодно. Но у компании Steepler было специальное подразделение, оно называлось Steepler Graphics Group. Они продавали Silicon Graphics — это были какие-то космические станции, всё было какое-то инопланетное. Я как-то раз к ним зашёл и подумал: «Ничего себе, вот это жизнь, вот это круто!». Так случилось, что в 1996 году они позвали меня на работу. Я стал заниматься техническим маркетингом — показывал Power Animator, потом Maya и другие безумные софты людям. Делал так, чтобы они захотели их купить. Это были и продажи, и маркетинг, и технические демо, и всё остальное.

Про интерес к компьютерной графике

В общем-то в графику меня тянуло и раньше, ещё когда я в университете работал, мне нравилось визуализировать разные данные. Например, я писал траектории поражающих элементов на OpenGL. Интерес к отрасли возник у меня на фоне интереса к визуализации данных. Мне году в 1991 попалась на глаза книжка «Когнитивная графика». Там было как раз о том, что есть циферки, и надо сделать так, чтобы по этим циферкам человек получал какие-то полезные знания. Для этого предлагалось нарисовать смешные графики — их я и рисовал. А потом, в 1996 году, когда я пришёл в CG, стало можно рисовать уже всякие глупости, не только графики.

Про физиков и лириков

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

Про секрет успеха CG Event

Я делаю ивент интуитивно. Секрет такой: заниматься тем, что тебе интересно.

Мы собираемся уже 13 лет — будет 29-й ивент. Да, это карма: мне когда-то сказали, что моё предназначение — собирать людей. Этим я, в общем-то, и занимаюсь. Я стал преподавать в 1999 году и понял, что моё предназначение — не пиксели красить, по темпераменту не подходит. А вот рассказывать об этом у меня получается хорошо, и людям нравится.

В целом CG Event — это плохой бизнес-проект, потому что он завязан на одного человека, на меня. Многочисленные консультанты говорят, что это уязвимый бизнес. Но как случилось — так случилось. Я долго преподавал, накопил большое количество учеников, потом написал книжку, она вышла в 2007 году, вокруг неё собралось определённое сообщество. Плюс я проводил с 1999 года семинары «Пользователи Maya», и они в итоге выросли в CG Event. Ну и до сих пор люди приходят на CG Event именно ко мне. Конечно, с точки зрения бизнеса это плохо, но мне приятно.

Я недавно оглянулся и понял, что конференция одна из самых старых, даже из IT-шных. А если рассматривать её как отраслевую конференцию, посвящённую именно CG, то это одно из крупнейших событий в мире. Так как это дело моей жизни, я продолжаю им заниматься. Это и хобби, и бизнес, и общение с друзьями — всё вместе, в одном флаконе.

Было много смешных попыток сделать какие-то альтернативы, но когда люди занимаются этим параллельно с какими-то проектами или для каких-то других целей, то, как правило, их хватает на раз или два.

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

Про главное кино для развития CG

«Парк Юрского периода», «Звёздные войны», второй «Терминатор». Из более современного — первые «Трансформеры» и «Особо опасен» Тимура Бекмамбетова.

— Расскажи, как ты пришёл к Data Science?

Первые 4 года учился в МФТИ на факультете общей и прикладной физики, занимался наноструктурами, затем решил перейти в Data Science.

Здесь мой путь начался с того, что я, совсем ещё зеленый в анализе данных, решил попробовать связаться с одним из самых успешных и прогрессивных российских учёных в области анализа данных, Евгением Бурнаевым, который стал впоследствии моим научным руководителем.

Он сразу предложил мне заняться научным исследованием и попробовать поработать с упором на production. Так я стал членом научной группы ADASE в Skoltech, и мой интерес к анализу данных вообще и к соревнованиям в частности только рос.

— Как ты попал на нейрохакатон?

После года работы мы с командой решили поучаствовать в хакатоне, который проводился в Сколтехе в коллаборации Сколтеховской лаборатории CoBrain и компании Philips. Мы подумали, что если хакатон проводится в Сколтехе, то это точно знак, что нам пора бы поучаствовать. В соревновании было несколько открытых треков и один научный, в котором мы и участвовали. Нужно было построить алгоритм сегментации рассеянного склероза на снимках МРТ.

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

— Участвовал до этого в хакатонах? Есть ли какие-то отличия от предыдущих?

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

— Почему решили выбрать именно научный трек?

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

— Как готовились к хакатону?

Фактически, подготовка началась в момент моего прихода в лабораторию AeroNet в Сколтехе, где мы занимаемся сегментацией спутниковых снимков. Это, конечно, не МРТ, но навыки и знания пригодились для хакатона почти полностью.

— В соревновании нужно было построить алгоритм сегментации рассеянного склероза на снимках МРТ. Ваш алгоритм будет использоваться на практике?

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

— Была ли какая-то цель для участия в хакатоне? Испытать себя, заявить о себе, с коллегами познакомиться?

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

— Насколько сложным был вступительный тест по работе с датасетами для участия в хакатоне? Много команд его осилило?

Вступительный тест был, на удивление, очень простым. Необходимо было немного поработать с текстовыми описаниями тех же снимков МРТ и определить уверенность/неуверенность постановки заключения врача. Насколько мне известно, все команды справились с заданием. Можно было придумать, как использовать эти данные в очном этапе, но мы не сочли это полезным для нашего решения.

— Насколько сложной была задача хакатона по сравнению с теми, которые обычно решаете в Сколтехе? Как оценивали свои шансы на победу до хакатона и во время ожидания результатов?

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

— Расскажи о технической части алгоритма, использованного на хакатоне и, если можно выделить, что именно помогло победить алгоритм Philips?

Как я уже говорил, это наши модели, которые мы используем для решения сегментационных задач в AeroNet. Естественно, это нейронные сети, предназначенные для сегментации изображений. В отличие от алгоритма Philips, который, как и многие подобные алгоритмы в production, представлял из себя одну-единственную модель сегментации, наша команда подготовила несколько натренированных нейросетей. Как решение мы представляли усреднение предсказаний наших топовых моделей. Ну, и без техник соревнований не обошлось — это и аугментации данных, и различные манипуляции по ходу обучения, и постпроцессинг.

— Долго решали поставленную задачу? Это всё было с ночёвкой на территории Сколтеха?

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

— Как долго ждали результатов? Какая была реакция после выигрыша?

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

— Мотивирует ли эта победа развиваться? Что вообще помогает двигаться дальше?

Да, очень сильно мотивирует. Больше всего, скорее, даже не призы, а возможность поработать вместе с Philips и CoBrain, написать публикацию. А деньги — это приятный бонус.

— Как и почему пришёл к Data Science после прикладной физики? Помогло ли первое образование?

Data Science начал заниматься, потому что всё-таки понял, что математика, а особенно теория вероятности и прикладная статистика, для меня в разы интереснее физики. А эти области математики являются основой для Data Science. Но не буду принижать физику, за годы изучения в физтехе всех её сортов и видов привилась гибкость ума и способность быстро приобретать навыки практически в любых областях.

— Насколько важно иметь руководителя при изучении? Смог бы осилить обучение сам?

Без руководителя никуда. Помимо самих знаний, навыков и советов, которые даёт руководитель, это, прежде всего, опыт работы в реальных научных задачах, взаимодействие с научным коллективом. В одиночку, как мне кажется, очень легко уйти в попытки собрать свой стартап, и непонятно, насколько удачным он будет. А с руководителем и научным коллективом появляется чутьё на актуальные задачи, навыки научного программирования, опыт общения с другими научными группами и наукоёмкими компаниями.

— Приходится ли от чего-то отказываться ради науки?

Да, конечно, прежде всего от [свободного] времени. Сейчас, когда надо учиться и работать в лаборатории одновременно, приходится посвящать всё своё свободное время только этому. Иначе просто ничего не успеть. Но, как говорится, если нравится, то и проблем никаких с этим нет.

— Есть ли какая-то глобальная цель, к которой идёшь в своей работе?

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

— Какие навыки, кроме технических, важны для тебя в работе?

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

— Какие художественные и технические фильмы и книги по теме любишь?

Любимая книга по области, это, конечно же, сборник Айзека Азимова «Я, робот». Она, фактически, Библия от мира Data Science. Всем известные три закона робототехники как раз пришли из этой книги.

— Где ищешь информацию, когда нужно что-то узнать? Есть какие-то проверенные сайты и книги или с коллегами советуешься?

Это, прежде всего, общение с коллегами в лаборатории, а также есть очень популярный чат для русского комьюнити Data Science в Slack — «Open Data Science». Там собралось очень много российских и не только учёных в области анализа данных, и на любой вопрос можно получить ответ. Да и просто очень полезно читать, чем люди занимаются и что спрашивают. А насчёт книг, это, конечно же, C. Bishop «Pattern Recognition and Machine Learning», а более практические навыки можно получить в многочисленных курсах от Stanford и на Coursera.

— Проходил ли какие-то курсы онлайн или оффлайн кроме основного обучения?

Да, это курс от Stanford CS231n по распознаванию изображений, специализация от МФТИ и Яндекса на Coursera по Машинному обучению.

— Как видишь своё будущее в Data Science?

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

— Можешь назвать топ-3 самых эффективных техник для обучения?

Топ-1 — это, безусловно, режим и эффективный сон, это крайне необходимое условие успеха, тем более в науке. Далее следует, конечно, техника для сохранения мотивации. Здесь надо просто окунуться в мир Data Science и не забывать, как сильно развился DS за последние 5 лет. Когда видишь беспилотные автомобили в Сколково, в которые можно сесть, как в такси, сразу же хочется заняться подобным. Ну, и лично для меня последняя техника — это правильная атмосфера при работе. Я почти всегда работаю с музыкой, но без слов, чтобы не отвлекала. Тогда можно очень надолго сохранить свою продуктивность.

— Как посоветуешь начинающим осваивать Data Science?

Сейчас существует бесчисленное количество курсов по Data Science и грех ими не пользоваться. Если есть хоть какое-то желание заняться DS, то надо, прежде всего, пробовать курсы — подобрать можно на любой вкус. А дальше необходимо как можно раньше понять, нравится тебе Data Science или всё-таки нет. С таким бурным развитием области необходимо быстро понять своё место в ней.

Смотрите также: План обучения для специалиста по Data Science

— Почему именно Кипр?

Мне как-то попалось объявление — работа на Кипре. Я посмотрел, подумал, почему бы и нет? Отправил своё резюме в декабре 2015 года, а уже в феврале 2016 вышел на работу.

Я из Магнитогорска, мне импонировал переход к другому качеству жизни: на Кипре свежий воздух, вкусные продукты и тёплый климат. В нашем офисе в Лимассоле — панорамные окна и смузи-бар на крыше.

Когда ты не сильно привязан к месту, можешь выбирать: работать под пальмой или в каменных джунглях. Каждому своё. Если нравится жить, как в Москве, — с шумными ивентами, масштабными тусовками и «Moscow never sleeps», то в Лимассоле будет скучно. Зато если по душе море, то Кипр быстро станет для тебя вторым домом: кайтинг, серфинг, дайвинг, яхтинг здесь в порядке вещей.

— Как проходило собеседование?

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

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

По результатам теста уже было обсуждение с техническим директором, а после последовали оффер с конкретной суммой и сам переезд.

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

— Какая ситуация с жильём?

В последнее время на Кипре наблюдается рост цен: на аренду жилья, на электричество. В начале 2016 года квартиру можно было снять за 500 €, сейчас такая же будет стоить 800 €. Плюс собственники страхуются и берут депозит размером в один, а то и в два месяца. Таким образом, чтобы въехать в своё жильё, бывает, что приходится платить сразу три цены.

Но в первый месяц новичкам предоставляется корпоративная квартира. Нам повезло: мы жили с соседями, которые потом стали нашими близкими друзьями. Здесь люди вытянуты из своего контекста, далеко от своих родственников и друзей из России. Они приезжают открытые новым знакомствам, и мне это очень понравилось.

Электричество здесь традиционно оформляется на жильца. Год назад для открытия счёта в энергетической компании требовался депозит примерно 300 €. Переезжать желательно с некоторой суммой (3000-4000 €), чтобы сразу хватило на аренду квартиры и открытие счёта на электроэнергию.

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

— А как распределены остальные расходы на быт?

Что касается продуктов — на семью из двух взрослых ежемесячно уходит порядка 500-600 €. Часть расходов (медицина, транспорт) покрывает компания.

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

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

Жёны сотрудников Exness получают тип резиденции без права на работу и занимаются чаще всего семьёй и домом. Компания покрывает расходы на здоровье, включая беременность и роды, страховка оформляется в первый день прибытия на работу. В мае у нас родились близнецы раньше срока, поэтому месяц после родов они провели в госпитале. В Лимассоле есть договоренность с одной клиникой, там даже если превышаешь сумму, указанную в полисе, всё равно всё оплачивает фирма.

— Как организован рабочий процесс?

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

Всех новичков поначалу «сажают в канбан», куда прилетают мелкие задачки, которые нужно быстро поправить. Так ты знакомишься с кодовой базой, познаешь воркфлоу процессов разработки и деплоя. Мы стараемся следовать принципам Agile, но без фанатизма, так как важнее достижение результата, а не соблюдение формальностей.

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

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

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

— Есть куда расти? Дополнительные занятия, курсы?

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

Каких-то специальных курсов для программистов в Exness нет. Я даже не знаю, насколько они были бы востребованы. У нас идёт набор специалистов уровня Senior, которые сами могут многому научить других, поэтому и нет необходимости в таких курсах. Но периодически проводятся внутренние хакатоны с весьма неплохими призами.
Как правило, программист в своей области развивается сам, потому что ему интересно. Он всегда знает все последние новости «на кончиках пальцев» не потому что должен, а потому что он этим живёт.

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

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

— Какая атмосфера на работе?

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

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

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

Мы пообщались с техническим консультантом чемпионата, Антоном Чумаченко, который также является победителем Russian AI Cup 2016 — соревнования в стиле Dota для ботов с ИИ.

— Расскажи, пожалуйста, почему тебя позвали помогать и какова твоя роль в хакатоне?

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

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

— Какой тип игры выбрали для соревнования и почему?

— Решили остановиться на мультиагентном покере (9 человек) и самой популярной разновидности — безлимитном техасском холдеме. Начальное количество фишек в каждой игре (50 больших блайндов) подобрано таким образом, чтобы стратегия не сводилась к выбору 3-4 простых вариантов, а имела хорошее ветвление с точки зрения вариативности развития событий.

В классическом покере в онлайн-казино часто используют ограничение в 100 больших блайндов в качестве минимально допустимого (большой блайнд — это минильная ставка для повышения). При таком ограничении дерево игры получается настолько большим, что для его обхода даже с учетом хитрых оптимизаций потребуется достаточно много процессорного времени. А если учесть, что участников 9, все они должны принимать решения последовательно и игр нужно провести много из-за сильного влияния случайных величин, чтобы отделить «хорошие» стратегии от «средних», то времени на ход слишком много выделять не получается. А вот при ограничении в 50 больших блайндов можно реализовать достаточно эффективную стратегию, основанную только на математике, и дерево игры будет значительно меньше.

— Как проходит онлайн-этап хакатона? Что ты сейчас делаешь?

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

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

— В описании турнира указано: «предлагается написать игрового бота на основе машинного обучения». Однако в покер можно играть, и даже, наверное, довольно успешно, не используя алгоритмы машинного обучения, а полагаясь на расчет вероятностей. Такие решения будут приниматься? Они вообще будут работать?

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

К тому же сложно провести грань, в каком решении есть машинное обучение, а в каком нет. Например набор IF-THEN-ELSE правил, которые опираются на хитрые константы, вполне мог быть выведен после обучения стратегии, основанной на нейросети, которая сыграла сама с собой миллионы игр и выдала на выходе оптимальные константы, а в исходный код участник не вставлял эту нейросеть для ускорения работы стратегии.

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

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

— Ты победил в прошлогоднем турнире Russian AI Cup. Есть ли что-то общее у этих двух соревнований?

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

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

— Какие советы ты дашь участникам, опираясь на свой опыт? Как бы ты стал решать данную задачу?

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

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

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

Привет, Антон. Какие в целом впечатления у тебя от соревнования?

В этом году специфика задания была таковой, что первая стратегия могла побеждать вторую, вторая — третью, а третья — с легкостью одерживать победу над первой. И задание оказалось гораздо шире в количестве разных аспектов, чем в предыдущие годы. Поэтому до самого финала нужно было пристально наблюдать за стратегиями других участников и писать новую порцию кода, если они находили контрмеры для твоей стратегии. Победа далась нелегко и в какой-то степени благодаря везению, так как отрыв от 2-ого места составил всего лишь 4 балла, а от 3-его — 6 баллов (у Антона 1250 баллов в финале — прим.ред).

У тебя уже был опыт участия в Russian AI Cup?

Да, я участвовал во всех чемпионатах Russian Ai Cup, начиная с 2012-ого года, и каждый раз результат был все выше и выше. Лучшим результатом до этого года у меня было 8-ое место в 2015-ом году. Переломным оказалось задание, где нужно было запрограммировать управление хоккеистами, потому что на тот момент мне казалось, что мои знания и способности существенно ниже, чем у участников, занимающих первые 30–50 мест в подобных соревнованиях. И первое место в песочнице (сразу после победителей финала) подарило мне вместе с ценным подарком веру в собственные силы и в то, что выучить что-то и улучшить свои способности никогда не поздно.

Как ты проектировал свою стратегию?

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

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

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

Помогло ли умение играть в DOTA, на которую похож формат игры?

Умение играть в доту помогло, но косвенно: был повышенный интерес в самом начале соревнования, вследствие чего быстро забрался в верхнюю часть песочницы. А дальше уже дополнительно подстегивало желание не потерять набранных позиций. Также считаю, что помог победить опыт настройки баланса и подбор коэффициентов, который я получил при написании пары своих небольших игрушек. В данном чемпионате были достаточно важны эвристические предположения, такие как “пойти за бонусом на 37-ой секунде или на 38-ой”. Математически все аспекты данного чемпионата запрограммировать было очень сложно, так как время ограничено.

Ты писал свою стратегию на C++, почему выбор оказался таким?

C++ я выбрал потому, что большинство крупных работ выполнял именно на нем, также не хотел упираться в лимит по времени, отведенный на стратегию, если вдруг будут какие-то сложные вычисления. Хотя особенности С++ я использовал мало, поэтому не так уж и важно, на каком языке писать. Лучше выбрать тот инструмент, для которого не потребуется каждые 15 минут лезть в гугл и искать примеры инициализации массивов. Правда, это утверждение хорошо подходит, если цель — занять место повыше. А целью может быть еще и изучение нового языка (такое наблюдалось у некоторых из участников).

Как можно подготовиться к этому соревнованию?

Заранее глобально подготовиться сложно. В целом могу посоветовать побольше изучить теорию графов, в частности поиск путей, и перебор с отсечением (это наиболее популярные виды алгоритмов, которые использовались на прошедших 5-ти Russian AI Cup). Также полезным будет прочтение статей победителей прошлых лет и изучение их кода. Хорошо потренироваться в написании ботов можно на сайте www.codingame.com. Еще раз повторюсь, что написание своего визуализатора увеличивает скорость отладки. Я для его написания использовал OpenGL, но, возможно, кому-то будет более комфортно использовать другие средства для отрисовки простой графики.

Порекомендуешь принять участие в чемпионате?

Конечно, оно того стоит! Неважно, какое место я занимал: 1-ое или 200-ое — во время чемпионата я получал массу удовольствия, отличную разминку для мозгов, дополнительные знания и навыки, а также знакомился с собратьями по интересам.

Благодарим Антона за предоставленное интервью.

Игры, для прохождения которых нужно писать программный код, в последнее время набирают популярность. Помимо участия в Russian AI Cup, “поиграть в программирование” дают возможность и другие компьютерные игры: мы собрали подборку игрушек, которые подойдут новичкам, а также коллекцию проектов, которые приглянутся уже более опытным программистам.

А о написании искусственного интеллекта для прохождения игры у нас есть целый цикл статей: в нем рассказывается о написании ИИ для игры в хоккей.

На этом мероприятии Франц Тост пригласил Владимира на стажировку в Италию.

17 ноября Франц Тост и Даниил Квят, пилот команды Scuderia Toro Rosso, приезжают в МФТИ, и вы можете задать им интересные вопросы. Авторы лучших вопросов получат фирменные призы и приглашение на втречу с Франце Тостом и Даниилом Квятом. Подробности о конкурсе — в конце статьи.

С Владимиром встретилась журналистка Физтех.Радио Валерия Муравья и узнала, как студенту из России удалось попасть в известную гоночную команду,чем живут в итальянской Фаэнце и почему Формула 1 — это самый высокотехнологичный вид спорта.

Добрый вечер, Владимир. Расскажи, пожалуйста, немного о себе, откуда ты родом, как попал в МФТИ?

Добрый вечер. Я родом из Санкт-Петербурга. Еще когда я учился в Физико-технической школе Санкт-Петербургского Академического университета я увлекался математикой, физикой и другими техническими науками. После окончания школы я сразу решил поступать в МФТИ, так как именно здесь я бы смог продолжить активно заниматься тем, что мне интересно.

С выбором факультета дела обстояли немного сложнее, выбирать пришлось между Факультетом инноваций и высоких технологий (ФИВТ) и Факультетом управления и прикладной математики (ФУПМ), но так как мне были интересны такие направления, как искусственный интеллект и машинное обучение, меня заинтересовала группа доктора физико-математических наук, профессора РАН, заведующего отделом Интеллектуальных систем ФИЦ ИУ РАН Константина Вячеславовича Воронцова которая была на ФУПМ-е.

Можешь рассказать о том, как ты узнал о приезде руководителя команды Scuderia Toro Rosso Франца Тоста в Долгопрудный и познакомился с ним?

Это очень интересная история. Как и все современные студенты, я сидел в ВК и вдруг увидел объявление исполнительного директора «Физтех-Союза по поддержке и развитию МФТИ» Алексея Золотарева, в котором говорилось, что “к нам в Долгопрудный на пару часов приедет руководитель гоночной команды Scuderia Toro Rosso, и если вы хорошо знаете английский язык и любите Формулу 1, то у вас будет уникальная возможность лично пообщаться с Францем Тостом”. С детства вместе с отцом я смотрю Формулу 1, и английский у меня был на приличном уровне. Поэтому я, не долго думая, написал Алексею и в итоге оказался в ресторане «Теория Кухня&Bar», где проходило интервью Франца.

Еще до самой встречи я знал, кто такой Франц Тост, знал, что он очень уважаемая и известная личность в мире Формулы 1, и я был невероятно рад возможности познакомиться с ним лично, узнать, как устроены команды Формулы 1 и сами гонки «из первых уст».

После интервью Франца мы провели для него небольшую экскурсию по кампусу МФТИ, рассказали про наш вуз, его историю, направления исследований, которые тут ведутся, и действующие лаборатории. В общении с Францем я отметил для себя его невероятную заинтересованность гонками. Я уверен, что про «внутреннюю кухню» Формулы 1 его расспрашивали огромное количество раз и, несмотря на это, он сохранил очень живой интерес к своему делу. На мой вопрос про программу стажировок в STR Тост отреагировал очень доброжелательно и рассказал, что такая программы в Scuderia Toro Rosso есть и они с радостью рассмотрят мою кандидатуру.

После экскурсии по кампусу МФТИ как ты построил свое взаимодействие со Scuderia Toro Rosso?

После экскурсии и после окончания Гран-При России, которое прошло в октября 2014 года, в Acronis мне помогли с контактами HR-службы Scuderia Toro Rosso, и я написал им. Мне ответили, что отбор на программу стажировок стартует только в 2015 году, и мне стоит связаться с ними в марте.

В марте я связался с HR-службой Scuderia Toro Rosso, и мне назначили дату первого Skype-интервью. Первое интервью-собеседование со мной проводил сотрудник HR-службы. Вопросы в основном были о моем образовании, о том, как я узнал про стажировку, моих увлечениях, в общем всем том, о чем расспрашивают всех соискателях на подобных интервью. У меня получилось хорошо себя показать, и я прошел на второй этап, где мне был предложен выбор из нескольких отделов, нуждающихся в стажерах.

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

После второго интервью меня попросили подождать ответа, спустя пару недель мне сообщили, что берут на стажировку. Я был невероятно рад. Только представьте, я смотрел гонки Формулы 1 с 1994 года, когда их впервые стали показывать по ТВ, и вот мне сообщают, что я поеду в Италию и все лето буду работать в команде Формулы 1. Можно сказать, что сбылась моя мечта детства.

Пригодились ли тебе какие-то из знаний, полученных на Физтехе?

Что мне нравилось в программе стажировок Scuderia Toro Rosso, так это то, что здесь от тебя не требуется заниматься только программированием. В моей работе присутствовало огромное количество различных задач, в которых требуются знания из области фундаментальных наук. По своей сути, геолокация и переложение обработанных сигналов с GPS строится на базе аналитической геометрии и линейной алгебры, а эти предметы на ФУПМ-е преподают на очень высоком уровне, так что мне это очень сильно помогало.

Расскажи пожалуйста непосредственно о своей стажировке, какие задачи ставили?

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

Как я уже говорил, согласно правилам, в гонке с болидов всех команд мы можем получать только GPS координаты и время, а с наших болидов мы получаем терабайты данных с сотен датчиков, вроде давления в шинах и температуры двигателя. Для того, чтобы анализировать, где находятся и как себя ведут наши болиды в сравнении с конкурентами, необходимо расшифровать доступные нам данные с машин конкурентов, строить их траектории движения по трассе и на основе этого давать рекомендации нашим пилотам, Максу Ферстаппену и Карлосу Сайнсу-младшему. Это очень важно, и, например, в команде Scuderia Ferrari таким анализом занимается целый отдел, который состоит примерно из 20 человек.

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

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

Наконец, в воскресенье проходит сама гонка и мы постоянно анализируем показания конкурентов, которые идут перед нашими болидами. Например, когда болид Scuderia Toro Rosso идет за Ferrari мы анализируем, как пилот Ferrari проходит повороты, когда тормозит, когда разгоняется, какие повороты срезает, в какие наоборот проходит шире, и сравниваем эти данные с данными на нашем болиде. Поняв, как и какие повороты нужно проходить, чтобы быстрее выйти и обогнать его, мы скидываем эту информацию в общий чат. Гоночный инженер по радиосвязи передает эти данные пилоту.

Кроме анализа показаний GPS конкурентов, со временем у меня появилась еще одна интересная задача. Я занимался построением моделей деградации шин. Сегодня шины в Формуле 1 – это очень важная составляющая победы, так как, выбрав правильный комплект резины, ты можешь выигрывать по 2-3 секунды с круга, а это невероятно много. По сути, шины это практически единственный параметр, который можно менять по ходу гонки. Нельзя сменить мотор, нельзя провести дозаправку, нельзя заменить пилота, можно лишь минимально изменить аэродинамику и сменить комплект резины. Так как по ходу гонки шины изнашиваются, а каждый заезд на пит-лейн обходится пилоту в 20-25 секунд, выбор удачного момента для их смены может дать огромный выигрыш. К моменту моей стажировки у Scuderia Toro Rosso уже была построена простая модель, и одной из моих задач стала ее доработка и усложнение на основе тех данных, которые были собраны.

Были ли какие-то сложности в работе?

Был небольшой языковой барьер. Я чувствовал, что мне не хватает знания итальянского языка. В Scuderia Toro Rosso сформировалась интернациональная команда, мой непосредственный шеф — Гиём и мой коллега Чарли были из Франции, а другой мой коллега Роберто — из Италии. Между собой они как правило общались на итальянском. На английском общались только со мной. Я знаю, что для сотрудников, у которых контракт на срок более одного года, команда оплачивает языковые курсы, но так как я был в команде всего три месяца, я бы не успел хорошо освоить итальянский.

А ты можешь рассказать, есть ли сейчас в Scuderia Toro Rosso постоянная программа стажировки для студентов?

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

Для меня, в каком-то смысле, было сделано исключение, и я стал единственным стажером Scuderia Toro Rosso из России. Во многом это связанно с тем, что исторически Формула 1 — это европейский вид спорта и его популярность в России начала расти только в 2010 году, когда появился первый российский пилот — Виталий Петров, а затем в 2014 году появилась трасса в Сочи и прошло первое Гранд-При России. Отдельно хотел бы поблагодарить Сергея Белоусова и команду Acronis за то, что пригласили Франца Тоста в МФТИ и помогают нашему вузу развивать подобные международные партнерства.

Ты можешь подвести итог своей стажировки?

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

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

Ты использовал полученные знания и данные при написании своей квалификационной работы?

Мысль написать квалификационную работу на основе тех знаний и данных, которые я получил в Scuderia Toro Rosso были. Более того, команде понравилось наше сотрудничество, они готовы были предоставить данные при условии подписания договора о неразглашении, и даже интересовались, хотел бы ли я продолжить с ними работать после окончания МФТИ. Но, к сожалению, тема моей студенческой работы пока не достаточно актуальна для моей кафедры МФТИ.

Видишь ли ты свое будущее в Формуле 1?

Это сложный вопрос. Но я знаю, что скоро, 17 ноября Франц Тост и Даниил Квят приезжают на Физтех по приглашению Acronis с единственной в России открытой лекцией и только для МФТИ, в честь юбилея Физтеха. Я бы хотел встретиться с ними на мероприятии и пообщаться по поводу вопроса моделирования деградации шин. Ведь когда я был на стажировке, я только закончил третий курс, и не обладал тем багажом знаний в области построения статистических и предсказательных моделей, которым обладаю сегодня, защитив бакалаврскую и учась на пятом курсе. Мне кажется, мой опыт может быть полезен. И, если каким-то образом получится реализовать этот проект, то это было бы очень круто. Я даже знаю нескольких ребят на Физтехе, которым тоже очень интересно участие в нем.

А поддерживаешь ли ты сейчас связь с кем-либо из команды?

Да, я поддерживаю связь через Facebook с членами нашей группы. Это очень увлеченные гонками люди, тот же Роберто до попадания в Scuderia Toro Rosso работал в итальянской гоночной команде MotoGP Ducatti, поэтому у нас находятся общие темы для разговоров. Вообще в Европе, и особенно в Италии, гонки — это невероятно популярный вид спорта, который может соперничать с футболом.

Что ты можешь посоветовать студентам, которые тоже захотят попасть на стажировку в Scuderia Toro Rosso?

Самое главное — не бояться проявить инициативу и подать заявку на участие в стажировке. Ведь если сидеть сложа руки, ничего не получится. Не стоит бояться того, что это другой мир, целая индустрия. До попадания на эту стажировку у меня не было ничего, кроме сильного желания попасть в команду, и базовых знаний, которые я получил на Физтехе. Дерзайте, у вас обязательно получится!

Для участия в конкурсе вам необходимо задать вопрос через эту форму. Даниил Квят обязательно ответит на самые интересные вопросы, их авторы смогут посетить Public Talk в МФТИ и получить открытку с автографом Даниила, а автор лучшего вопроса получит ценный приз с символикой мероприятия!

Выражаем благодарность команде Физтех.Радио за подготовку материала.

Конкурс завершен! Победителями стали:

1 место (призы: футболка и открытка с автографом): Орешников Алексей Юрьевич.

2-5 места (приз: открытка с автографом): Зезюлинский Владимир Николаевич, Давлетов Вадим Мухамедьярович, Тарасов Павел Александрович, Денисенко Антон Андреевич.

Поздравляем победителей! Организаторы конкурса свяжутся с вами в ближайшее время.

Сева рассказал о своем жизненном пути и дал советы другим начинающим программистам.

После публикации в СМИ с ним также связалась компания Mail.Ru Group — сейчас они обсуждают возможности сотрудничества.

Здравствуй, Сева. Я пообщался с твоим ботом, он действительно очень полезный. И сегодня я бы хотел поговорить подробнее о нем и о тебе, как о молодом представителе IT-сферы.

Ну что же, начнем. Сева, расскажи о себе, кто ты такой?

Я Сева, школьник из Удмуртской республики, маленького города Воткинск с населением в 100 000 человек. Я занимаюсь программированием на Python уже полтора года, а в целом программирую с 9 лет. Сейчас мне 14.

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

Отлично. Сева, скажи, если не секрет, сколько пользователей бот имеет на данный момент?

В первый день мы пробили планку 1000 человек, во второй день заинтересовалось около 500 чел, сегодня же около 400. Интересно, что порядка 94% из них — в Telegram.

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

Бот был серьезным проектом или больше хобби?

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

Понятно, какие планы имеешь в дальнейшем? Как планируешь развивать проект?

Планирую создать экосистему телеграм-ботов, т. е. несколько ботов, которые объединены в определенную систему и могут использовать одни и те же данные о юзере.

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

Довольно амбициозные планы, хочу сказать.

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

Хорошо. Скажи мне вот что. Теперь, после такого успеха, о твоем проекте знают твои друзья, одноклассники. Как они к этому относятся? Как относятся учителя в школе?

Как к хобби. Положительно. Гордятся, как и любыми другими достижениями ученика.

Вот некоторые люди считают, что твой возраст на самом деле — просто пиар, а в тени — кто-то серьезный. У тебя кто-то из родственников программист, я прав? Что вообще думаешь о таких обвинениях?

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

Тех, кто утверждает обратное — нужно ткнуть в историю коммитов на GitHub.

«Тех, кто утверждает, что автор не я — нужно ткнуть в историю коммитов на GitHub»

Довольно глупо говорить, что этот продукт разрабатывал не я.

Т.е. бот Open Source? А чего не афишировал? Я вот не знал.

Не думаю, что это стоит всегда афишировать.

Боишься, что украдут идею и реализацию?

Нет, дело в том, что я в спешке его доделывал, и там есть некоторые неровные моменты…

Стыдно за код?

Ага.

*смеется*

На самом деле исходники открыты, и я задумывал его таким изначально, чтобы его могли улучшать, но оказалось, что другим код конкретно этого бота не нужен.

Отлично. А какие еще у тебя в жизни есть крупные достижения? Которыми не каждый может похвастаться.

Хм, даже не знаю. В этом декабре я устроился на стажировку в Медузу. Вроде это не так много, но для меня это много значит.

Это моя первая настоящая работа, мне понравилось заниматься реальными проектами и делать что-то нужное людям.

Та самая Медуза? Та, что Meduza.io?

Ага, та самая.

Невероятно, ну и как ты туда попал? Расскажи историю.

Подумал, хорошо бы позаниматься чем-то реальным, написал письмо им на почту — предложил свою кандидатуру на стажировку.

Написал, что я разработчик и готов выполнять какие-то определенные задачи. Мне тут же ответили и пригласили, дали задание.

Так процесс и пошел.

Удаленно?

Да.

И сейчас ты продолжаешь там работать или стажировка окончилась?

Последнее время не работаю из-за занятости, иногда только исправляю старые баги.

Хорошо. Такой вопрос: из страны уехать хочешь? Только честно.

Да, хочу.

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

В конце концов, кто сейчас не хочет в Долину? Ладно, давай вернемся к твоему более раннему возрасту: как ты понял, что хочешь стать программистом?

Как-то в классе в 1-2 возвращался из школы и увидел объявление о наборе на курсы информатики, записал телефон и уже через неделю начал их посещать. Где-то до 2 класса получил базовые знания, мне понравилось, и я решил развиваться дальше.

Полноценных курсов или обучения IT никогда не проходил.

Сёва, а в олимпиадах ты участвовал? Районных, областных, международных?

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

«Недавно я победил в хакатоне GOTO по анализу Big Data»

Тем не менее, я участвовал в соревнованиях по разработке ПО, недавно вот победил на хакатоне от GOTO по анализу Big Data для школьников от 14 лет. Это всё проходило непосредственно в Москве.

Скажи, вот ты сейчас в 8 классе, выпускной не так уж и далеко. Где планируешь учиться в дальнейшем? По твоему мнению, нужно ли программисту высшее образование в принципе? Потому что судя по твоей ситуации — можно обойтись и без него.

Мне кажется, однозначного ответа на этот вопрос дать невозможно хотя бы потому, что программисты бывают разные.

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

Иногда я думаю о том, что наверное, неплохо было бы поступить в ВУЗ, чисто для получения каких-то математических знаний. Но пока приходится самообучаться и в этой области.

Тем не менее, сам поступать не планирую, но других отговаривать не хочу.

Думаю, подписчики заметят, что твой жизненный путь весьма похож на путь великих людей, вроде Стива Джобса, Марка Цукерберга или Билла Гейста. Как считаешь ты сам?

И Джобс, и Гейтс крутые, но я подражать кому-то не хочу, мне интересно делать свои какие-то продукты и я хочу посмотреть, к чему это приведет. Вдохновлял меня Марк Цукерберг.

Видимо, смотрел «Социальную сеть»?

Конечно.

Хорошее кино. В качестве завершения интервью, посоветуешь читателям 3 фильма, которые обязательно нужно посмотреть?

А чем в 8 классе занимались вы? ?

Как вы пришли в ИТ-сферу? Что именно для вас стало толчком, который подсказал, что с этой сферой хочется связать свою профессиональную деятельность? Повлияло ли базовое образование на выбор пути?

Я окончил мехмат МГУ, и большинство моих однокурсников пошли либо в науку, либо в ИТ-компании. Я выбрал сферу информационных технологий. Учеба дала мне две важные вещи. Во-первых, хорошо работающую голову, то есть умение быстро разбираться с новыми алгоритмами, технологиями. Во-вторых, определенный круг общения. Когда после университета я пришел в AT Consulting, подавляющее число сотрудников были выпускниками либо моего факультета, либо соседнего ВМК. Фактически я попал в уже знакомый мне круг людей, только постарше. Так что образование имеет решающее значение: оно определяет человека в его социальный слой, оставаясь в котором, проще развиваться.

Я пришел в AT Consulting на стажерскую позицию тестировщика на масштабный проект по внедрению CRM-системы в крупном операторе связи. Тестирование проводилось по принципу «черного ящика»: я работал как пользователь, нажимал на кнопки, смотрел на реакцию системы, сверялся с тест-кейсами и искал ошибки. Но мне все время хотелось разобраться в системе глубже, понять, как она работает. Сначала я пытался что-то автоматизировать, писать скрипты, которые вместо меня будут на кнопки нажимать, создавать запросы, делающие выборку, чтобы проверить, правильно сценарий отработал или нет. Это доставляло мне удовольствие, и в конце концов я решил попробовать себя в роли разработчика этой же системы. Мне удалось перейти на позицию стажера-разработчика.

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

Так я стал «рабочей лошадкой», разработчиком, которому поручают сложную работу.

Поступала ли помощь от коллег на проекте, или приходилось самому во всем разбираться?

У нас было несколько серьезных разработчиков-гуру, которые не первый год работали с этой системой, и они выступали в роли наставников, давали советы. Это мне очень сильно помогало. Конечно, сначала я пришел в ужас, потому что пришлось во многом разбираться самому. Читать документацию «от корки до корки» не было времени, нужно было быстро решать насущные проблемы, с которыми я сталкивался на практике. Но помощь коллег и упорство помогли мне преодолеть все трудности.

Вы сказали, что выбрали информационные технологии, почему не привлекла научная деятельность?

С самого начала я не чувствовал склонности к науке. Хотя и занимался несколько месяцев научной деятельностью, сопряженной с программированием. А именно, моделировал разные научные задачи на Matlab в Научно-исследовательском институте. Но работа там не вдохновляла меня, хотелось найти динамичный молодой коллектив, решать сложные технические задачи. И вот однокурсники позвали в AT Consulting, здесь ценилось желание работать и умение быстро учиться.

В какой момент пришло понимание, что уже есть достаточно опыта, и почему вообще решили стать менеджером?

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

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

Над какими навыками вы работали и каким образом? Были какие-то курсы, внутреннее, внешнее обучение?

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

Что бы вы порекомендовали специалистам, которые хотят расти, что им нужно освоить, на что обратить внимание?

Нужно научиться использовать свои сильные стороны. Если мы говорим про специалистов-разработчиков, то они прекрасно понимают, что и как в системе устроено, какие есть возможности, ограничения. Но очень важно не замыкаться на этом опыте, потому что здесь кроется ловушка. Разработчики знают, для чего система предназначена, знают, как она должна работать, но это им может мешать слышать клиента, понимать его потребности. Система нужна для того, чтобы решать задачу, и если эта задача звучит как-то «неудобно» для системы, это не значит, что ее не нужно решать. Эксперт должен предложить оптимальный путь, который бы, с одной стороны, решал проблему, а с другой — не превращал систему в сложное сооружение. Если ты взрастил в себе такой навык, твоя ценность для команды значительно повышается. Нужно уметь понимать людей, их потребности и предлагать решения, базируясь на опыте, накопленном в разработке.

Как изменилось содержание вашей работы на руководящей позиции?

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

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

Вы говорите, что количество общения увеличилось. Как вы накопили на это энергию, учитывая, что изначально ощущали недостаток коммуникативных навыков?

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

Каким образом от руководителя практики вы перешли к управлению?

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

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

А как стали партнером?

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

Сколько сейчас в вашей практике людей?

170 человек.

То есть в три раза увеличилось. Чем вы сейчас занимаетесь в качестве партнера и руководителя этой практики?

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

Какие у вас сейчас клиенты?

Исторически наша практика работает с финансовым сектором, и многие ключевые игроки — это наши клиенты. Мы делаем проекты для Сбербанка, группы ВТБ, Росбанка, Россельхозбанка, ОТП Банка, сети супермаркетов «Азбука Вкуса» и многих других компаний

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

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

Большую роль играет инициативность.

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

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

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

Резюмируя сказанное, скажу, что важны следующие общечеловеческие качества: самостоятельность, ответственность, чувство локтя, инициативность, проактивность.

Сохранилась ли у вас сейчас техническая экспертиза, нужна ли она, помогает?

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

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

Какой совет вы можете дать начинающему и амбициозному ИТ-специалисту? Есть ли универсальный рецепт успеха?

Это вопрос довольно сложный, если бы такой рецепт существовал, то все бы им тут же воспользовались.

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

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

Благодарим AT Consulting за предоставленный материал

На какие качества вы обращаете внимание в первую очередь при наборе разработчиков, и влияет ли диплом о высшем образовании на ваше мнение?

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

Недавно я интервьюировал одного человека, без диплома, который 2—3 курса отучился в Бауманке или МИФИ, а потом исходя из некоторых внутренних соображений и необходимости зарабатывать деньги, плюс в силу характера, невозможности совмещать работу и учебу, бросил вуз. И вот мы с ним разговаривали, он вполне хороший разработчик, достаточно интересными вещами в жизни занимался, и как-то зашла речь о причинах, почему он бросил вуз. Он мне все объяснил и сказал, что жалеет,  что недоучился. Я спросил почему, и он объяснил, что несколько раз в своей карьере наталкивался на задачи, где ему не хватало образования, где разработка эффективного алгоритма требовала глубокого понимания теории графов, например. Он говорит: «понятно, что 90—95% моей работы требует образования на уровне «умею складывать, умею умножать», но иногда попадаются задачи, где я просто чувствую, что, если бы я потратил время и поучился, я бы смог создать что-то сильно лучшего качества». Это одно соображение, но это никак не отрицает того факта, что если человеку действительно необходимо, то он может потом засесть за учебники, прочитать нужные материалы, разобраться. Но, как часто бывает в жизни — «потом» найти время и разобраться тяжелее, чем в молодости.

«Просто без хорошего образованиятяжелее чего-либо добиться»

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

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

Правда ли, что успехи на олимпиадах по программированию (математике) негативно коррелируют с работой в компании? Много ли у вас в команде олимпиадников?

Напрямую олимпиады не помогут. Так же, как и знание матанализа не поможет человеку писать программы на Java или Python. Но олимпиадное программирование, если хотите, это как спортивное самбо. Оно не гарантирует успеха в уличных драках, мало того, есть много примеров, когда спортсмены-самбисты были жестоко покалечены именно в уличных драках, потому что там нет правил: там могут ударить ножом и втроем накинуться на одного. Но спортсмен-самбист намного быстрее становится именно бойцом, начав изучать боевое самбо (или другое рукопашное единоборство), чем человек, который с попкорном смотрит в экран монитора. Поэтому относиться к этому нужно ровно так: олимпиадное программирование – это хороший способ улучшить свой уровень. Человеку, который этим занимается, овладеть новой областью компьютерной науки или способу программирования будет легче.  Это полезная деятельность, ее не стоит избегать. Если человек профессионально работает в компании, делает продукты, продающиеся широко, это становится как хобби. Человек, который работает в компании, производящий продукты для резервного копирования, наверное, за несколько лет становится профессионалом мирового класса в этой области. И олимпиадное программирование, если он начнет в нём участвовать, вряд ли ему сильно поможет, чтобы он стал на голову выше своих коллег. Но это полезное хобби, которое развивает нужные навыки.

«Олимпиадное программирование — это как спортивное самбо. Оно не гарантирует успеха в уличных драках… Но спортсмен-самбист намного быстрее становится именно бойцом…, чем человек, который с попкорном смотрит в экран монитора.»

А вообще, удивительно, как люди отказываются учиться. Когда я был молодым, пропаганда была очень мощная: надо учиться, это полезно, знание — сила, невежество – тьма. Не понимаю, почему у ваших ребят могут возникать такие вопросы. Знания не бывают лишними. В конечном итоге жизнь устроена так, что если человек понимает что-то очень-очень глубоко, ему легче увидеть, как работает какая-то совершенно, казалось бы, несвязанная с ним область. Всё, что мы делаем, в конечном итоге похоже.  Так, я пребывал в иллюзии по поводу строителей, пока не стал делать свой первый ремонт. Первый и последний. Я обнаружил, что работа строителей в квартире очень похожа на работу коллектива программистов. И мало того, что все те проблемы, с которыми мы сталкиваемся, у строителей стоят в полный рост. И там еще хуже. Потому что средний уровень строителя ниже среднего уровня программиста, с точки зрения образования и общей толковости. Они так же ошибаются, у них есть баги, бывают как хорошие так и плохие проектные менеджеры. Если плохой – могут, образно, и унитаз на потолок прикрутить, а потом делать вид, что так и было. Поэтому знаний избегать не надо. Возможно, конкретно данное знание мне никогда не пригодится, но если я что-то понял, понял почему так, а не иначе, мне оно пригодится хотя бы в виде аналогии.

Не поделитесь вопросами и задачками, которые вы задаете кандидатам на работу?

Они очень разные. Мне нравится подход, который был популярен в различных компьютерных сообществах, используемый в Google, Microsoft и прочими крупными компаниями, когда человеку дают разные нетривиальные задачки и ему предстоит пофантазировать на эту тему, подумать. Сколько шариков помещается в школьный автобус? Сколько человек помоет окон? Один из архитекторов и разработчиков NTFS Microsoft любил такую задачку – он говорил «напиши мне memory allocator для ядра». У нас суть такая же – мы даем задачу, а дальше смотрим, что человек начинает спрашивать, потому что понятно, что решение задачи зависит от дополнительных условий, как именно мы хотим оптимизироваться. Мне кажется, что это правильный подход, когда человек начинает думать и мы смотрим, как он подходит к задаче. Потому что, если человек молодой и неопытный, он сразу начинает писать решение, сразу какие-то начальные условия сам себе расставляет и под них подгоняет задачу. Это даёт сразу большое количество информации и позволяет оценить, какого уровня человек: будет ли он требовать присмотра, обучения или он уже готовый специалист.

Мне нравятся простые задачки – весы и 8 монеток, одна из которых легче, потому что фальшивая. Как ее найти? Многие не знают, те кто знают – отвечают легко. Интересно посмотреть на реакцию людей. Какие-то задачи более сложные – два стакана и сто этажей – как найти этаж, с которого стакан начинает разбиваться за минимальное количество попыток. Иногда я вообще никаких задач не спрашиваю – все зависит от человека, как пошел разговор. Жестких правил здесь нет. При разговоре сначала спрашиваю о его жизни: где учился, какие проекты делал. Спрашиваю обычно на достаточно общем уровне, не въезжаю глубоко в детали, не спрашиваю, сколько какого кода написал. Нет. Просто слушаю, как человек рассказывает о своей работе – это тоже много информации дает. Когда человек делал малую часть и не понимает, что эта за система, или наоборот, когда человек все видит и, может быть, он отвечал за одну часть, но понимал все целиком и сделал свою часть так, что лучше уже нельзя.

«Когда [кандидат] начинает крыть своего бывшего работодателя, это производит крайне плохое впечатление»

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

После этого начинаем уже профессиональные вопросы, чтобы понять, насколько глубоко разбирается в своей области. Пример: 2003—2004 год, ко мне пришел человек на интервью. Я стал читать его резюме, у меня начали руки дрожать – настолько хорош был человек, что просто не верится. Знает все, что нам надо, и еще намного больше. Когда я говорил с ним, у меня было чувство, что ко мне попал алмаз и его продают по цене стеклянного шарика и я, боясь спугнуть, не задавал много вопросов. Но потом всё же случайно задал такой вопрос, что человек поплыл. Когда я стал дальше «щупать» по ключевым словам в его резюме, то понял, что он ничего не знает. Я в конце ему говорю – как же так, с таким резюме и ничего не знать! Что происходит? Признался, что списал у брата. Это реальный случай, поэтому я всегда задаю пару вопросов, чтобы удостовериться, что человек не выучил наизусть компьютерный жаргон, а действительно понимает, о чем говорит.

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

Нахватавшихся терминологии сейчас довольно много – по различным причинам. Индустрия последние годы резко расширялась. 20 лет назад потребность в программистах в нашей стране была не очень высокая, и найти работу было нелегко. Большинство программистов тогда выполняли работу «эникейщика»: принтеры носили. А потом, когда стали появляться серьезные компании, появились программные продукты, требования рынка по количеству программистов резко увеличилось и зарплаты стали расти, туда потянулись люди. В том числе и те, у кого не было профильного образования, ни компьютерного, ни технического. Это не всегда мешает стать хорошим программистом, но была когорта людей, которые знали только по вершкам и научились программировать в Visual Basic. Написали себе резюме и стали хотеть много денег. Поэтому я всегда базовые вопросы спрашиваю. Если ответы странные — копаю глубже, смотрю, что он знает. Если человек отвечает нормально, видно, что понимает, то стараюсь понять его общечеловеческие качества. Я нейтрально отношусь к политике, хобби, беготне по лесам с хоббитами, сыроедению и т.п. Считаю, что это – личное дело человека. Но когда человек начинает говорить странные вещи, что надо, например, убивать всех велосипедистов, то это, конечно же, очень серьезный звонок. По опыту, если у человека есть странное увлечение или мировоззрение – оно мешает работе и приводит к тому, что человек может неожиданно подвести.

Молодежи вот такие задачки не всегда нравятся, они же высокого мнения о себе.

Я спокойно к этому отношусь. В молодости быть категоричным и безапелляционным совершенно нормально. Есть же известная история про французского математика Эвариста Галуа, которого убили в 20 лет на дуэли. Он был очень талантливым, поля Галуа до сих пор в математике изучаются. Когда он пришел устраиваться в Политехническую школу, профессора попытались устроить ему что-то вроде экзамена. Дали задачку. Он с ходу швырнул в них тряпкой, которой стирают мел с доски, и сказал, что он им не школьник на такие детские вопросы отвечать. Когда ты молод, горяч и очень высокого о себе мнения, задачка может тебе не нравиться, но надо понимать – ее задают не для того чтобы унизить, а чтобы посмотреть на то, как человек думает. Ведь наша жизнь устроена так, что даже если человек клинический идиот – он не ходит с табличкой  «я идиот». Нет, он приходит на интервью, и с первого взгляда сказать, что он идиот, бывает невозможно. И любой, кто кого-то нанимает, старается понять, кто к нему пришел: нормальный человек, гений или тот, кого надо сразу заворачивать. Эти задачки – способ посмотреть, как человек думает. Они могут быть про шарики, кубики, интересные или не интересные – неважно.

Ваш любимый язык программирования?

Я начинал с «ассемблера» для Intel 8085 и 8080. Первые свои программы я писал в тетрадке. Перфокарты были, но я как-то мимо них проскочил, случайно правда. БЭСМ-6 у нас в институте были, но я на них почти не работал. Потом были процедурные языки, объектно-ориентированные и функциональные… Я бы сказал, что у меня нет любимого языка. Язык под задачу – это верный подход. Если попросят написать драйвер под операционную систему – это будет С, без шансов.  Если что-то скриптовое, то это, скорее всего, будет Bash. Мне нравится Bash, я много на нем писал, в нем есть элементы и функционального программирования и любые другие. Если задача будет связана с бэкэндами, это может быть Java или Python. Скорее то, на чем уже написана часть кода. Но если нет жестко заданных ограничений, то, наверное, всё-таки Bash.

Станислав, расскажите, пожалуйста, над какими проектами вы сейчас работаете?

Над нашими продуктами, над новыми версиями. Что-то улучшаем, каким-то образом пытаемся сделать так, чтобы все наши продукты были связаны, чтобы была единая платформа.

Недавно у вас появился мобильный бэкап, это одна из частей этой платформы?

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

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

Но тут встает другая проблема – как найти ту информацию, которая вам нужна. Лично я стараюсь все сохранять, не «убиваю», например, свою почту, но, когда мне надо найти какое-нибудь письмо — это просто мука (тут еще есть такой интересный феномен – обычно почему-то находится письмо из прошлого поискового запроса, и я не знаю даже, как это объяснить). У меня есть почта, которую я заархивировал, есть почта, которая живет на моём Exchange, и есть еще какая-то почта на личных аккаунтах. И если я не помню, где ее искать – шансов найти достаточно мало. Вот мы и пытаемся, например, этот процесс сделать удобным – чтобы данные всегда были доступны со всех устройств и их потенциально было легко найти. Над этой системой мы в том числе и работаем.

Как у вас компании непосредственно организована разработка? Как идёт процесс от постановки задачи до выхода продукта на рынок? Какие методологии применяете?

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

Когда мы начинали, у нас было совершенно детское представление о методологиях разработки. В одной книжке про историю компании Microsoft я прочитал, что, когда они работали с IBM над IBM PC, MS DOS и прочим, у инженеров IBM уже была высокая культура разработки. В частности, потому что в IBM всегда делали железо, а в железе ошибки стоят гораздо дороже. Так вот, инженеры IBM просто впадали в ступор, когда видели идеологию Microsoft на тот момент: «if it compiles… ship it!». То есть в Microsoft не было тогда ни понимания, что нужен quality assurance, ни тестеров — ничего. Скомпилировалось – вот вам ребята! Не работает? Сейчас починим!

«Не очень важно, какой именно процесс разработки у себя в компании использовать, но очень важна итеративность»

Любая компания, которая начинала очень рано, а мы, по меркам нашей страны, начали очень рано, через это проходила. Мы на собственном тяжелом опыте понимали, почему надо тестировать, почему в ночь перед релизом простой fix, который точно ничего не может сломать, обязательно все сломает. Пример: когда мы делали один из наших продуктов, то в ночь перед релизом обнаружили, что в русской версии продукта название программы на экране написано на английском. И инженер, который, кстати, сейчас работает здесь же, в Acronis, сказал мне: «Давай переведем, я соберу, ведь выглядит некрасиво. Что мы можем сломать, мы просто заменим английский текст на русский». Я ему ответил – хорошо. Он перевел – и все перестало работать. А причина была очень простая – русский текст был на несколько байт длиннее и случился «buffer overrun» («нехватка буфера»). То есть был баг, который не проявлялся в английском варианте, там был фиксированный буфер, туда клалась строчка, а в русском чуть больше – и буфера не хватало. Так что мы все это проходили. Начиная с базовых вещей, что нужно тестирование, нужно фиксить баги, их квалифицировать.

Я помню, как тяжело было понять некоторые методологии в начале-середине 90-х, описывающие интерактивный процесс разработки. Вот есть waterfall, а вот rational unified process, который предполагает несколько итераций waterfall. Сейчас расскажи это любому инженеру – он это поймет, ведь уже и книг написано куча, все работают в компаниях, где итеративный процесс в том или ином виде присутствует. А тогда было непонятно. Потому что в waterfall начинаем мы с требований, потом пишем код, потом мы тестируем, потом выпускаем продукт. Зачем это делать несколько раз, если мы вот тут уже должны выпустить? Extreme programming мы тоже пробовали и использовали, причем во всех его реинкарнациях: парное программирование и т.д. и т.п.

«Когда люди становятся профессионалами, им надо дать возможность самим выбирать инструменты»

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

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

Кстати, по поводу начинающих команд. У нас в сообществе довольно много программистов, только встающих на путь становления профессионала. Они объединяются, выбирают проект и начинают его делать. Могли бы вы посоветовать им перенять какие-то аспекты вашей практики организации разработки? Например, стоит ли им использовать Jira или не стоит, может быть, какие-то ещё инструменты.

Очень тяжело давать советы, потому что у разных людей работают разные вещи. Я скажу так: для меня, когда люди начинают ссориться на тему «Jira или не Jira» – это звучит дико. Конечно, лучше иметь современный стэк тулзов, который позволяет обеспечить то, что называется continuous integration. Выбор этих тулзов – вкусовщина. Если люди знакомы с «джирой» – пусть используют «джиру». Если хотят использовать что-то другое и они согласны – ничего такого в этом нет. Но вот непрерывная интеграция (continuous integration) – это важно, “ итерационная разработка” (iterative development) – это важно. Кто-то, играющий роль продакт-менеджера, то есть человек, разбирающийся с тем, что же мы делаем, – это тоже очень важно. «Проверка качества» (quality assurance) – это важно. А дать конкретные рекомендации «берите только джиру или не джиру» — это будет глупо, неправильно и не имеет никакого смысла.

«Лучше иметь современный стэк тулзов, который позволяет обеспечить то, что называется continuous integration»

У команд, которые объединяются, на самом деле и так задача очень сложная. Потому что очень часто эти команды – виртуальны, люди которые расположены в разных городах, зачастую даже никогда лично не встречались, и которые хотят сделать проект. В любом софтверном проекте есть шансы на неудачу, и в зависимости от разных вводных эти шансы могут увеличиваться. Команда незнакомых друг с другом людей, расположенная в разных городах, сильно увеличивает шансы на неуспех. Не все способны работать удаленно. Я знаю многих людей, которым тяжело работать дома, потому что дома человек пришел, cел за компьютер, хочет поработать, а тут прибежал ребенок, залез на плечи, попросил купить алмазиков в какой-нибудь игре, затем убежал. Человек отвлекся, вдохновение пропало… и он пошел на какой-нибудь сайт. Время ушло. Работать удаленно тяжелее, чем в офисе, для многих людей. В любом случае человеку удобнее, когда его не отвлекают. А дома с этим проблематично.

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

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

Беседовал Алексей Михайлишин, основатель проекта tproger.

После того, как TJournal опубликовал расследование, DDoS-ить начали и это издание. А всего несколько часов назад предполагаемый лидер атакующих заявил (скрин), что он не причастен к атакам.

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

Как стало известно в пятницу, 2ch.hk лежит под крупной DDoS-атакой. Каковы ее масштабы?

Масштабы можно оценить по тому, что от рук атакующего лежат крупнейшие торренты, лег проект «Роскомсвобода», лег полностью наш дата-центр, пока не отключили нас.

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

Испытывал ли ваш сайт раньше DDoS-атаки подобного масштаба?

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

Самый первый раз нас атаковали с мощностью в несколько гигабит в 2012 году из-за взломанной почты активистов движения «Наши», тогда мы под CloudFlare встали и все пришло в норму.

Cloudflare: CDN-сервис, предоставляющий множество средств для удобства управления сайтом, в том числе защиту от DDoS-атак

Потом еще несколько попыток ддоса было, но мы поменяли хостера, и защита уже не пробивалась, но теперь снова пробили.

Вы так и не выяснили, каким образом слили ваш реальный IP? Или это закрытая информация?

Выяснил, но рассказывать не буду, понятно по каким причинам.

Пока обсуждаю с Cloudflare, есть ли возможность это предотвратить в дальнейшем.

Хорошо. Какие методы защиты от DDoS-атак вы используете на данный момент и почему они не сработали?

Начиная от программных, которые работают против простейших атак, заканчивая CloudFlare, который обошли.

Есть защита у ДЦ от подобных атак, фильтрация мусорного трафика, но она не справилась. Какая там у них защита стоит, лучше узнать у датацентра.

Как вы планируете отбивать данную атаку и защищаться от подобного в дальнейшем?

Сейчас датацентр наращивает мощности, чтобы в дальнейшем подобные атаки не влияли на работоспособность сайтов, стараются отфильтровать атаку, мы поднимаем резервный сервер.

На нас регулярно совершаются DDoS-атаки разной мощности

Из скольки человек состоит команда технических специалистов вашего сайта? Чем она занимается на данный момент? Есть ли в ней свободные места?

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

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

Организаторы атаки недавно сказали, что торрент-трекеры атакуются из-за распространения там нелицензионного контента. Как вы думаете, а в чем причина DDoS-атаки на ваш сайт?

Организаторы атаки прислали письмо датацентру, что у нас «рассадник аморальной информации».

На самом деле, им кто-то проплатил атаку нашего ресурса, а торренты, полагаю, атакуют ради пиара и рекламы.

На своей странице ВКонтакте вы написали, что собираете 100 тысяч рублей на оплату хостинга и улучшение защиты. Сколько средств было собрано на данный момент? Расчитываете ли вы набрать полную сумму только с пожертвований?

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

Пока собрали около 20% от суммы, для одного дня более, чем нормально, спасибо анону.

Спасибо за интервью!

Вам тоже.

Абу благословил этот пост

Рассказывает Максим Кузькин, вице-президент Parallels и главный архитектор продуктов Odin — бренда, под которым реализуются решения для дата-центров от лица Parallels.

Я в своей работе никогда не пользуюсь словом «программист». Когда я обращаюсь к людям своей профессии, я всегда стараюсь называть их инженерами. Сугубо узкая формулировка «программист» — точно так же, как и «тестер», например, — плохо отражает специфику нашей профессии. И чем дальше, тем хуже эта формулировка работает.

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

По мере того, как течёт время, порог входа становится ниже. Например, в Microsoft сейчас нет такой роли, как «тестер» — у них есть developer in test (Специалист, который пишет программы, тестирующие другие программы. — Прим. ред.). При этом всех людей, которые занимаются разработкой, называют инженерами программного обеспечения (software engineers), просто они задействованы в немного разных сферах. Сейчас освоить инструменты стало настолько просто, что границы между конкретными специализациями стираются. В будущем вряд ли останется разделение, скажем, на JavaScript-программиста, Python-программиста и .NET-программиста — как и разделение между фронтендом и бэкэндом.

Знать язык программирования недостаточно

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

Вот пример того, что я имею в виду под технологическим стэком в случае с браузером. Есть JavaScript, есть представление о том, что такое HTML, протокол HTTP. JavaScript-программисту никуда от этого не деться, он должен его понимать — как и то, откуда взялись правила изоляции и кроссдоменной безопасности, как работает протокол SSL, как работает безопасность, основанная на сертификатах. Дальше, если мы идём в бэкэнд, то человек обязательно должен понимать организацию структур данных. В любом более-менее сложном приложении, когда речь заходит о визуальном отображении сложных структур данных, объединении таблиц и организации выборок, интерфейс и бэкэнд становятся непосредственно связаны. Очень сложно сделать эффективное приложение, если люди, которые делают интерфейс, не понимают хотя бы базовых проблем, о которых нужно думать в бэкэнде: шардинг, организация данных, структура запросов. И наоборот: очень сложно сделать правильный API в бэкэнде, правильно предусмотреть возможность шардинга и горизонтального масштабирования, если человек, который пишет бэкэнд, не понимает проблем, которые есть на фронтенде.

Грань между дизайнерами и инженерами останется

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

Сейчас, если я хочу сделать хороший сайт, то, наверное, имеет смысл нанять JavaScript-программиста. С другой стороны, я могу пойти на Wix или другой билдер и сделать там сайт, близкий к тому, что мне нужно. Мне кажется, что этот тренд продолжится.

Инженерам нужны и естественные, и гуманитарные науки

Чем дальше, тем более сторонними оказываются затрагиваемые сферы. Возьмите хотя бы развитие компании Apple, которое во многом было продиктовано увлечением Стива Джобса и людей, которые его окружали, гуманитарными науками: в частности, маниакальной любовью к красивым шрифтам и иероглифам. Все запоминающиеся изменения в информационных технологиях очень часто происходят на стыке наук. Это почти всегда синтез, потому что IT — просто способ представления и обработки информации, который лишается смысла в вакууме. Так, сложно назвать «программистами» людей, которые придумали графический пользовательский интерфейс, — это как сказать, что iPhone стал успешен благодаря только «железу» или только «софту».

Ещё 10 лет назад фронтенд-разработчику казалась бы дикой мысль о том, что нужно прочитать книги о восприятии и психологии людей. Сейчас это уже само собой разумеющееся: если человек разрабатывает сайты, то он прочитал все возможные книги по UX, UI, тому, какой объём информации люди способны воспринимать, как её лучше подавать. И это ведь смежная технология, пришедшая к нам чуть ли не из медицины — и то же самое будет касаться физики, химии и биологии.

Получайте базовые знания, которые не устаревают

Что бы вы ни начинали учить сейчас, через 5—10 лет оно устареет. А потому, как бы глупо это ни звучало, нужно учиться учиться. Если есть запас времени, лучше посвятить его тому, как работает то, чем вы собираетесь пользоваться, — начиная от курса физики и математики. Без базовых знаний пресловутым умением учиться сложно воспользоваться. Фазовый переход на следующий уровень всегда намного проще для людей, которые понимают, как работают компьютеры на физическом уровне, — пускай они даже этим не пользуются и работают на гораздо более высокоуровневых языках. Они не просто пользуются автомобилем и включают передачи, а понимают, как автомобиль работает. Когда эта штука становится чем-то вроде электромобиля, им сделать этот переход намного проще.

Если мы ставим на стратегию долгосрочного развития и роста, то важнее не прикладные, а фундаментальные знания. Не банальное представление, как послать GET-запрос, а понимание HTTP-протокола: почему он был так сделан, какие идеи в него были заложены. Когда мы перейдём на условный SPDY, вы сможете понять, как произошло это изменение. Нужно общее понимание того, когда эти запросы посланы на сервер, как работает процессор, который делает эти вычисления на сервере. Слишком углубляться во всё не надо, но для широты знаний нужно понимать, как это всё работает.

Денис, для начала разговора расскажите, как вы попали в сферу мобильных технологий и связали свою жизнь с GDG Moscow?

Как и многие мальчики, я с детства не расстаюсь с компьютерами и слежу постоянно за интересными гаджетами. Со школьных лет увлекался кастомными прошивками для телефонов. На факультете компьютерных наук, живя в Воронеже, начал изучать разработку по Android с написания курсовой и уже после третьего курса я устроился разработчиком под мобильные платформы. Потом начались различные конференции, так и познакомились с ребятами из GDG. Ну а когда переехал в Москву, с легкой руки лида московского GDG и при поддержке российского подразделнения Google я начал вести с моим коллегой курсы по Android StudyJam. Так, кстати 70 человек, посетившие наши курсы, смогли освоить Android. Мы планируем в конце года еще одни курсы, если кому-то интересно — пишите в комментариях. После курсов я прошел серию собеседований и получил статус Google Developer Expert.

Скажите, а в ближайшее время, помимо курсов, планируются какие-либо конференции с околомобильной тематикой?

Да, безусловно, будет с очень даже мобильной тематикой в конце сентября Droidcon Moscow. Я выступаю с докладом об особенностях адаптации приложений  под новую версию Android с кодовым названием «M» (что означает «Marshmallow», как выяснилось уже после интервью — прим. ред.).

А вы могли бы рассказать вкратце, что это за особенности?
В первую очередь, это новая обработка запросов приложением пользователя на получение доступам к различным  API, таким как камера, местоположение, смс и т.д. Но помимо этого, там есть несколько других менее заметных, но важных пунктов. Каких? Я расскажу на конференции, приходите!

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

А всем, у кого есть Nexus 5/6/9 я рекомендую уже скачать последний билд бета версии прошивки с Android M с официального сайта  и самим попробовать все новые фишки.

Спасибо за советы! Денис, а можете выделить основные тренды в разработке приложений на платформе Android в настоящее время?

Сейчас огромную популярность получило реактивное программирование. Если вы начинаете новое приложение, рекомендую посмотреть в сторону rxJava и rxAndroid. Ну и конечно, если ваши приложения не нарисованы и не анимированы по гайдлайнам Material Design — скорее это исправляйте, благо теперь для этого появилась удобная Support Design Library.

А скажите напоследок, где молодые разработчики могут находить интересные для них статьи и полезные материалы из мира разработки под Android?

Сейчас очень много источников и тысяча статей. Можно найти материалы в русскоязычном сообществе, даже книги на русском продаются в любом магазине. Но я рекомендую обращаться к первоисточникам, никогда не стесняться задать вопрос на SOF,  следить за новостями от разработчиков самой платформы  и подписаться на  Android Weekly. И, конечно, вступайте в наше GDG сообщество!

Расскажите, пожалуйста, чем вы занимаетесь в Parallels?

Я работаю над главным серверным продуктом Parallels под названием Cloud Server. Это специальным образом подготовленный для запуска виртуальных машин и контейнеров дистрибутив Linux, который аккуратно интегрирован с большим количеством дополнительных приложений от Parallels — управление кластером, распределенное хранилище, веб-панели и тому подобное. Продукт этот многокомпонентный, его составные части порой сами по себе являются очень сложными системами. Я занимаюсь тем, что проектирую многие из этих систем, главным образом связанные с ядром, их внутреннюю структуру, логику работы и взаимодействие друг с другом.

Кроме того, я организую процесс взаимодействия ядерной команды Parallels с сообществом разработчиков ядра Linux. Дело в том, что Parallels активно участвует в разработке подсистем контейнерной виртуализации в Linux, почти все наши специалисты что-то делают для ядра Линуса Торвальдса. Я за этой деятельностью слежу и пытаюсь направлять ее в нужное для компании русло.

Сегодня мое самое любимое занятие — развитие проекта CRIU, который получился из нашей работы с Linux-сообществом. Это приложение, которое умеет снимать состояние выполняющихся в Linux процессов и восстанавливать в другом месте или в другое время эти процессы из полученных данных.

Как возник проект CRIU? Что именно подтолкнуло к его созданию?

Проект возник как решение по интеграции контейнерного кода Parallels в ядро Linux. А сама интеграция — это тоже интересная история, которую я уже упомянул.
Спустя несколько лет после запуска проекта OpenVZ в Parallels поняли, что поддерживать все изменения, которые делались в ядре, своими силами будет очень тяжело.
Мы решили начать портировать наш контейнерный ядерный код на ядро Linux и отправлять эти изменения в сообщество с просьбой принять их к себе. Я тогда был просто разработчиком, и выбор «кто слать будет» пал на меня. Я начал портировать наш код на другое ядро, высылать эти изменения и разговаривать с людьми из сообщества на предмет принятия новой функциональности.

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

Первый прототип был написан примерно за три дня дома, пока я сидел на больничном. Я его выслал «на посмотреть» в сообщество. Люди посмотрели и… решили, что те небольшие изменения в ядре, которые мне понадобились, они берут (эти изменения через пару месяцев окончательно осели в ядре Linux).

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

Над какими проектами, связанными с ядром Linux, помимо CRIU, вы работаете? В каких проектах, не связанных с ядром Linux, принимаете участие?

Серьезно почти ни над какими и ни в каких. Того, что мне приходится делать в рамках OpenVZ, CRIU и нашей интеграции с ядром Linux, хватает с лихвой.

Вы упомянули проект OpenVZ. Расскажите, что это за проект? Какова степень вашего участия в нем?

С точки зрения софта, это ядро от Parallels + несколько утилит для его конфигурации, с помощью которых можно создавать и управлять Linux-контейнерами.
Кроме софта, это еще и такой (уже) бренд, с помощью которого Parallels заявляет о себе в мире Open Source. Вокруг проекта даже выросло средних размеров сообщество.
Степень моего участия в нем, судя по всему, немаленькая. Вскоре после того, как проект родился, меня «продвинули» с простого разработчика до лидера команды ядерщиков. И поскольку основное, что в то время было ценного в OpenVZ, — это ядро, то я де-факто стал еще и чем-то вроде технического лидера проекта. А еще через год стартовала упомянутая кампания по интеграции кода OpenVZ в ядро Linux, которая тоже проводилась под флагом OpenVZ и изначально легла на меня лично.

Сейчас ядро не является основной ценностью проекта (поскольку мы уже очень много интегрировали в ядро Linux, и, например, на Fedora 19 можно делать контейнеры без нашего ядра). Так что я вместе с менеджером проекта (Киром Колышкиным) занимаюсь тем, что придумываю, как можно двигать проект дальше, не «выезжая» на одном только ядре.
Одно из таких направлений — это, например, наш CRIU, который позиционируется как подпроект OpenVZ.

Какие возникли сложности в процессе интеграции кода OpenVZ в ядро Linux? С выхода какой версии ядра началась интеграция?

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

По-моему, это были пространства имен (namespaces) PID и SysVIPC. К 2.6.32, на котором у нас находилась следующая стабильная версия, были интегрированы сетевая виртуализация (net namespaces) и что-то еще.

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

Что нового в фундаментальном плане можно ожидать в ближайшие годы в области виртуализации?

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

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

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

Как происходило становление разработчика ядра? Какие возникли сложности на первоначальном этапе?

Началось все, кажется, на четвертом курсе института. Я тогда работал над академической распределенной файловой системой, и мой научный руководитель сказал, что в Parallels (тогда компания еще называлась SWsoft) собрались делать из этой системы коммерческий проект, и отправил поговорить со своим аспирантом, чтобы присоединиться к ним. Аспирант этот работал в команде Linux kernel, со мной провели собеседование и взяли в команду со словами: «С этой файловой системой мы попозже разберемся, начни пока с ядра». В итоге до системы у Parallels руки так и не дошли, так что я остался ядерным разработчиком.

Настоящие сложности возникли, когда мне пришлось писать код не для того ядра, которое разрабатывалось внутри Parallels, а для основного, которое делает Линус Торвальдс, и связано это было с тем, что модели разработки кода в Parallels и в сообществе кардинально различались.

В Parallels это более-менее стандартная разработка коммерческого кода. Работа в сообществе — совершенно другой процесс. Главной его особенностью, с моей точки зрения, является то, что это… не совсем процесс разработки ПО. Это главным образом общение людей, которым интересно создать большую и сложную программу, а собственно разработка там на втором месте. Осознание этого факта и подстройка под него и явились главными трудностями.

Над какими подсистемами ядра работаете?
Практически над всеми, кроме драйверов. Это в каком-то смысле одна из проблем — не получается глубоко и основательно погрузиться ни в одну из систем, приходится постоянно следить за развитием всех. Есть, правда, «любимые» системы — для меня это сетевой код и подсистема управления памятью.

Как происходит процесс включения ваших патчей в ядро? Каковы особенности этого процесса? В чем заключаются сложности?

Процесс выглядит одинаково для всех. Сначала надо сделать сам патч или их серию, написать комментарии к каждому (это, кстати, отдельное мастерство). Потом патч высылается в список рассылки, в котором обсуждается нужная подсистема ядра. В «копию» ставятся человек, который поддерживает подсистему (его по-английски называют maintainer), и люди, которые в ней разбираются и могут помочь оценить качество работы. Потом надо немного подождать. Если все сделано хорошо и всем все нравится, maintainer патч забирает себе в свой репозиторий. Потом Линус включает накопленное у всех maintainer в свое дерево.

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

К примеру, когда я начал отправлять части контейнерного кода в рассылки, мне приходилось переписывать код «с нуля» по нескольку раз. В итоге то, что сейчас есть у Линуса «про контейнеры», ни одной строчкой не похоже на то, что есть у нас, хотя и решает те же задачи.

Имеются ли стандарты на оформление кода для включения в ядро Linux? Если да, то не могли бы привести характерные примеры? Допускается ли отклонение от стандартов?

Стандарты, безусловно, есть. Даже написан специальный документ — Kernel Coding Style. В нем собраны все требования для оформления. Требования, надо сказать, очень разумные. К ним легко привыкнуть, и очень трудно потом начать писать (и читать) по-другому. Отклонения от стандарта, с одной стороны, допускаются, но, с другой, они все описаны в самом стандарте, так что можно сказать, что и нет.

Приходится ли писать на ассемблере для ядра Linux?

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

Как выглядит ваш рабочий день? Сколько времени посвящаете программированию, сколько проектированию?

Гм… Даже не могу представить, как выглядит средний рабочий день. Обычно рабочая неделя — это такой салат из различных «подумать», «порисовать», «покодить», «поговорить», «попереписываться», который я пытаюсь распределить во времени так, чтобы было как можно меньше переключений из одной деятельности на другую и чтобы люди, которые ожидают от меня каких-то действий, не ожидали их «вхолостую».

Какое программное обеспечение используете в работе? Рабочее окружение (GNOME, KDE, XFCE и т.п.), клиент электронной почты (может, связка веб-интерфейс/ почтовый клиент), веб-браузер, редактор, инструментарий разработчика (например, git)?

«Тюнингованный» (как водится) Fedora Linux. Ну и продукты Parallels, конечно. KDE и Gnome я не люблю, сразу ставлю себе FluxBox. Из графических приложений пользуюсь Thunderbird, Chrome, Skype. Периодически надо нарисовать слайды для очередной конференции. Пока возможностей OpenOffice хватает.
Остальное (даже мультики детям) запускаю в терминале.

Редактор VIM, а также стандартные инструменты разработчиков — make, git, svn, gcc, objdump, gdb.

Используете ли вы облачные сервисы в работе или личных целях? Если да, то какие?

Помимо google+ и hangouts, почти ничего. Я чаще на все эти сервисы смотрю «с другой стороны», чтобы почерпнуть темы для размышлений над нашими облачными продуктами ну или просто для «общего развития».

Как выглядит рабочее место? Есть ли особые предпочтения в выборе аппаратной части?

Стол, кресло, ноутбук. Предпочтение по аппаратуре только одно — у IBM ThinkPad очень удобная клавиатура и trackpoint.

Нередко разработчики говорят о том, что слушают ту или иную музыку во время работы. Как вы к этому относитесь? Какую музыку слушаете?

Зависит от того, что именно я «работаю». Если это что-то рутинное, типа просматривание рассылки за день, то можно что угодно. Если это кодирование, про которое уже ясно, что именно кодить, то музыка без слов, иначе трудно сконцентрироваться. Для более интеллектуальной деятельности предпочитаю тишину.

А явных предпочтений в музыке у меня, как мне кажется, нет — это и классика, и тяжелая музыка, и советский поп-рок-комплект, и какие-то случайные песни, которые по радио услышал.

Что вы могли бы посоветовать начинающим разработчикам ядра? Как снизить «порог вхождения» в процесс разработки?

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

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

Какие книги или источники вы можете порекомендовать для тех, кто начинает заниматься разработкой ядра?

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

Лучше освоиться с принципами функционирования аппаратных платформ и операционных систем и сразу «окунуться» в чтение кода.

Зато могу порекомендовать сайт kernelnewbies.org — для новичков в ядре это будет как минимум отличной и, главное, актуальной коллекцией ссылок на другие сайты, документацию и некоторое количество канонической литературы по ядру.

Беседовал Игорь Штомпель, журнал «Системный администратор»

Мы решили взять у Валерия небольшое интервью, он ответил нам на некоторые актуальные вопросы и просто рассказал о себе.

Редакция: не переживаете ли вы, что операцию отменят?

Валерий: Я вообще ни о чем не переживаю. Меня устроит любой поворот событий. Я буду знать, что сделал всё, что от меня зависело.

Откуда возьмете деньги на операцию?

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

Как оцениваете свои шансы на выживание?

Мы откроем результаты опытов с животными и вы сами оцените шансы. Но в любом случае — дело не только в моем выживании. Дело в научных данных.

Правдиво ли утверждение, что для вас это “безболезненный способ самоубийства”?

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

Как проводите свой день?

Я много работаю. На две компании. Удаленно. В основном занимаюсь только этим. Еще я каждый день нуждаюсь в помощи других людей. Кто-то приходит утром — поднимает меня с кровати в кресло. Кто-то — помогает делать всё остальное: душ, туалет. Поэтому приходится привязываться по времени еще и к ним.

Опишите свою жизнь несколькими словами.

Учеба. Дисциплина. Доброе отношение к людям. Интерес ко всему.

Какие три сайта в интернете чаще всего посещаете?

Хабр, Ютуб (люблю видео-лекции), Тапочек.нет ?

Какие три книги посоветуете подписчикам?

Всего Жюля Верна. Он здорово вдохновляет, в том числе и на инженерные поиски. “Я такой как все” Олега Тинькова. Толкиена “Властелина Колец”.

Редакция очень благодарна Валерию Спиридонову за интервью и желает удачи на операции.

Номер карты для сбора средств для осуществления проекта пересадки:

5469 1000 1137 3181

— МГУ, МГТУ им. Баумана, МИФИ, МАИ — это если перечислять московские. СПбГУ, Новосибирский Государственный Университет — довольно сильные учебные заведения в масштабе страны. Для меня, конечно же, Физтех ближе всех.

В России много отличных технических вузов, честно. Но, конечно, проблемы с IT-образованием, которое и появилось-то здесь лет 20 назад, в нашей стране есть. И инжиниринг программного обеспечения и computer science в нашей стране на уровне университетского образования — в зачаточном состоянии. Но, как это ни смешно, я не считаю это большой проблемой. Все-таки наша сфера молодая. И, соответственно, заниматься ей успешно можно, имея хорошее фундаментальное техническое образование. Вообще интересно было бы сделать соцопрос по крупным IT-компаниям и посмотреть, какие специальности получили их программисты и системные архитекторы. Уверен, что большинство закончили смежные факультеты: физфак, физмат, но не computer science. В компании Parallels (Сейчас Станислав старший вице-президент Acronis по проектированию и разработке — прим. ред.) работают программисты, закончившие Университет пищевых производств или геологический факультет МГУ.

— Достаточно ли одного вузовского образования для становления крепкого специалиста? Есть ли модель идеального образования для айтишника?

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

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

Второе: занимайтесь самообразованием всю жизнь. Нужно читать книжки профессиональные и смежные. У меня есть приятель, который работает экономистом в Чикаго, имеет PhD. Как-то раз ему пришла статья известного американского экономиста. Он знал всю терминологию, был в курсе последних изменений в этой области, но сложить все воедино не смог, и статью не понял. Он сохранил ее и стал каждые полгода перечитывать, чтобы понять, улучшается его понимание, или нет. И вот через три года, когда он все понял — оказалось, правильно написано, элементарно, ясно. То есть для того чтобы понять смысл прочитанного, все-таки нужно иметь определенный уровень.

— Над чем еще нужно поработать молодым программистам?

— Я бы посоветовал всем айтишникам интересоваться людьми. У многих технарей наблюдаются пониженные навыки социализации. Есть люди, талантливые ребята, иногда близкие к гениальности, но даже не с нулевыми, а с отрицательным уровнем коммуникации. Это значит, что парни не просто не умеют строить диалог, воспринимают слова собеседника противоположным образом. Когда таким человеком ужасаются, ему кажется, что его действия одобряют. Это непонимание людской природы — большая проблема, поэтому есть большой смысл получать дополнительное образование в области работы с людьми. Я не буду оригинальным — просто посоветую забить «книжки по психологии» в поисковике, наверняка среди них будут интересные. Я уверен, что поднимаясь вверх по карьерной лестнице, мы становимся отчасти менеджерами. А хороший менеджер умеет общаться, и ни в коем случае не социофоб.

— Какими навыками должен обладать выпускник вуза, чтобы получить у вас работу?

Я  всегда спрашиваю про средний балл выпускника. Это как соц. опрос: чтобы узнать, есть ли у кандидата ожирение, лучший вопрос, который можно придумать — «Сколько вы весите?».  Ответ выпускника в принципе ничего не определяет, но это хорошая общая информация.

Вторая вещь — это сообразительность. Сейчас в сети бродит много всяких задачек в стиле «сколько мойщиков окон требуется в Сан-Франциско». Мне хочется посмотреть на мыслительный процесс в действии, понять, как человек подходит к задаче, у которой неполные начальные условия. Естественно, прощупаю область, в которой парень считает себя асом. Зарплата,  взгляды на жизнь — это важно, но вторично. Основное, что требуется от выпускника, — это сообразительность, желание учиться, желание работать.

— На ваш взгляд, с чего лучше всего молодым начинать карьеру?

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

— А почему не стоит начинать в крупной компании?

Большую компанию от  маленького предприятия отличает очень размеренная жизнь и предсказуемое развитие карьеры. Шансы попасть на

Топ фло (top floor, англ.) — верхний этаж, ведущая позиция в карьерной лестнице.

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

— Вы можете назвать самые перспективные области в IT? Чем должна заниматься средняя компания, чтобы быть на плаву?

— Например,

Облака, облачные вычисления (англ. cloudcomputing) — модель потребления приложений или вычислительных ресурсов серверов через Интернет у провайдера.

. Всем уже понятно, что в индустрии произошел сдвиг к облачным сервисам. Мы сами не заметили, как стали хранить информацию в Dropbox, слушать музыку из VK или Spotify, а фотографии хостить на Flickr или Instagram. Все это облачные вычисления, где применений может быть гораздо больше, чем приложения для развлечений. Огромная индустрия облачных сервисов развернулась в сторону офисных и многих других приложений для малого бизнеса. Кроме этого — мобильные устройства. Сейчас люди покупают айпады, другие планшеты, переставая приобретать  ноутбуки и компьютеры. Как объяснил нынешний генеральный директор Apple, компания должна выпускать такой продукт, который съест долю других своих продуктов, чтобы этого не сделали другие. Поэтому мобильные приложения — это, безусловно, горячая область в IT.

Часть вторая. Work&travel: иммигрировать нельзя остаться

— Русские выпускники — айтишники проигрывают зарубежным?

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

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

— Ситуация с реальным оттоком сильно преувеличена. Да, люди уезжают, но не больше, чем раньше. Наверное, это происходит от низкого уровня компенсации труда в стране. Когда Parallels была маленькой и снимала помещение МФТИ, меня попросили почитать лекции студентам. Меня поразили ставки: они собирались платить мне 9 тысяч рублей в месяц плюс 6 тысяч за кандидатскую степень. Если бы я решил посвятить себя, например, преподаванию, то либо сам умер от голода, либо от меня ушла бы жена с детьми. Это большая проблема. Хотя я вижу, что разница в зарплатах IT-сферы медленно сокращается. Пятнадцать лет назад хороший программист в России стоил 500 долларов в месяц, в Америке — 6—7 тысяч долларов. Они жили в 12—14 раз лучше. Сейчас у топовых специалистов разница сократилась до 5—6 раз. В среднем сегменте дела обстоят так: хороший программист в Москве  сегодня зарабатывает от ста до ста пятидесяти тысяч рублей, 20—30 тысяч долларов в год без вычета налогов. В Америке программист такого уровня зарабатывает 120, максимум 150 тысяч долларов.

— Разница все равно существенная.

— Да, но в Америке и налоги в три раза выше. Еще раз повторяю, что она уменьшается. Мне кажется, что наша профессия чудесна, потому что не подвержена многим болезням общества. Люди мотивированы другими, правильными вещами. Вот бич многих российских предприятий — повальное воровство. В IT такого нет, ведь если человек украл компьютер и сел за пустой стол, то все заметили, что что-то с ним не так. И поэтому у нас нет многих проблем, которые считаются характерными для  России. Мы боремся за то, чтобы создавать продукты, которые конкурируют на главных рынках с продуктами лучших западных фирм. Это очень интересно, это захватывает. Я считаю, что IT может стать  той отраслью, которая во многом поможет России стать нормальной страной для жизни и если не вернуть таких как Новоселов обратно, то создать новых.

Спасибо компании Parallels за предоставленное интервью.

Владимир Иванов: Имея текущий опыт, что бы вы поменяли в разработке Linux 10 лет назад?

Джеймс Боттомли: Я не уверен, что поменял бы хоть что-то. Как упражнение, позволившее большому числу людей научиться разрабатывать, оно полностью себя оправдало и делалось довольно неплохо. Очевидно, мы были бы куда более профессиональным сообществом десять лет назад, если бы имели то, что имеем сейчас (жесткий контроль того, что делается в git репозитории и 2-х недельные циклы на внесение изменений в ядро Linux). Но думаю, нам нужно было научиться этому и пройти весь этот путь.

Андрей Карнаухов: Как вы смотрите на то, что .Net переезжает в OpenSource? И как вы считаете, почему в Microsoft пошли на это?

Джеймс Боттомли: Думаю, вы видели, в том числе из моего интервью, что мы двигаем собственные продукты OpenVZ и Parallels Cloud Server к модели open source. Может статься, Microsoft наконец-то осознал для себя прелести более открытой экосистемы. Я очень сомневаюсь, что здесь есть какой-либо другой мотив кроме желания увеличить использование .net как инструмента разработки, который, нужно отдать ему должное, очень распространен среди open source сообщества.

Юрій Якимчук: Посоветуйте какой-нибудь язык/технологию для изучения начинающим программистам, которые хотят приобщиться к миру OpenSource.

Джеймс Боттомли: Разрабатывать новую функциональность тяжело: нужно понимать, как работает сообщество изнутри, какие фичи сообщество примет, а какие не примет ни за что. Для этого нужно погрузиться в это с головой. Как новичку вам лучше всего начать с чего-ниб простого типа исправления багов. Это позволит вам продемонстрировать другим разработчикам сообщества ваши способности. Обычно для этого требуется всего лишь отправить патч в нужную ветку обсуждения.
Что касается языка или технологии, то выбирайте то, что нравится лично вам. Тот проект, над которым захочется работать, с большой долей вероятности сделает этот выбор за вас. Например, если хочется писать непосредственно в ядро Linux, то придется использовать С и т.д.

Сергей Гоголев: Есть ли у сообщества глобальные планы по развитию? Есть ли программы вовлечения молодежи в OpenSource?

Джеймс Боттомли: У сообщества нет глобальных планов. Большинство open source сообществ самоорганизующиеся, за исключением OpenStack, которое отличается большей структурированностью в вопросах планирования. Вообще вовлечением молодых людей занимается большое число сообществ. У команды, которая разрабатывает ядро, есть менторская программа, Gnome сам ищет талантливых людей. Большинство проектов имеют, как минимум, базовые how-to гиды, например, по документированию или тому, как отправлять патчи в ядро. Это тоже способ вовлечься. Нужно только что-то для этого делать.

Спасибо компании Parallels за возможность задать вопросы Джеймсу Боттомли.

Джеймс Боттомли: Linux-сообщество сегодня, спустя 23 года после своего основания, намного более разнообразно и также намного более профессионально, чем в самом начале своего существования. В сообществе насчитывается около 10 000 людей, 90% которых занимаются развитием ядра Linux, в том числе, нанятых именно для этих целей разными компаниями и считающих это своей основной работой. В самом начале такого не было.

Типичный: А от добровольного сообщества по интересам коммьюнити перешло к оплате труда? Я правильно понимаю, что сначала все это было бесплатно? Возможно, это разные модели управления людьми?

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

Я сам 23 года назад, в 1992 году, заинтересовался Linux, прежде всего, как операционной системой. Это было во время моей работы в Кембридже после защиты кандидатской диссертации. Тогда появился процессор Pentium, и мы обнаружили, что ПК на Pentium PC под Linux работает гораздо эффективнее, чем наши прежние рабочие станции, и при этом его цена составляет примерно 1/10 от их стоимости. Я подсчитал, что если мы купим 10 систем Linux по цене одного SPARC (наша предыдущая рабочая станция), то одну я могу оставить себе. И я помог создать первую программу для их инсталляции на рабочие места отделений математики и физики.

Так благодаря Linux у меня появился мой первый софт, который не только вызвал огромный интерес у людей, с которыми я работал, но и который я целиком создал своими собственными руками, и который при этом работал именно так, как я запланировал. Потом от хобби я перешел к профессиональной работе с Linux, а затем эта операционная система начала проникать (правда, в основном через черный вход) на бизнес-рынок, и использовалась сначала в основном для организации веб-сервисов, а затем и для создания веб-платформ, которые разрабатывали IBM и HP. Из-за этого и сам процесс, и сообщество становились все более профессиональными. А причина этого была очень прагматичная: если вы собираетесь основывать свой бизнес на операционных системах с открытым кодом, и вы при этом компания по производству оборудования (как IBM или HP), то вам понадобится полная поддержка своего программного и аппаратного обеспечения и всего, что с этим связано. Например, вам придется держать под своим контролем все: начиная от заботы о том, чтобы операционная система делала именно то, что вам нужно, до ваших собственных инженеров в штате, которыми управляете вы, но они при этом работают над софтом с открытым кодом.

Типичный: Правильно ли я понимаю, что открытый программный код в какой-то момент оказался более конкурентным для крупных компаний, чем платформы с закрытым кодом типа Microsoft и т.п.? Это было неким условием для того, чтобы заинтересовать компании работать с Linux или нет?

Джеймс Боттомли: У ответа на этот вопрос есть своя история. Вспомним старые деньки в восьмидесятые годы и даже чуть раньше: UNIX доминировала на рынке и была признанной операционной системой. Но проблема с UNIX была в том, что у каждой отдельной компании была своя версия. У HP было HP-UX, у IBM – AIX, и другие собственные коммерческие разновидности UNIX разных компаний – CLIX, IRIX, Solaris и так далее. И у всех этих компаний была своя разработка этих маленьких ОС, и все расходы по разработке и поддержке ложились на каждую такую компанию. И это не только снижало их доходность, но и долю их рынка, потому что, по сути, эти компании конкурировали и пытались дифференцироваться друг от друга с помощью практически одинаковых продуктов. Более того, это влияло и на их клиентов, которые несли огромные расходы, им приходилось покупать практически все у одного поставщика без возможности выбора – и ОС, и сопутствующий софт, и оборудование, и поддержку. Когда в середине девяностых появились новые универсальные платформы под ПК, они были в десять раз дешевле, чем эти UNIX-продукты. Все ожидали, что UNIX должен умереть хотя бы из-за этой ценовой политики. И действительно, вскоре пользовательское оборудование на базе Windows и Intel практически заменили его. Но тут Linux все испортил: он пришел как софт с открытым кодом – что означало его бесплатную установку. И при этом он был похож на UNIX – и программно, в плане кода (не нужно было заново обучать персонал работе с ним), и в том, что Linux можно было легко адаптировать под нужды своей компании. Вендорам «железа», которые работали с UNIX, потребовалось совсем не много, чтобы адаптировать свои продуктовые линейки под новые условия, и при этом снизить свои затраты. Поэтому они воспользовались стратегией работы с Linux и Intel – начали адаптировать Linux под то, что раньше выполнял UNIX. У них теперь была совместимая и универсальная платформа для всех продуктовых линеек, так что их клиенты больше не были ограничены необходимостью покупать дорогие и штучные системы. И можно было оптимизировать некоторые затраты, например, не платить полностью за поддержку своей собственной операционной системы и оборудования. При этом у каждой компании была одна и та же ОС Linux, но также возникла необходимость и вместе над ней работать. Модель поведения изменилась: вместо конкуренции разных операционных систем компании были вынуждены взаимодействовать, вместе работать над платформой Linux и поддерживать ее.

Я все это почувствовал на своем собственном опыте: сначала, когда я работал в университете в Кембридже, мы купили компьютер за десять тысяч фунтов. А потом мы уже могли купить десять систем Intel за те же деньги и запустить на них мощность в десять раз большие, чем мы запускали на своих тогдашних станциях SPARC, Alpha, MIPS и множестве других систем, которые мы покупали для вычислений. И он был цветным, что тогда не было так широко распространено на рынке UNIX.

Типичный: А какая сейчас бизнес-модель у Linux-сообщества, как оно зарабатывает и как тратит деньги? Как это распределяется сейчас?

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

Типичный: То есть я правильно понимаю, что компании обращаются к Linux-сообществу, и ставят конкретные задачи под свои нужды? То есть фактически платят разработчикам, чтобы они создали нужный компаниям софт?

Джеймс Боттомли: Нет, все по-другому. Linux – это то, что в общем-то доступно всем и так, это не сервис, за который нужно платить. Если приходят люди, которым требуется какая-то определенная функциональность, которой в Linux еще нет, которые хотят, чтобы linux сделал для них что-то новое, то они должны поступить по-другому. Во-первых, должны полностью проработать, что именно они хотят и что надо сделать, а затем убедить своих собственных инженеров это разработать (или заплатить каким-то другим инженерам, чтобы они разработали этот самый нужный код). А затем по определенным каналам придется убеждать Linux Comminity, что они должны включить этот код в ядро Linux.

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

Типичный: … поскольку идет перепроверка другими пользователями в сообществе.

Джеймс Боттомли: Да, и они отклонят этот код, более того, вы создадите себе этим и дурную репутацию, потому что они вполне могут продолжать отклонять ваш код, пока вы не научитесь делать все правильно. Это фактически очень и очень сильно отличает модель Linux от общепринятой отраслевой. Мы привыкли говорить клиентам, что мы производим лучший код, но часто даже в хорошо отработанной версии по-прежнему много «костылей», которых там быть не должно. А Linux фактически силой заставляет их производить их самый лучший код.

Типичный: У меня напрашивается аналогия с народной энциклопедией типа Википедии, где люди могут свободно предлагать свои статьи, которые будут потом редактироваться членами сообщества. Но, в отличие от Linux, статьи не всегда получаются на 100% высокого качества. Я хочу спросить, в чем различие между подходом в Википедии (условно) и в Linux-сообществе, ведь и там и там вроде бы есть некий условный аутсорсинг. И при этом конечный продукт у Википедии не всегда профессионального уровня, а у Linux это не так. Как вы избегаете каких-то ошибок, неточностей, как осуществляете контроль качества и так далее?

Джеймс Боттомли: С одной стороны, Linux – это операционная система, и ее качество легче увидеть, потому что она либо работает, либо нет  в отличие от Википедии, где коллективный разум пытается определить объективность, что само по себе субъективно. И также у нас есть не только сообщество людей, разрабатывающих Linux, но и сообщество людей, которые хотят попробовать то, что предлагается. У многих, как у меня, Linux стоит на ноутбуке, причем с самым последним ядром. Если что-то не работает, я кричу «Почему???» и требую, чтобы кто-нибудь удалил то, что вызвало проблему, или починил это. И вот такие люди как я тестируют Linux и на пользовательском, и на отраслевом уровне, в инфраструктурах больших компаний, в платформах или бизнес-продуктах. Это также важная часть контроля качества, потому что какие-то мелкие вещи инспекция в лице Linux-сообщества могла и пропустить. В Википедии если ты не понял статью, то можешь ее и пропустить, не читать, а в ядре Linux лишь очень немногие люди на самом деле понимают буквально все. А ведь есть и такая область, как драйверы устройств и тому подобные вещи, которые устанавливаются на компьютер. Вот почему так важно иметь именно диверсифицированную экосистему тестеров, которые также будут мониторить эту ОС на различном оборудовании. По крайней мере, всегда найдется несколько человек, которые проверят, как работает драйвер, и если найдут ошибку, то пришлют о ней отчет. С Википедией – если никто не читает статью, никого не интересует, что в ней написано, то не имеет значения, какого она качества.

Типичный: Тогда следующий вопрос, что мотивирует людей, работающих в сообществе?

Джеймс Боттомли: Это по-прежнему желание по-настоящему помочь с созданием операционной системы. Это всемирно известный софт с технологически сложными задачами и большими целями, и людям нравится быть причастными к этому, нравится создавать код, решать сложные проблемы. Работа над операционной системой – это как упражнение для талантливых людей. Есть ведь много людей, которым компании платят за то, чтобы они работали над их собственными операционными системами, но при этом в ответ они получают гораздо больше контроля, они связаны обязательствами перед нанимателями, сроками, целями проекта и так далее. Но заниматься микроменеджментом (фактически – стоять над душой) людей, которые работают с Linux в сообществе, гораздо тяжелее. Разработчики тоже люди, им нравится, что им благодарны, нравится внимание к ним. Авторские же права на продукт компании принадлежат компании, многие вещи закрыты по соглашениям о неразглашении коммерческой информации, а тут можно говорить на весь мир, что именно ты автор той или иной вещи, и общаться с такими же, как ты. В этом смысле инженерам точно гораздо больше нравится работать именно с открытым кодом.

Типичный: А как вы двигаете сообщество в нужном направлении?

Джеймс Боттомли: Глобально – просто нужны идеи, если они есть, то все возможно. Сообщество лучше всего откликается именно на удачные идеи, и люди типа меня все время делают все необходимое, чтобы эти хорошие идеи у них появлялись. Сообщество – это хороший вариант протестировать идею: хорошая она или нет, что работает, а что нет. Чья-то идея будет развиваться, а чья вызовет лишь разочарование, или пропадет, как камушек, брошенный в воду.

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

Parallels как раз пример такой компании. Например, Parallels уже около 15 лет работает в сфере контейнерной технологии виртуализации. В 2013 году на этот рынок пришел разработчик Docker и начал делать интересные вещи, которые получили много известности. Наш департамент маркетинга дал мне задание, чтобы я рассказал миру и о достижениях Parallels в области контейнеров, так как у нас их не меньше, чем у Docker. Поскольку Docker работает с программным обеспечением с открытым кодом, мы могли видеть, куда они двигаются. У нас были те же идеи, с которыми мы работали много лет, мы наблюдали за рынком и тоже видели, что он может откликнуться на идеи контейнерной виртуализации – в бизнес пришли облачные вычисления, а контейнеры в этой области дают гораздо больше плотности, гибкости, скорости отклика, чем любые другие решения виртуализации.

Поэтому нашей задачей стало сделать использование контейнеров на корпоративном рынке проще и легче. Один из вариантов это сделать – через OpenSource. Разработчики Docker делали почти то же самое, мы даже оба выпустили свои решения приблизительно в одно время. При фактической конкуренции на нас обоих взаимно повлияли идеи друг друга, и нам понравились идеи друг друга. И в результате через полтора месяца мы стали партнерами: анонсировали совместную разработку продукта, который сделает контейнеры удобным инструментом работы для разных компаний. Такая схема была бы невозможна в условиях закрытого кода. Если бы это была коммерческая разработка, то мы бы просто выпустили наши системы и начали думать о рыночном продвижении, пытаясь адаптировать один продукт к другому. Тогда проиграли бы мы, проиграл бы Docker, весь рынок контейнерной технологии проиграл бы. Но мы превратили угрозу в возможность.

Типичный: А не было ли такого, когда сообщество отвергало перспективную, но про на тот момент не оцененную идею?

Джеймс Боттомли: Да, иногда. Что вы можете сделать, если такое случилось? Что вам надо искать, так это use cases – сценарии использования. Рынок все время стремится к тому, чтобы все технологии стали потребительскими, но технологии всегда сами по себе немного забегают вперед. Если идея достаточно хорошая, вы можете понаблюдать за рынком: двигается ли он хотя бы чуть-чуть к вашей идее или нет. Если да, то нужно определить сценарии использования и еще раз попробовать продвинуть свою идею. И если она все-таки была верная, то на втором круге ее могут принять, такое на моей памяти пару раз случалось. Когда такое случалось в Parallels, мы говорили: ок, но нам это нужно по таким-то причинам. Если не срабатывает, то нужно рассказывать, зачем это нужно кому-то еще и по каким причинам. И поскольку это открытый код, то мы можем найти людей, которым это тоже нужно, и создать из них коалицию, которая скажет, что идея должна быть принята.

Мы так делали несколько раз, так произошло, например, с нашим проектом CRIU, который умеет снимать состояние выполняющихся в Linux процессов и восстанавливать их в другом месте или в другое время. Сегодня эта технология checkpoint-restore – основная технология миграции контейнеров. Но ее история не была гладкой. В 2010 году ее предложили ребята из Columbia University (а было и еще несколько других технологий, которые делали похожие вещи). И ее сначала отклонили, потому что она была реализована не в том виде, в котором было нужно. Но нам эта технология была жизненно необходима, иначе мы бы попросту не могли работать на рынке облачных вычислений. И тогда мы создали сообщество из всех людей, которые хотели эту технологию, и, раз ее не хотели включать в само ядро, то в Parallels ее реализовали в виде приложения к ядру (CRIU), которое можно было использовать на уровне пользователя, а приложение добавили в ядро при помощи патчей, а не напрямую. Фактически вошли не в парадную дверь, а с заднего крыльца. Так что со стратегической точки зрения вместо того, чтобы модифицировать ядро, мы модифицировали саму технологию checkpoint-restore, чтобы она работала на уровне процесса отладки, которая уже использовалась тогда и регулярно генерировала отчеты о состоянии системы. Мы расширили возможности интерфейса отладки, и теперь можно было воссоздавать состояние процессов, используя информацию от системы отладки. И в итоге 3 года спустя CRIU – это уже полнофункциональный продукт, на основе которого мы можем делать и бизнес-решения. Например, эта технология используется в нашем коммерческом решении Parallels Cloud Server.

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

Типичный: Знаете ли вы бизнесы, похожие по структуре на Linux?

Джеймс Боттомли: Очень много проектов с открытым кодом, похожих на сообщество Linux, но бизнес-компаний с похожей структурой я не встречал. Из проектов после Linux Community больше всего известен OpenStack, они создают совместно используемую платформу для управления облачными решениями, причем этим там тоже совместно занимается довольно много компаний, которые при этом на рынке конкурируют между собой.

Типичный: То есть опыт Linux можно тиражировать? Или в нем есть некая уникальная, скажем так, составляющая, которую растиражировать в других бизнесах нельзя?

Джеймс Боттомли: Определенно, можно тиражировать, и OpenStack уже это делает, и есть буквально сотни OpenSource-проектов, которые делают то же самое. Не все из них точно следуют модели сообщества Linux. В Linux Community есть она уникальная особенность, которой нет больше ни у кого – это Линус Торвальдс, который решает, что в итоге будет включено в платформу, а что – нет. Но большинство функций нашего сообщества они повторяют, хотя могут иметь множество различий в структуре. Например, у некоторых есть совет директоров, у некоторых – нет, есть разные типы лицензирования. Но если говорить в целом, то в софтверной отрасли сегодня OpenSource – это наиболее жизнеспособный метод сотрудничества для конкурентов-разработчиков.

Типичный: Не так часто такая кооперация людей приводит к конкретным результатам, есть очень много примеров, когда попытки организовать свободное OpenSource-сообщество или краудфандинг провалились. Готовые открытые продукты – это редкость. Реже, чем когда этим целенаправленно занимается корпорация. Поэтому интересен в этом смысле опыт Linux, в чем секрет?

Джеймс Боттомли: А секрет в том, чтобы всегда следовать своим собственным принципам. Для Linux секрет в том, чтобы всегда быть технологически честными, особенно во время инспекции своего программного кода, и всегда быть готовым ко всему, как в примере с нашей технологией CRIU, о которой мы говорили выше.

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

Спасибо компании Parallels за предоставленное интервью.

— Я генеральный директор и основатель EcmaSoft. Мы вышли на рынок в 2007 году и находимся в Санкт-Петербурге, Россия. Наша основная задача — разработка мобильных приложений. Также мы предоставляем услуги в веб-разработке.

— Какие факторы определяют сроки создания мобильного приложения?

— Два наиболее важных фактора — степень сложности приложения и количество разработчиков, необходимых для реализации проекта. Когда нужно максимально быстро сделать проект, мы используем 2-3 разработчика для одной платформы, это помогает сократить время разработки на 30-60%. Еще один фактор — информация и ресурсы, которые мы получаем от клиента. Если мы делаем все сами, от дизайна до API, это уменьшает вероятность задержек. Если клиент дает нам какие-то материалы, мы должны изучить их, понять, подходят ли они для реализации. Также в этом случае нам приходится ждать, пока клиент внесет исправления на основе наших предложений. Время, затрачиваемое клиентом на ревью и тестирование конечного продукта вместе с обзором Apple Store, также может повлиять на сроки выпуска приложения.

— Сколько времени в процентном соотношении уходит на разработку фронтенда и бэкенда для мобильного приложения?

— Разработка фронтенда занимает примерно 60% времени, бэкенда — 40%. Но это во многом зависит как от сложности самого приложения, так и от того, какие фреймворки или CMS используются для разработки серверной части.

— Какой бизнес-модели придерживается ваша компания: использование своей команды в офисе или привлечение сторонних поставщиков / аутсорсинг?

— У нас есть высококвалифицированная команда из двенадцати человек с опытом, необходимым для реализации каждого этапа проекта. Услуги, которые мы предоставляем по разработке мобильных приложений, включают в себя бизнес-анализ, создание вайрфреймов, создание прототипов, дизайн UI и UX, разработку iOS- и Android-приложений, создание API и тестирование конечного продукта. У нас есть все необходимые устройства для тестирования приложений: все версии iPhone и iPad, а также наиболее популярные Android-девайсы.

— Какие у вас основные преимущества по сравнению с другими компаниями на рынке?

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

— Какие отрасли бизнеса нуждаются в ваших услугах? Обращаются ли к вам клиенты повторно?

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

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

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

— На какой платформе, Android или iOS, вы советуете своим клиентам начинать работать, когда они приходят к вам со своими идеями, и почему?

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

— Android или iOS, Native или Hybrid — какую платформу лучше всего использовать для создания приложения? Что порекомендуете?

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

— Какую платформу и технологии вы предпочитаете использовать в разработке своих веб-приложений?

— Мы используем PHP-фреймворк Yii или Ruby on Rails — это очень гибкие инструменты, которые применимы для любого типа приложений от небольших интернет-магазинов до сложных веб-сервисов.

— Каким образом формируется конечная стоимость проекта и как происходит оплата?

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

— Есть ли у вас какие-то требования к минимальному бюджету для проекта?

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

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

— Все зависит от категории проекта. Лучшая модель, на мой взгляд, — это модель условно-бесплатного ПО, нацеленного на привлечение клиентов. При этом в приложение можно добавить рекламу и продавать какие-то дополнения с помощью in-app purchase.