При 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.
Современный фронтенд — это сложно. Если легаси проекты ограничены "что есть — то есть", то для новых приложений, кроме настройки 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, а также занимается спецпроектами в Туту.ру Тезисы
Соотношение ценности продукта и сервиса. Что важнее: эмоции или качество?
Сергей Абдульманов, 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
Книга рецептов: 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 человек, приведу пару примеров, показывающих, насколько разработчики глубоко погружены в бизнес и могут самостоятельно предлагать топовые решения.
Часто при разработке мобильных приложений разработчики попадают в ситуацию, когда бэкенд не работает. Причин этому много, однако итог один — разработка затягивается.
Ребята из 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 посмотрим, как выглядит их внедрение, какие боли лечит, а какие создает.
О важности фокусировки и концентрации знают все. Но как переключать себя в это состояние? Особенно тогда когда нужно? Расскажу такой рецепт. Простой и понятный алгоритм действий.
Андрей Шапиро, Byndyusoft
Три инструмента ТРИЗ в практике проектировщика интерфейса
Теория решения изобретательских задач (ТРИЗ) на слуху в дизайнерской среде, однако мало кто владеет конкретными практиками. Прочитав две книги по этой теме, я всё ещё сильно «плавал» и не мог применять теорию. Только погружение в практику современной ТРИЗ дало навык решения задач.
В докладе рассмотрю три метода в приложении к дизайнерским задачам. Этими методами будут:
причинно-следственный анализ;
оператор «идеальный конечный результат»;
графическая форма технического противоречия.
Звучит жутко, но инструмент даёт мощнейший.
Александр Устинов, BeaversBrothers
Специфика работы с детской аудиторией: что должен уметь дизайнер, чтобы создавать проекты для детей?
Основные вопросы, на которые я отвечу по ходу доклада:
Что должен уметь дизайнер, чтобы создавать игровые проекты для детей?
Как проводить исследование, чтобы понять, какие игры могут быть интересны детям?
Какие исследования можно делать онлайн, а что обязательно нужно делать оффлайн?
Как рассказать детям о сложном просто?
Как придумывать игровой сюжет?
Как придумать интересных героев?
Как тестировать идеи на детях?
А еще поговорим о том, какие навыки UX/UI дизайнера помогают создавать игры для детей, а какие мешают. Почему в создании игр для детей дизайнер должен быть сценаристом, режиссёром, исследователем? Можно ли совмещать в себе эти навыки и какой из них самый главный?
Дмитрий Бровка, Яндекс
Три проблемы разработки, которые решит дизайн-система
Растущее количество интерфейсов требует серьёзной дисциплины. Высокий темп трансформации сервисов невозможен без слаженной работы и быстрой доставки обновлений до пользователей. Мы нашли решение в разработке дизайн-системы и инфраструктуры вокруг неё.
Я расскажу, какой путь мы прошли, чтобы построить оптимальный флоу и решить проблемы, связанные со взаимодействием между дизайнерами и разработчиками.
Дарья Почекуева, Почтатех
Проектирование сложных B2B-сервисов в деревне Виллабаджо
Доклад основан на личном опыте работы над цифровыми продуктами Почты России.
Рассмотрим кейс системы учёта международной почты и ответим на вопросы: 1. Как проектировать сложные и специфические B2B-продукты в консервативных сферах, где исследования подменяются требованиями заказчика. 2. Как навести порядок в дизайне продукта, если нет развитых дизайн-процессов. 3. Как сохранить интерес и энтузиазм, когда проект сложный и с долгим циклом разработки.
Доклад будет интересен дизайнерам, которые ищут способы организовать свою работу с нуля, когда вокруг хаос и не на что опереться.
Тамара Персикова, Тинькофф
Диалоговый дизайн голосовых ассистентов
Тренд на голосовые интерфейсы не стихает, но окружен смесью хайпа и скепсиса. Кому и зачем нужен голос? Voice first или voice only? Почему боты такие тупые? И как сделать их лучше?
На докладе я расскажу о:
дизайне диалогов — процессе на стыке продуктового дизайна и редактуры, который учит голосовых ассистентов решать задачи клиентов;
молекулах и атомах проектирования процедур для бота;
клиентских путях и процессе UX-исследований для голоса;
юзкейсах и ЦА голоса;
истории и перспективах дизайна VUI.
Доклад будет интересен тем, кто не знаком с ML, и хочет узнать, как работает диалоговый дизайн.
Мила Иванова, Artsofte
Масштабирование навыков дизайнера в продукте
Какие важные для профессии навыки развиваются в фоновом режиме?
Можно ли их осознанно масштабировать?
Как понять свою ценность для компании и презентовать её команде?
Я расскажу про способы оценки своих скилов и потребностей, про вертикальный рост и горизонтальную миграцию в команде. Поделюсь опытом работы на разных ролях в продукте, и зачем мне это было нужно. А также расскажу о том, какие метанавыки будут востребованы на рынке в будущем.
Александр Обанин, DD Planet
Генеративный дизайн: меньше работать, больше творить
Генеративный дизайн — современный подход к проектированию и дизайну, при котором человек делегирует часть процессов компьютерным технологиям и платформам. С его помощью создают сайты, изображения, мелодии, архитектурные модели, детали, анимации и многое другое.
Я расскажу про две стороны применения генеративного дизайна.
Первая — автоматизация процессов для тиражирования дизайна.
Вторая — использование компьютера как творческого инструмента, помощь дизайнеру в создании новых визуальных элементов.
Олег Пирогов, Сбер
Особенности дизайна мобильных приложений
Поговорим о пяти основных моментах, которые нужно учитывать при дизайне мобильных приложений. 1. Моторные, визуальные и когнитивные нагрузки 2. Контекст использования и способ взаимодействия 3. Привычные паттерны пользователей и платформ 4. Шрифты и трекинг 5. Анимация интерфейса
Понимание этих пяти пунктов поможет создавать по-настоящему крутой и удобный дизайн
Тестирование и QA
Как работая меньше, нравиться тимлиду больше. Ускоряем ручное тестирование
Что случилось в сообществе в 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, и главное, как обеспечить бизнес должным уровнем качества.