Запрос счета
Заполните поля ниже, чтобы получить счет на оплату билетов DUMP от юридического лица
Юр.лицо
ИНН
Количество билетов на оффлайн-конференцию
+
Количество билетов на онлайн-трансляцию
+
Количество билетов на афтепати
+
Промокод (если есть)
Заявка на выступление
Имя и фамилия
Компания
Должность
Город
Ваш e-mail
Ваш телефон
Тема
Краткое описание
Какую ценность слушатели получат в итоге:
В какой секции хотите выступить
Напишите нам
Задайте вопрос, напишите пожелания или оставьте отзыв
Ваш e-mail
Ваше имя
Напишите здесь то, что хотели:
Заявка на спонсорство
Записи докладов DUMP 2021
Смотрите выступления, собравшие аншлаги
Темы и тезисы
Учиться, так учиться: 74 темы об IT-продуктах, разработке и разработчиках
Backend
Проблемы embedded или как мы от sqlite ушли
Михаил Беляев,
Прософт-Системы
Тезисы
Чистая Архитектура на практике
Андрей Цветцих,
EPAM Anywhere
Тезисы
Функциональные языки для бизнес-разработки
Роман Неволин,
Контур
Тезисы
Клиентский HTTP в .NET: дорога по граблям от WebRequest до SocketsHttpHandler
Евгений Пешков,
JetBrains
Тезисы
Как Яндекс.Афиша 2 раза переезжала на GraphQL
Александр Поляков,
Яндекс
Тезисы
Фичи для рекомендательной системы
Антон Шишкин,
SKB LAB
Тезисы
Kotlin как основной язык разработки бэкенда и обработки данных
Фагим Садыков,
SpectrumData
Тезисы
Аспектно-ориентированное программирование на C# и .net вчера, сегодня и завтра
Денис Цветцих,
Invent
Тезисы
Михаил Беляев, Прософт-Системы
Проблемы embedded или как мы от sqlite ушли
При embedded разработке существует очень большая проблема - это весьма ограниченные ресурсы устройства, на котором выполняется твой код. И в ходе разработки, когда запросы клиентов растут, а ресурсы embedded устройства на исходе, очень часто стандартные и проверенные решения не подходят и разработчик сталкивается с выбором: или сказать, что наше устройство не может справиться с требуемыми задачами, или сделать нестандартный ход и выиграть. Вот именно об этом процессе перехода от использования SQLite к собственному хранилищу данных, которое позволяет читать и писать данные значительно быстрее, и хотелось бы поведать другим разработчикам, которые, может быть так же, как и мы, столкнулись с данной проблемой, но отступили.

Слушатели познакомятся с проблемами embedded разработки, узнают о процессе решения проблем с производительностью при работе с данными (запись/чтение/хранение). Также узнают о развитии и текущей архитектуре нашего хранилища данных и, при желании, смогут использовать его в своих проектах, поскольку это открытый проект.
Андрей Цветцих, EPAM Anywhere
Clean Architecture in practice
С момента выхода книги Дяди Боба "Clean Architecture" прошло уже достаточно времени. Кто-то прочитал книгу, а кто-то только смотрел видео докладов на эту тему.
Докладов на youtube тоже хватает. Но все эти доклады идейные — вот как нужно делать и у вас все будет хорошо. При этом у авторов обычно нет практического опыта создания больших проектов по данной архитектуре (а еще запуска этих проектов в production). А все примеры — слишком простые и на практике все равно остается много вопросов.

Больше года назад мы начали 2 новых проекта, в которых применяли принципы, описанные в книге. Я готов поделиться нашим опытом.
Это корпоративные приложения на C# (API, backend). Enterprise который еще не успел стать кровавым :)
Но этого вполне достаточно чтобы получить первые результаты.
Роман Неволин, Контур
Функциональные языки для бизнес-разработки
Функциональные языки зачастую воспринимаются как красивые и модные игрушки — посмотреть и повертеть забавно, а вот в суровом энтерпрайзе им не место. Принято считать, что здесь лучше всего подходят проверенные годами, простые и надежные языки, такие как Java. Роман же с этим согласиться никак не может и постоянно пытается применить любимый функциональный язык — F# - к очередной бизнес-задачке.

В этом докладе мы поговорим о том, как Роман это делает, зачем оно ему (и всем остальным) нужно, и какие именно грабли он успел собрать на этом пути.
Александр Поляков, Яндекс
Как Яндекс.Афиша 2 раза переезжала на GraphQL
Мы расскажем о том, как переписали API Я.Афиша с REST на GraphQL на node.js + Python. А затем, в рамках оптимизации, избавились от node.js + Python и переписали весь GraphQL на Java.

Поясним, почему мы выбрали технологию GraphQL, какие проблемы и задачи решали с ее помощью. Расскажем и покажем как эволюционировала наша архитектура. Дадим несколько практических советов по тому, как лучше всего начинать работать с GraphQL. Расскажем для каких команд и проектов подходит наше решение, а для каких нет и почему.
Евгений Пешков, JetBrains
Клиентский HTTP в .NET: дорога по граблям от WebRequest до SocketsHttpHandler
На первый взгляд кажется, что отправить HTTP запрос - это очень просто. Тем не менее, даже HTTP/1.1 достаточно нетривиален - RFC на него содержит более 150 страниц, кроме того - браузеры уже поддерживают HTTP/2 и HTTP/3. Это не оставляет никакого выбора: стандартный клиент в платформе должен быть реализован на высоком уровне.

На пути от .NET Framework 1.0 к .NET 5 клиентские API для работы с HTTP и его реализации претерпели множество изменений. В некоторых версиях они были удачными, в некоторых же — провальными и явно временными.

В докладе я расскажу о истории развития клиентского HTTP API в .NET, его особенностях, о миграции приложений с Framework на Core с их учётом. Также разберу некоторые хаки, полезные при работе с ним. Заглянем в NuGet и рассмотрим представленные в нём обёртки над HTTP API с точки зрения эффективности и кроссплатформенности.
Антон Шишкин, SKB LAB
Фичи для рекомендательной системы
Расскажем про свой опыт построения рекомендательной системы от offline расчетов до online. Отдельно расскажу про то, как обеспечивается актуальность фичей для онлайн расчетов.

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

В компании SpectrumData Kotlin используется как основной (и по факту единственный) продуктовый язык разработки на платформе JVM для самого широкого круга задач: работа с данными, реализация микро-сервисной архитектуры, реализация бэкенда.

История успешного применения Kotlin в компании длится уже 4 года с версии языка 1.1.

Для SpectrumData характерно полноценное применение в своей кодобазе всех возможностей и рекомендованных практик по данному языку.

Прослушав доклад, слушатели смогут сделать вывод о реальной применимости и вариантах миграции на Kotlin с Java. Получат полноценное представление о самых сложных и неоднозначных аспектах использования Kotlin.
Денис Цветцих, Invent
Аспектно-ориентированное программирование на C# и .net вчера, сегодня и завтра
Аспектно-ориентированное программирование (АОП) позволяет без дублирования кода добавлять инфраструктурный функционал вроде кеширования и логирования на разные слои вашего приложения. И все это — не меняя уже написанный код! Это очень мощная, удобная… а также редко используемая техника.

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

В своем докладе Денис делится 10-летним опытом использования АОП на C# и .NET. Расскажет о подходах к реализации АОП, а также покажет, как менялись инструменты для разработки аспектов вместе с языком программирования и платформой.

Естественно, он предложит наиболее оптимальный на сегодня вариант реализации аспектов. И вместе подумаем, какими хотелось бы видеть инструменты для разработки аспекты в будущем. Примеры будут на C# и .NET, но идеи доклада будут актуальны для любой платформы.
Frontend
Трасси... что?
Алексей Охрименко
Яндекс Музыка
Тезисы
Нужен ли нам N(e/u)xt.js?
Григорий Петров,
Evrone
Тезисы
RTC и Франкенштейн
Полина Гуртовая,
Evil Martians
Тезисы
Стейт машины спешат на помощь
Роман Омельницкий,
Яндекс
Тезисы
React: Lifting state up is killing your app
Андрей Гончаров,
Hazelcast
Тезисы
Е2Е тесты в браузеры. Когда Cypress, а когда не очень
Леонид Семёнов
InvestEngine
Тезисы
Как создавать React компоненты, которыми будет приятно пользоваться
Роман Лысов,
Semrush
Тезисы
Как тестировать фронтенд без тестировщиков и спать спокойно
Людмила Мжачих,
Mail.Ru Group
Тезисы
Григорий Петров, Evrone
Нужен ли нам N(e/u)xt.js?
Современный фронтенд — это сложно. Если легаси проекты ограничены "что есть — то есть", то для новых приложений, кроме настройки Webpack и Babel, у нас есть HMR, SSR, code splitting, routing, кеширование, stream rendering — и это, не считая, собственно, фронтенд фреймворка и бэкенда, CI/CD и деплоя.
HMR "ломается" на приложениях сложнее hello world, настройку SSR в интернетах хором называют "адски сложной", ну, а роутинг, в уважающей себя связке фронт+бэк, можно неправильно организовать десятью конкурирующими способами.
Вся эта сложность породила новое направление "jamstack", и такие решения, как Next.js и Nuxt.js — "opinionated фреймворки", где все настроено за нас.

В докладе я использую эти два фреймворка, чтобы рассказать об основных сложностях современной фронтенд-разработки и то, как мы можем с ними бороться: готовыми шаблонами, собственным кодом или новыми архитектурами приложений. Сложности я буду показывать с позиции "почему так получилось?". Ради чего мы мучаемся с настройкой Webpack? Почему реализация SSR требует писать столько кода и нужен ли он нам вообще такой ценой? Кто виноват и что мы, как разработчики, можем сделать?
Полина Гуртовая, Evil Martians
RTC и Франкенштейн
Расскажу об особенностях использования WebRTC для боевых задач, опишу проблемы, которые поджидают разработчиков, и покажу способы их преодолевать
Роман Омельницкий, Яндекс
Стейт машины спешат на помощь
Когда приложение растёт и интерфейсы усложняются классический подход к стейт менеджменту показывает себя не так хорошо.

В докладе я расскажу что такое конечные автоматы и стейтчарты и как они могут помочь нам писать более чистую и прозрачную логику. Покажу как их применять и какие готовые решения существуют и что они позволяют сделать.
Ведь возможности впечатляют: прототипирование и синхронизация с дизайном, управление сложными блоками интерфейса, помощь с сборе аналитики и тестировании, документирование поведения и анимации.
Андрей Гончаров, Hazelcast
Lifting state up is killing your app
Слышали ли вы про "lifting state up"? Может ли одна из двенадцати ключевых концепций в официальной документации React приводить в плохой производительности? В рамках доклада мы сделаем простейший grid на React. Поэтапно разберем возникающие проблемы производительности. Увидим, что иногда и O(1) - это недостаточно быстро. Будем профилировать и рефакторить до тех пор, пока приложение не станет работать бестрее, чем вы успеете сказать "React".
Алексей Охрименко, Яндекс Музыка
Трасси... что?
Отладка приложения занимает 99% нашего времени. Кто-то пользуется Chrome DevTools, кто-то обходится обычным console.log, кто-то использует профайлеры. Зачастую этих инструментов более чем достаточно. Но есть еще один, не особо известный и популярный в JavaScript мире.

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

В этом докладе я расскажу о плюсах и минусах трассировки, существующих инструментах, и поделюсь советами, которые мне помогали справляться даже с самой сложной кодовой базой.
Леонид Семёнов, InvestEngine
Е2Е тесты в браузеры. Когда Cypress, а когда не очень
Что делать если ошибки в проде смертельны, а релизы идут каждый день?
Как спастись от бессонных ночей, панической боязни сломать прод, и не страдать при этом от тестирования?
Ответов может быть много, но, кажется, что очевиден один — автотесты!
Как внедрить автоматизированное сквозное тестирование?
О двух внедрениях, двух инструментах, одном путешествии, проблемах по пути и о самом пути вы тут и узнаете.
Роман Лысов, Semrush
Как создавать React компоненты, которыми будет приятно пользоваться
Проблема кастомизации компонентов и их использовании друг с другом всегда болезненна, мы у себя в компании решили эту проблему.

Мой доклад основан на 4-х летнем опыте создания дизайн-системы для большого числа разработчиков.

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

В своем докладе я расскажу о нашем опыте скрещивания тестирования и разработки, о том, как мы автоматизировали регрессионное тестирование, какие инструменты использовали, с какими сложностями столкнулись и что из всего это вышло.
Product
Быстрый сбор глубоких интервью с большим рычажным эффектом
Сергей Абдульманов,
Управляет собственным PR-агентством Loft, а также занимается спецпроектами в Туту.ру
Тезисы
Соотношение ценности продукта и сервиса. Что важнее: эмоции или качество?
Сергей Герштейн,
Кнопка
Тезисы
Пользовательские сценарии на контенте. Говорение как способ растить продуктовые метрики
Наталья Бондарь,
Ridero
Тезисы
Новый рынок для продукта или как начать с нуля не начиная с нуля
Нюта Блиничева,
Яндекс.Практикум
Тезисы
Компетенции продуктовой команды при выходе на новые рынки (новая ниша или география)
Елизавета Кондрашова
ФРИИ
Тезисы
Продуктовая разработка и маркетинг на больших поисковых данных
Илья Телегин,
Scalekarma
Тезисы
Как продакту фокус держать
Евгений Гурьянов
BestDoctor
Тезисы
10 вредных советов продакту. Как не расти самому и угробить продукт?
Дмитрий Павлов,
Dodo Engineering
Тезисы
Сергей Абдульманов, Loft, а также занимается спецпроектами в Туту.ру
Быстрый сбор глубоких интервью с большим рычажным эффектом
В этом докладе будет много концентрированной пользы.

Я расскажу:
  • Зачем проводятся глубокие интервью и как это делается обычно
  • Какие бывают инсайты: практические примеры и польза от них
  • Что будет, если применить мозг для решения 80% задачи
  • Как правильно разговаривать с клиентской базой
  • Особенности формата, которые увеличивают отклик в 2,5 раза
  • Правила обработки результатов
  • Создание ядра лояльной аудитории
  • Использование результатов интервью дальше
Только самое важное — без bullshit'а.
Илья Телегин, Scalekarma
Продуктовая разработка и маркетинг на больших поисковых данных
Без булшита поговорим о том, как синхронизировать продуктовое видение с реальностью и маркетингом.

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

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

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

Приходите, обсудим практические подходы и инструменты.
Сергей Герштейн, Кнопка
Соотношение ценности продукта и сервиса. Что важнее: эмоции или качество?
У продукта-услуги есть объективные параметры качества, а есть субъективно воспринимаемая клиентом "сервисность". Например, объективными параметрами могут быть скорость ответа клиенту, качество консультации, отсутствие ошибок, выполнение запланированных действий в срок и т.п.

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

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

И вот главная проблема: как определить оптимальный уровень затрат на "сервисность" и их влияние на доход/прибыль от продукта?

Мы поговорим вот о чем:

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

Все это поможет прийти к важному выводу - когда инвестировать в продукт, а когда в его сервисную обёртку.
Полина Чижова, exAvito, exAliexpress
Поколения Z и А: инсайты, паттерны и прогнозы
Поколение X и миллениалов, кажется, все давно хорошо изучили. Но на смену им подросли поколения Z и A. Это не просто разделение молодых людей по году рождения, их особенностям поведения и привычкам - хотя это само по себе интересно. Еще это будущая аудитория ваших продуктов, поэтому важно знать о них и учитывать их потребности уже сейчас.

В докладе будет много интересного:

  • Кто такие поколения Z и А: их общая характеристика.

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

  • Рассмотрим что можно сделать уже сейчас, чтобы быть ближе к этому рынку.

  • Маркетинг и продукт: как можно переиспользовать мировые практики, если у вас небольшой бизнес или вы далеки от корпораций?

  • Как продуктологу можно проверить гипотезы по изменению продукта для поколения Z и А? Какие есть подводные камни?
Наталья Бондарь, Ridero
Пользовательские сценарии на контенте. Говорение как способ растить продуктовые метрики
А вы умеете правильно рассказывать о продукте? Так, чтобы его полюбили? Так, чтобы он приводил пользователей, которые принесут деньги?

Расскажу, как говорение о продукте влияет на метрики:

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

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

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

Поделюсь на кейсах болей и радостей Яндекс.Практикума в США и других.
Елизавета Кондрашова, ФРИИ
Компетенции продуктовой команды при выходе на новые рынки (новая ниша или география)
Что важно для продуктовой команды при выводе продукта на новый рынок

В докладе будет много полезного:
- о том, как оценить наличие продуктовых компетенций в команде
- матрица компетенций продакта: что ключевое для core команды, а что можно купить «на месте»
- про самодиагностику команды исходя в зависимости от сегмента b2b/b2c
- интересные факап-истории про выход на международный рынок
- как подращивать в команде продактов заранее
- инсайты и статистика по компетенциям продактов на рынке России
Евгений Гурьянов, BestDoctor
Как продакту фокус держать
Проблема

Как часто к вам на работе прилетают чайка-менеджеры и просят "запилить" что-то в продукте? Каждую неделю? Каждый день? Или каждый час? У вас много "неравнодушных" коллег, которым всегда срочно что-то нужно от продукта, хотя это что-то явно менее приоритетнее ваших текущих активностей? А может даже и вредно для бизнеса? При этом у вас есть стратегия, вы живете по OKR, приоритеты и фокусы (как долгосрочные, так и краткосрочные) расставлены и согласованы?

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

Если описанные ситуации близки вам, то приходите на мое выступление. Поведаю о том, как существовать в этом жестоком продуктовом мире. Ну и держать фокус))

Тезисы

Сначала я расскажу про методы удержания фокуса.

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

В заключительной части выступления мы поговорим про коммуникацию: Как правильно сказать Нет в том или ином случае? Без риска для жизни.

Ценность для слушателя

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

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

Дмитрий Павлов, Dodo Engineering
10 вредных советов продакту. Как не расти самому и угробить продукт?
В апреле 2011 года у нас была 1 пиццерия в Сыктывкаре. В 2017 году 160+ пиццерий и 10 стран.

Сейчас в нашей сети 696 пиццерий (а на момент моего выступления уже будет 700+, хорошо, что презентацию можно поменять ???? ) и 2 новых концепции Drinkit и Doner 42. Эти концепции мы запустили в прошлом году. При этом информационная система Dodo IS остаётся одна и для стран, и для новых концепций.

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

В докладе я расскажу как росли продакт оунеры и менялась их ответственность за последние 3 года. Посмотрим, где и как мы огребали и какие выводы сделали. Обсудим, к чему мы в итоге пришли, чтобы развивать глобальные продукты для нескольких рынков и концепций.
Team
Книга рецептов: 20 инсайтов, как повысить эффективность с помощью Objective and Key Results
Толя Коротков,
Scrumtrek
Тезисы
Пандемия против психики: как мы справлялись и справились ли
Витя Степанов,
Контур
Тезисы
Performance review: инструмент для повышения личной и командной эффективности
Артем Сусеков,
Miro
Тезисы
Говорите, пожалуйста! Как построить эффективную коммуникацию в команде
Илья Якямсев,
Компания Wiley
Тезисы
Физиология мозга: рычаги управления личной эффективностью
Григорий Петров
Evrone
Тезисы
Что такое wellbeing и почему концепция благополучия важна для современного бизнеса
Влад Вишняков
DataArt
Тезисы
Люди и команды
Леонид Черный,
Мегафон
Тезисы
Мы строили, строили и наконец построили. Как бизнес и ИТ научились работать вместе
Дмитрий Павлов,
Dodo Engineering
Тезисы
Толя Коротков, Scrumtrek
Книга рецептов: 20 инсайтов, как повысить эффективность с помощью Objective and Key Results
Про OKR знают все, кто управляет проектами и продуктами.

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

Но умеете ли вы применять OKR максимально эффективно?

В докладе я поделюсь инсайтами и нашим опытом.

Вот часть рецептов:

  • Ускорение узких функций через сквозное целеполагание.
  • Объединение компаний через общие цели.
  • Фокус на кратный рост.
  • Балансировка KPI и OKR и тд.
Витя Степанов, Контур
Пандемия против психики: как мы справлялись и справились ли
  • Ковидные изменения в картине психологических неприятностей глазами корпоративного психолога.
  • Первоначальная паника: как развивалась, к чему приводила, чем боролись.
  • Выгорание: новый путь формирования.
  • Эпидемия самозванничества и чем ещё чревата удалёнка.
  • Проблемы в личной жизни: почему так пышно расцвели, и все ли плоды поспели.

Всё это с кучей примеров, глубокомысленными выводами и рекомендациями.
Артем Сусеков, Miro
Performance review: инструмент для повышения личной и командной эффективности
Быстрый рост команды влечет за собой проблемы с оценкой людей.

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

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

Разумеется, не всё было гладко. По пути мы наломали дров и иногда было очень больно. В докладе расскажу о том, как мы запускали Performance Review, какую систему грейдов разработали и почему, как всё это коснулось вопросов зарплаты и как повлияли все эти изменения на эффективность команд.
Илья Якямсев, Wiley
Говорите, пожалуйста! Как построить эффективную коммуникацию в команде
О том, как создать хорошую атмосферу в команде, грамотно использовать мессенджеры, сократить количество встреч и быть нормальными людьми и внутри, и снаружи
Григорий Петров, Evrone
Физиология мозга: рычаги управления личной эффективностью
Обилие книг "как стать эффективным и добиться успешного успеха" намекает, что с эффективностью не все хорошо. Мы что-то делаем, а через неделю или месяц понимаем, что никак не приблизились к нашим целям. Читаем книги о прокрастинации, целеполагании, эффективности. Снова что-то делаем и снова недовольны результатом.

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

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

А предсказательную силу я проиллюстрирую с помощью прокрастинации и целеполагания, раз уж так заведено. Но доклад все равно не о них, а о том, "как же оно может внутри работать, что вот такая фигня в конце каждого дня получается".
Влад Вишняков, DataArt
Что такое wellbeing и почему концепция благополучия важна для современного бизнеса
Зачем заботиться о коллегах? Мифы и легенды о концепции благополучия.

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

Хорошо ли это, когда уровень текучести в компании в полтора раза ниже среднего по индустрии?

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

Расскажу на примере DataArt — компании из нескольких тысяч человек и сотен команд, практически все инструменты можно использовать и в коллективах меньшего размера.
Леонид Чёрный, МегаФон
Люди и команды
Доклад будет о более глубоких проблемах менеджеров - когда основные процессы уже выстроены, а основные болячки уже полечены.

Мы поговорим:

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

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

  • про работу менеджера в связке внешних и внутренних процессов. Когда компания диктует одни процессы, а в команде приняты другие - как менеджеру обеспечить этот буфер.
Дмитрий Павлов, Dodo Engineering
Мы строили, строили и наконец построили. Как бизнес и ИТ научились работать вместе
Январь 2020. Команда международного развития.

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

Разработчики пилят технические задачки, изредка узнавая у бизнеса - а как там дела (не, иногда ещё помогают Лёше с запуском новой страны). У каждого свой бэклог задач, все при делах и заняты.

Идиллия?

Как бы не так. Таски мутятся, но прорыва на международных рынках нет.

Как быть?

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

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

В докладе я расскажу, как строили единую команду ИТ+бизнес, на какие грабли наступали, как работали с возражениями, к чему в итоге пришли. Например, поделюсь, как мы пришли к общим квартальным планированиям и обзорам спринта, как теперь ставим общие цели и OKR на 17 человек, приведу пару примеров, показывающих, насколько разработчики глубоко погружены в бизнес и могут самостоятельно предлагать топовые решения.
О чем речь?
Профессиональное выгорание тимлида
Mobile
«Разработка на моках»
Александр Кравченков,
Surf
Тезисы
Жизнь вслепую: разрабатываем устройство без экрана
Виктор Лапин,
Адвантум
Тезисы
Осознанная меркантильность (работа по совместительству)
Антон Назаров,
Самозанятый
Тезисы
Declarative UI и Figma: ускоряйся!
Владимир Иванов,
Тинькофф
Тезисы
The Swarm
Денис Малых,
Яндекс
Тезисы
Null Safety
Александр Денисов,
EPAM
Тезисы
Писать или не писать (тесты на Flutter)? Вот в чём вопрос…
Евгений Сатуров,
Surf
Тезисы
Боль и спасение в snapshot тестах
Вячеслав Бельтюков,
Joom
Тезисы
Александр Кравченков, Surf, iOS Team Lead
«Разработка на моках»
Часто при разработке мобильных приложений разработчики попадают в ситуацию, когда бэкенд не работает. Причин этому много, однако итог один — разработка затягивается.

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

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

Слушатели увидят еще один системный путь решения «проблем с сервером» (а не просто «писать заглушки на клиенте»), узнают принцип работы, получат референс на готовый инструмент и поймут как подобные инструменты могут решать смежные проблемы (например, проблемы тестирования).
Виктор Лапин, Адвантум, руководитель группы мобильной разработки
Жизнь вслепую: разрабатываем устройство без экрана
Все Android разработчики уже успели привыкнуть, что их приложения будут видны на экране устройства пользователя. А что делать, если у конечного устройства нет экрана? Виктор поделится опытом разработки железа на Android (прошивки) с предустановленными бизнес-приложениями. Экрана у устройства нет, поэтому нужно обработать множество ситуаций, которые на смартфоне делаются парой нажатий на кнопки.
Денис Малых, Яндекс
The Swarm
Мобильные устройства стали достаточно мощными, чтобы из разряда тонких клиентов перейти во что-то большее. Мы все привыкли к тому, что приложения — это клиенты к облаку, но "облака" теперь можно строить и на базе самих мобильных устройств, а также есть приложения, которые справятся со свой задачей и без облака.

В моем докладе посмотрим, что есть уже сейчас, и перспективные технологии в части децентрализованных приложений и то, как такие приложения можно строить (с небольшими математическими и алгоритмическим подробностями).
Владимир Иванов, архитектор продукта, Тинькофф
Declarative UI и Figma: ускоряйся!
Менеджеры проектов ожидают, что UI, который делают разработчики, в точности соответствует макетам дизайнера. На практике это не так: то шрифт не тот стоит, то отступ пропущен, то с цветом лажа. Дизайнерам приходится проверять результат вручную, а разработчикам исправлять замечания.
Такой процесс замедляет поставку продукта к пользователям, отчего недовольны все.
Хорошая новость в том, что сочетания декларативных UI фреймворков и Figma может помочь избавиться от этих проблем!
В докладе мы увидим, как с помощью процессных и технических решений преобразить процесс верстки и дизайн ревью и сделать всех довольными.
Антон Назаров, Самозанятый, iOS разработчик
Осознанная меркантильность (работа по совместительству)
В нашей индустрии популяризируется качественный способ карьерного роста: учись, бери больше ответственности, упрись в зарплатный потолок.

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

Начнем с предпосылок к параллельной работе в нескольких компаниях. Обсудим первые шаги, послушаем истории других людей, решившихся получать несколько зарплат в месяц. Пофилософствуем об алчности, цинизме и совести. Я поделюсь проблемами и моральными дилеммами, которые пережил за два года совмещения. После доклада ты либо начнешь искать дополнительную работу, либо раз и навсегда откажешься от такого способа увеличения дохода.
Александр Денисов,
EPAM
Null Safety
Язык Dart для разработки на Flutter выбран не просто так, он играет особенную роль.

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

Причем Dart развивается и меняется очень быстро. Всего пару лет назад он сменил динамическую типизацию на статическую, оброс кучей других фич, таких как extension methods. А не так давно была анонсирована новая фича языка — Null Safety.

В докладе я расскажу о том, что такое Null Safety, чем она может помочь в разработке, какие сложности могут вас ждать при миграции и чем реализация в Dart похожа, а чем отлична от Kotlin и Swift реализаций.
Евгений Сатуров,
Surf
Писать или не писать (тесты на Flutter)? Вот в чём вопрос…
Тесты нужно и важно писать. Сегодня с этим уже мало кто спорит. Если технология обладает развитой инфраструктурой для тестирования кода, это выгодно отличает её на фоне альтернатив. Как с этим обстоят дела у Flutter?


В ходе доклада я расскажу:
- Какие виды тестов можно писать на Flutter и на чём стоит сфокусироваться в первую очередь;
- Что такое виджет-тесты и как можно тестировать UI не запуская приложения;
- Зачем тестировать виджеты в изоляции от окружения;
- Как писать unit-тесты на всё, включая асинхронный Dart-код;
- Что не стоит пытаться покрыть тестами, потому что всё равно не получится;
- Как писать кастомные матчеры и что с ними потом делать;
- Как лучше всего мокировать данные;
- Почему сделать снимок состояния тестового покрытия кодовой базы проекта — нетривиальная задача;
- Как писать код на Flutter так, чтобы его можно было протестировать.
Вячеслав Бельтюков,
Joom
Боль и спасение в snapshot тестах
Как часто у вас расползался интерфейс приложения? А как много времени нужно тестировщику, чтобы проверить все состояния экрана?

Решить эти и другие проблемы могут (или нет) snapshot тесты.

На примере Joom посмотрим, как выглядит их внедрение, какие боли лечит, а какие создает.
Design
Фокус с фокусом
Павел Колодяжный,
pavel.live
Тезисы
Три инструмента ТРИЗ в практике проектировщика интерфейса
Андрей Шапиро,
Byndyusoft
Тезисы
Специфика работы с детской аудиторией: что должен уметь дизайнер, чтобы создавать проекты для детей?
Александр Устинов,
BeaversBrothers
Тезисы
Проектирование сложных B2B-сервисов в деревне Виллабаджо
Дарья Почекуева,
Почтатех
Тезисы
Диалоговый дизайн голосовых ассистентов
Тамара Персикова,
Тинькофф
Тезисы
Масштабирование навыков дизайнера в продукте
Мила Иванова,
Artsofte
Тезисы
Генеративный дизайн: меньше работать, больше творить
Александр Обанин,
DD Planet
Тезисы
Особенности дизайна мобильных приложений
Олег Пирогов,
Сбер
Тезисы
Павел Колодяжный, pavel.live
Фокус с фокусом
О важности фокусировки и концентрации знают все. Но как переключать себя в это состояние?
Особенно тогда когда нужно? Расскажу такой рецепт. Простой и понятный алгоритм действий.
Андрей Шапиро, Byndyusoft
Три инструмента ТРИЗ в практике проектировщика интерфейса
Теория решения изобретательских задач (ТРИЗ) на слуху в дизайнерской среде, однако мало кто владеет конкретными практиками. Прочитав две книги по этой теме, я всё ещё сильно «плавал» и не мог применять теорию. Только погружение в практику современной ТРИЗ дало навык решения задач.

В докладе рассмотрю три метода в приложении к дизайнерским задачам. Этими методами будут:
  1. причинно-следственный анализ;
  2. оператор «идеальный конечный результат»;
  3. графическая форма технического противоречия.
Звучит жутко, но инструмент даёт мощнейший.
Александр Устинов, BeaversBrothers
Специфика работы с детской аудиторией: что должен уметь дизайнер, чтобы создавать проекты для детей?
Основные вопросы, на которые я отвечу по ходу доклада:

  • Что должен уметь дизайнер, чтобы создавать игровые проекты для детей?
  • Как проводить исследование, чтобы понять, какие игры могут быть интересны детям?
  • Какие исследования можно делать онлайн, а что обязательно нужно делать оффлайн?
  • Как рассказать детям о сложном просто?
  • Как придумывать игровой сюжет?
  • Как придумать интересных героев?
  • Как тестировать идеи на детях?
А еще поговорим о том, какие навыки UX/UI дизайнера помогают создавать игры для детей, а какие мешают. Почему в создании игр для детей дизайнер должен быть сценаристом, режиссёром, исследователем? Можно ли совмещать в себе эти навыки и какой из них самый главный?
Дмитрий Бровка, Яндекс
Три проблемы разработки, которые решит дизайн-система
Растущее количество интерфейсов требует серьёзной дисциплины. Высокий темп трансформации сервисов невозможен без слаженной работы и быстрой доставки обновлений до пользователей. Мы нашли решение в разработке дизайн-системы и инфраструктуры вокруг неё.

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

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

Доклад будет интересен дизайнерам, которые ищут способы организовать свою работу с нуля, когда вокруг хаос и не на что опереться.
Тамара Персикова, Тинькофф
Диалоговый дизайн голосовых ассистентов
Тренд на голосовые интерфейсы не стихает, но окружен смесью хайпа и скепсиса. Кому и зачем нужен голос? Voice first или voice only? Почему боты такие тупые? И как сделать их лучше?

На докладе я расскажу о:
  • дизайне диалогов — процессе на стыке продуктового дизайна и редактуры, который учит голосовых ассистентов решать задачи клиентов;
  • молекулах и атомах проектирования процедур для бота;
  • клиентских путях и процессе UX-исследований для голоса;
  • юзкейсах и ЦА голоса;
  • истории и перспективах дизайна VUI.

Доклад будет интересен тем, кто не знаком с ML, и хочет узнать, как работает диалоговый дизайн.
Мила Иванова, Artsofte
Масштабирование навыков дизайнера в продукте
  • Какие важные для профессии навыки развиваются в фоновом режиме?
  • Можно ли их осознанно масштабировать?
  • Как понять свою ценность для компании и презентовать её команде?

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

Я расскажу про две стороны применения генеративного дизайна.

  • Первая — автоматизация процессов для тиражирования дизайна.
  • Вторая — использование компьютера как творческого инструмента, помощь дизайнеру в создании новых визуальных элементов.
Олег Пирогов, Сбер
Особенности дизайна мобильных приложений
Поговорим о пяти основных моментах, которые нужно учитывать при дизайне мобильных приложений.
1. Моторные, визуальные и когнитивные нагрузки
2. Контекст использования и способ взаимодействия
3. Привычные паттерны пользователей и платформ
4. Шрифты и трекинг
5. Анимация интерфейса

Понимание этих пяти пунктов поможет создавать по-настоящему крутой и удобный дизайн
Тестирование и QA
Как работая меньше, нравиться тимлиду больше. Ускоряем ручное тестирование
Павел Мазунин,
Xsolla
Тезисы
Создаем инфраструктуру для интеграционных тестов
Слава Черепанов,
2ГИС
Тезисы
Путь от одного человека до распределённой команды нагрузочного тестирования
Дмитрий Винокуров,
Miro
Тезисы
Когда применять BDD?
Дмитрий Бормотов,
Flow Health
Тезисы
Экосистема BDD для проекта
Владислав Мухаматнуров,
Тинькофф
Тезисы
Тестирование: взгляд с другой стороны
Артём Кураев,
Почтатех
Тезисы
Структура QA в крупной компании
Антон Нечеухин,
Miro
Тезисы
Best practice: гибкие и ускоренные тесты на вашем проекте
Евгений Малыгин,
Raketa.travel
Тезисы
Ферма для iOS
Руслан Абашин,
Кавычки
Тезисы
Ural Testing Community - всё ещё существует
Максим Захаров,
СКБ Контур
Тезисы
Максим Захаров, СКБ Контур
Ural Testing Community - всё ещё существует
Что случилось в сообществе в 2019, что поменялось в 2020.

И главное, почему к нам стоит присоединиться в 2021: когда и как пройдут соревнования, как долго будем переводить книгу, в какие компании зайдем в гости и кого из известных тестировщиков пригласим выступить перед сообществом.
Руслан Абашин, Кавычки
Ферма для iOS
С удалёнкой появилась потребность в закупке и отправке живых устройств IOS для команды, а это время и деньги. При этом, существующие решения тестирования IOS не идеальны. Это все сказывается на качестве.

Мы работаем на удалёнке более десяти лет, поэтому эти проблемы стали актуальны для нас еще до того, как удалёнка стала пандемийным мейнстримом.

И чтобы не тратить ресурсы на закупку и тестировать качественно, мы создали собственную разработку — мобильную ферму для тестирования IOS.
Евгений Малыгин, Raketa.travel
Best practice: гибкие и ускоренные тесты на вашем проекте
Доклад будет посвящен работе над скоростью прогона автотестов.

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

С best practice ваши тесты будут летать со скоростью ракеты!
Приходите, будет интересно, а главное полезно!
Павел Мазунин, Xsolla
Как работая меньше, нравиться тимлиду больше. Ускоряем ручное тестирование
Ручное тестирование отнимает слишком много времени и сил? Может вы просто неправильно его готовите?

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

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

Мы разберем, какие бывают тестовые стенды и - особенно! - окружения special for автотестов, сравним разные варианты.

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

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

Прослушав доклад, вы узнаете, как создать инфраструктуру для автотестов, подходящую именно вам, и как не потратить на это слишком много времени.
Дмитрий Винокуров, Miro
Путь от одного человека до распределённой команды нагрузочного тестирования
В условиях гиперроста в Miro в 2020 г. возникла острая потребность в нагрузочном тестировании (НТ), и имеющиеся наработки пришлось оперативно развивать.

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

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

Результатами этих процессов стали:
1) возможность уверенного внедрения новых компонентов и доработки существующих;
2) оптимальный выбор настроек компонентов в соответствии с требованиями;
3) автоматизация, упрощение и ускорение тестирования.

Отдельно стоит отметить участие в наполнении публичной базы знаний по НТ вместе со специализированным сообществом.

Также в ходе рассказа о "внутренней кухне", технических и организационных решениях, даётся краткое введение в НТ.
Дмитрий Бормотов, Flow Health
Когда применять BDD?
Использование BDD призвано улучшить процесс автоматизации тестирования в виду документирования пользовательских сценариев в процессе написания кода, а также расслоения структуры тестов.
Владислав Мухаматнуров, Тинькофф
Экосистема BDD для проекта
Разработка на основе поведения - достаточно захайпованный подход к организации процессов разработки и обеспечения качества на IT-проектах. И тем не менее, мало кто умеет готовить BDD правильно, еще меньше проектов добиваются действительно эффективной экосистемы.

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

  • Расскажу о важности пирамиды тестирования и что её нужно разрабатывать совместно.

  • Расскажу об инструментах тестирования и почему часто их проблематично применять
Антон Нечеухин, Miro
Структура QA в крупной компании
Хочу рассказать, как можно построить функцию QA в компании, которая состоит из нескольких сотен разработчиков.

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

Мы поговорим про подобные не очевидные вещи, разберемся какой должна быть структура QA, как организовать эффективное развитие всей функции QA, и главное, как обеспечить бизнес должным уровнем качества.
DevOps
Не Helm'ом единым
Александр Тарасов,
ANNA Money
Тезисы
Пишем надежные ansible роли
Владимир Лила,
Контур
Тезисы
4 золотых сигнала на службе SRE инженера
Кирилл Казарин,
DINS
Тезисы
Долгий путь от bash до gitops
Дмитрий Харламов,
Provectus
Тезисы
Как измерить DevOps?
Виталий Хабаров,
Экспресс 42
Тезисы
Платформа цифровых продуктов Ростелекома. Как запилить DevOps-инфраструктуру в кровавом энтерпрайзе
Руслан Тагиров,
Ростелеком
Тезисы
Dev.+Ops — чему нас учат новые миры
Димитрий Сугробов,
Леруа Мерлен
Тезисы
Без отката до рассвета
Артём Картасов,
Postgres.ai
Тезисы
Cloud native vs self-hosted solutions при масштабировании инфраструктуры. Что выбрать? Опыт Miro
Виктор Еремченко,
Miro
Тезисы
Александр Тарасов, ANNA Money
Не Helm'ом единым
У нас в ANNA Money более ста различных микросервисов (и их число только растёт), которые мы доставляем сотни раз в неделю на тестовые и промышленную среды на базе Kubernetes. При таком объёме встают вопросы по унификации, стандартизации и упрощении формата описания сервисов и их деплоймента. Одним из способов решения этой проблемы является использование пакетного менеджера Helm (пожалуй, наиболее популярного на текущий момент).

Но что если Helm в вашей вселенной был не всегда? А что произойдёт, если завтра ему на смену придёт другой более хиповый способ описания деплойментов?

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

В докладе автор расскажет:
- какие идеи и мотивация стояли за разработкой собственного формата описания сервисов
- как быть готовым к изменениям и почему дополнительный слой абстракции, который контролируешь именно ты, помогает в решении этой проблемы
- как устроен у нас деплоймент сейчас
- как именно мы используем Helm
- и почему мы не боимся перемен
Владимир Лила, Контур
Пишем надежные ansible роли
Ansible в 2021 году может звучать не модно, однако им по прежнему решают огромное количество задач.

Мы в Контуре тоже используем Ansible для раскатки инфраструктуры.

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

В докладе расскажу:
  • как решали проблему с зависимостями Ansible ролей, добавляли тестирование ролей в докере,
  • разбирались с линтерами,
  • подумали о работе на 6 операционных системах,
  • совмещали локальную разработку и CI,
  • устанавливали всем единое окружение,
Внутри много технических деталей!
Кирилл Казарин, DINS
4 золотых сигнала на службе SRE инженера
Дмитрий Харламов, Provectus
Долгий путь от bash до gitops
У нас в Provectus множество различных проектов, от типовых до очень необычных.

Зачастую запуск проекта, а тем более стартапа, без знаний бизнеса или без понимания конечной инфраструктуры (а если еще и ТЗ меняют на ходу) - боль. Боль как для Ops команды, так и для Dev. Необходимо быстро реагировать на ситуацию, иметь возможность расширить\сократить\заменить людей на проекте или стек целиком. Но что бы ни случилось, требуется сделать хорошо и соответствовать определённым стандартам.

Ещё один важный фактор – оставить после запуска проекта знания, передать артефакты, чтобы у заказчика была возможность обслуживать инфраструктуру своими силами. Или иметь возможно повторить проект с небольшими изменениями, часто в сжатые сроки!

Взяв за основу наработки одного из наших DevOps инженеров (это был многим знакомый Terraform), мы создали инструмент, который позволял развернуть базовую инфраструктуру в AWS с упором в EKS, и что не мало важно, удалить все созданное без остатка. Мы решили назвать проект Swiss-Army-Kube.

В докладе автор расскажет:
- Что подтолкнуло к разработке подобного инструмента и с какими трудностями пришлось столкнуться
- Как договорится в большой компании инженеров с множеством инструментов
- Как именно мы используем Swiss-Army-Kube и в каком направлении развиваемся
- Что мотивирует на развитие проекта и зачем нужно делится этим со всем миром
Виталий Хабаров, Экспресс 42
Долгий путь от bash до gitops
Четыре ключевые метрики Accelerate (они же DORA) стали индустриальным стандартом для оценки качества процессов поставки. Их внедряют в GoCD и Gitlab CI.

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

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

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

Нельзя просто взять и начать делать пилот нового проекта на GCP, AWS или даже Yandex.Cloud. Ты связан определенными ограничениями корпоративной сети.

Нельзя просто взять и делать вообще что-то. Это всегда непросто. Потому и возник термин "кровавый энтерпрайз". Так было до недавнего времени.
Корпорации вынуждены меняться и отвечать на запросы продуктовых команд как организации самой разработки (кто еще не поехал в Agile?), так и технологического процесса (весь этот наш DevOps).

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

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

На примере конкретного кейса – рефакторинга монолитной региональной CRM-системы с одновременным переходом с "водопада" на Kanban и перестройкой CI/CD в проекте – мы расскажем, какие боли есть у руководителя проекта и как ему может помочь корпоративная DevOps-платформа.

Мы расскажем о Платформе Цифровых Продуктов (ПЦП) Ростелекома и о том, почему всё больше новых проектов в РТК выбирают её, какие проблемы "кровавого энтерпрайза" она помогает решить и как сделать так, чтобы бизнес поверил в DevOps и дал денег, а эксплуатация не крутила у виска пальцем.

Расскажем, почему ПЦП – это не просто пара-тройка кластеров OpenShift, а нечто большее.
Димитрий Сугробов, Леруа Мерлен
Dev.+Ops — чему нас учат новые миры
Больше 10 лет прошло с момента первой легендарной конференции DevOps Days в Генте. За это время в мире появилось с несколько дюжин различных коллабораций с Ops-спецами, начиная с класических DevSecOps-ов, заканчивая диковинными HugOps-ами.

Рассмотрим боли и причины появления таких движений, возьмём их лучшие практики и проанализируем направления, куда можно развиваться DevOps специалисту.
Артём Картасов, Postgres.ai
Без отката до рассвета
Одним из ключевых принципов DevOps является уверенность в отлаженности процесса деплоя приложений. Уверенности нам добавляет контроль и предсказуемость производимых изменений, в том числе и на стороне базы данных. Понимание того, как будут выполняться миграции в вашей базе данных, как никогда важно иметь перед процессом деплоя, а не после или во время.

В этом докладе я расскажу, как интегрировать тестирование миграций на реальных данных в свой пайплайн CI/CD и убедиться, что изменения будут предсказуемо выполняться при деплое в production-среде.
Виктор Еремченко, Miro
Cloud native vs self-hosted solutions при масштабировании инфраструктуры. Что выбрать? Опыт Miro
За последний год нагрузка на наш продукт выросла x5, и перед нами встала серьезная задача быстро масштабировать инфраструктуру.

Это был настоящий вызов и мы с ним справились.

Расскажу о cloud native и self-hosted подходах и поделюсь плюсами и минусами каждого из них, а также критериями для выбора, которые мы определили для себя
GameDev
Создание игры: от идеи до релиза
Кумыков Эдуард,
Belka Games
Тезисы
Гипер-казуальные игры. Обзор сделок и рынка
Марина Бондаренко,
BoomBit
Тезисы
Как игры меняют наше будущее
Сергей Гимельрейх,
основатель творческого пространства авторов игр "Индикатор", сооснователь проекта Манжеты Гейм-дизайнера
Тезисы
Продуктовая аналитика в GameDev
Кушнарев Игорь,
Targem Games
Тезисы
Unity, DOTS и ECS. Как перестать бояться и начать делать игры по новому: быстро и приятно
Лукьянов Алексей,
Azur Games
Тезисы
Сказ о том, как Playrix свой движок делал
Владимир Беляев и Федор Ефтимица,
Playrix
Тезисы
Blue-green deployment игровых серверов
Дмитрий Апанасевич,
Mail.Ru, студия ITT
Тезисы
Кумыков Эдуард, Belka Games
Создание игры: от идеи до релиза
Создать и выпустить игру не так просто, как кажется, особенно если вы хотите, чтобы релиз прошел успешно и игра добилась каких-то результатов, окупив при этом вложенные затраты… или нет ;) Т.к. геймдев — высокорисковое мероприятие.

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

Вы сможете узнать, на каком этапе необходимо подключать аналитику, обращаться к издателю и как необходимо проводить тестирование игры, технический и "мягкий" запуск, а также готовиться к полноценному выходу на весь мир.
Марина Бондаренко, BoomBit
Гипер-казуальные игры. Обзор сделок и рынка
В докладе будет рассмотрена тема гипер-казуальных игр, их отличия от других жанров игровой разработки. А также мы узнаем ответы на важные вопросы:
  • Где найти вдохновение?
  • Как сделать успешный креатив?
  • Как и чем привлечь издателя и инвестиции?
Сергей Гимельрейх, основатель творческого пространства авторов игр "Индикатор", сооснователь проекта Манжеты Гейм-дизайнера
Как игры меняют наше будущее
Сергей поделится удивительной историей зарождения, развития и эволюции Игры, как важнейшей части нашей цивилизации.

Сквозь призму заложенных в людях социально-культурных, психологических и природных аспектов мы взглянем на игру, как новое медиа, охватывающее всё больше сфер реальной жизни, оказывающее влияние на каждого из нас сегодня и формирующее совершенно новую гибридную реальность человека будущего.
Кушнарев Игорь, Targem Games
Продуктовая аналитика в GameDev
Данный доклад предназначен для тех кто хочет окунуться в аналитику именно в направлении разработки игр.

Во время доклада Игорь разберет зачем нужна аналитика играм, как ее осуществлять, какими методами и инструментами пользоваться, а также даст примеры из реальной практики, когда аналитика помогает не только в достижении продуктовых показателей, но и в геймдизайне.
Лукьянов Алексей, Azur Games
Unity, DOTS и ECS. Как перестать бояться и начать делать игры по новому: быстро и приятно
В своем докладе Алексей расскажет о новом стеке технологий Unity DOTS, поделится опытом применения парадигмы ECS для быстрой и комфортной разработки игр.

Также будут освещены темы красивой архитектуры проекта, лучших практик, решения частых проблем DOTS и применения лучших моментов из классического и нового подходов к разработке
Владимир Беляев и Федор Ефтимица, Playrix
Сказ о том, как Playrix свой движок делал
Лао-цзы писал: "путь в тысячу ли начинается с одного шага". Вот и наш сказ будет о том, как один технологический шаг вперед привел Playrix к пути в тысячу ли – созданию Unity-подобной библиотеки.

Поговорим про то, что сделать минималистичный движок не сложно и не дорого, а вот хороший и удобный – совсем наоборот. Про то, как отличаются проблемы в начале пути от проблем на стадии зрелой разработки. А еще про всяких зверей на этом пути: C++ reflection, code generation, refactoring, ImGui, interface user expirience, cross-project game logic и test automation.
Дмитрий Апанасевич, Mail.Ru, студия ITT
Blue-green deployment игровых серверов
Дмитрий даст обзор техники обновления серверов приложений без остановки обслуживания запросов. И расскажет по каким причинам в студии ITT пришли к необходимости ее внедрения, об особенностях игровых проектов для мобильных девайсов.

В докладе будет показано как подход zero-downtime deployment применяется для кластеров серверов игровых проектов студии ITT, что было сделано для его реализации. А так же какие есть особенности применения, способы решения задач взаимодействия между различными инстансами приложений.