Конференция завершена. Ждем вас на РИТ++ в следующий раз!

Заявки на доклады

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

Поиск по тегам:

Профессиональная конференция по применению психологии в управлении и бизнесе Aletheia Business 2019

Трансформационные изменения

Трансформация бизнес-культуры: преодолеть сопротивление, добиться результата

Марина Корсакова

1. Давайте поговорим о том, почему самые смелые инновационные идеи могут оказаться не реализованы... Часто дело в том, что будучи блестящими и оригинальными сами по себе, они тем не менее не попадают в подходящую организационную культуру. Какая организационная культура способствует инновациям? Прозрачная, доверительная, толерантная к различиям, но при этом операционно-эффективная и продуктивная. "Культура ест стратегию на завтрак", — сказал Питер Друкер, когда информационная экономика еще только готовилась сменить индустриальную. Его слова более чем справедливы и сегодня.

2. Значит ли это, что не обладая соответствующей деловой культурой, организация должна отказаться от развития и самой жизни? Вовсе нет. Культура — вещь динамичная; она течет и изменяется. На докладе я расскажу о том, что бизнес-культуру можно целенаправленно трансформировать и приведу примеры. А ещё мы поговорим о том, что именно вопросами управления культурой должны заниматься первые лица компании (спойлер: а не только HR :)

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

Корпоративная культура и мотивация
,
Управление / другое
Доклад принят в программу конференции

О чем еще говорят мужчины среднего возраста на встречах клуба собственников IT-бизнесов

Вирна Штерн
Александр Зиза

Три года мы проводим клуб собственников. Это ежемесячные встречи на два полных дня!

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

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

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

Модели руководства
,
Выбор стратегии долгосрочного развития, KPI
,
Управление / другое
Доклад принят в программу конференции

Управленческие и карьерные сопротивления

Александр Орлов

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

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

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

Доклад принят в программу конференции

Развитие осознанности

Эффект поведенческой экономики в ИТ-подборе

Людмила Клепова

1. Статистика на рынке ИТ-подбора.
* Какой стек самый востребованный?
* Каких кандидатов больше всего на рынке?
* Где открывать региональные офисы? И открывать ли?
* Кандидаты с какими технологическими стеками самые «дешевые»?
* Почему отказываются от офферов?
* На что идут люди: лидер, эксперт, деньги, проект?
* Хорошо ли в опен-спейсе и нужны ли людям печеньки?

2. Разрушение мифов или успех иррациональных решений.
* Три кейса из ИТ-компании, банка и производства.

3. Основы поведенческой экономики и как их применить в ИТ-подборе.

4. Три вывода: осознанность, статистика и менеджерская интуиция.

Доклад принят в программу конференции

Психологические инструменты

Особенности охоты на Senior+: Executive Search и HeadHunting в IT

Anna Afonina

Специалисты уровня Senior+ (Team/Tech Lead, PM, Head/Chief of..., etc), у которых действительно все хорошо, не находятся в поиске работы.

Мы разберем специфику ES и HH в IT:
- Пассивный поиск. Как они вообще меняют работу?
- Мало кандидатов. Really? Основные источники поиска. Архитектура network.
- Вы мечтали найти того, кому даже резюме не нужно. А как теперь оценивать?
- Сбор и анализ информации о кандидате — сокровища для выстраивания стратегии переговоров.
- Как мотивировать кандидата дойти до оффера через все этапы подбора?
- Организация переговоров с руководителем. Как довести до win-win?
- Лучшим всегда делают Counter-offer. Залог вашего успеха, и когда стоит сдаться.

Доклад принят в программу конференции

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

Андрей Макаров

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

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

Модели руководства
,
Корпоративная культура и мотивация
,
Поиск и развитие команды
,
Управление / другое
Доклад принят в программу конференции

Новая культура организации

Счастье или галеры! Культура организации платформенного (цифрового) мира

Александр Зиза

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

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

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

Модели руководства
,
Корпоративная культура и мотивация
,
Управление / другое
Доклад принят в программу конференции

(почти) Объективная оценка людей в IT

Георгий Могелашвили

Правильно ли художник кладёт краску на холст? А может ли поэт слагать стихи в два раза быстрее? Достаточно ли эффективно программист пишет код?

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

В Booking.com мы придумали и выстроили свои процессы, которые работают для более чем 1500 сотрудников в IT. Мы оцениваем людей не только по тому, что они делали, но и как они это делали, полагаясь на мнение не одного единственного руководителя/тимлида, а множества людей вокруг.

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

Доклад принят в программу конференции

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

Анатолий Иванов

Что будет в докладе:
1. Как мы вывели ключевые бизнес-метрики на экраны в офисах и открыли всем доступ к финансовой статистике. Как это помогло в pull-формате побудить людей к любознательности и вовлечь их в бизнес-игру про "заработать больше денег" :)
2. Как мы наладили культуру обратной связи от бизнеса командам после каждого спринта.
3. Как мы приучили команду аналитики давать обратную связь по итогам внедрения каждой крупной фичи.
4. Как мы сделали демо настолько увлекательными и даже немного шоу, что все, включая бизнес, обожают ходить на него.
5. Как мы начали звать технарей на бизнесовые конференции. Спойлер – на такие конференции даже ради afterparty стоит ездить ))
6. Как мы внедрили культуру задавания вопроса "А все-таки зачем мы делаем эту фичу" не в теории, а на практике.
7. Как мы учим технарей общаться напрямую с конечными пользователями, и почему это всем нравится ;)
8. Как мы распространяем бизнес-знания в компании, что работает, а что не очень.

Доклад принят в программу конференции

Социальный договор цифрового мира: работа должна обеспечивать счастье, а не только деньги

Максим Цепков

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

В докладе будет разобрана история формирования и изменения социального контракта в IT. Особенность отрасли в том, что старый социальный контракт работал плохо, потому что регламенты не обеспечивали результативность. Именно в этом суть книги Брукса "Мифический человеко-месяц". RUP, потом Agile — разные попытки организовать результативный процесс в рамках существовавшего рабочего контракта. Но Agile ориентацией на ценности открыл путь к его изменению, актуальный в условиях нарастающего дефицита рынка труда. Компании начали привлекать сотрудников свободным графиком, самореализацией и другими благами. И в целом этот процесс приводит к изменению социального контракта. Но по пути возникло много побочных эффектов, например, Agile-курорт, складывающийся в некоторых IT-отделах корпораций, на котором сотрудники блага получают, а на бизнес-цели компании не работают, и разные другие эффекты взаимного несоответствия ожиданий, которые также будут рассмотрены в докладе.

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

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

Как воспитать свое сообщество, чтобы не танцевать

Ксения Рагозина

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

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

Доклад принят в программу конференции

Fullstack HR, или Трансформация роли HR при цифровой трансформации

Ольга Давыдова
Артем Каличкин

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

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

Конечно, для нас, как для компании-разработчика ПО, основным инструментом в достижении таких целей стала agile-трансформация команд.

В процессах менялась жизнь людей. Весь привычный строй деятельности кардинально менялся. Трансформация — это история про людей!

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

Если так много в этих историях человеческого, то где тогда во всех них HR?
Если у вас возникает вопрос, а при чем тут HR, то возникает встречный вопрос — а какую роль у вас выполняет HR?

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

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

Доклад принят в программу конференции

Раскрытие талантов

Дата-экспедиции: продвинутый формат обучения работе с данными

Ирина Радченко

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

Базы данных / другое
,
Аналитика / другое
,
Другое
,
Профессиональное развитие инженера
Доклад принят в программу конференции

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

Виктория Юркевич

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

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

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

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

Доклад принят в программу конференции

Круглый стол по вопросам развития (T&D) с HR, DevRel и TeamLead digital-компании

Александр Зиза
Михаил Клюев
Ольга Африна
Иван Лукьянов
Анастасия Чертовских

Круглый стол, посвященный вопросам трансформации T&D-функции.

* Как трансформируется функция HR?
* За что отвечает DevRel?
* За какие направления развития отвечает TemLead?

Ответы на эти и свои вопросы вы сможете получить на встрече с представителями digital genuine-компании с digital-культурой.

Доклад принят в программу конференции

Профессиональная конференция для серверных веб-разработчиков Backend Conf

Теория программирования

The Future

Андрей Аксенов

Давайте немного пофилософствуем. Давайте поговорим о будущем. Будущем разработки, будущем индустрии. Каким оно может оказаться?

Доклад принят в программу конференции

Тестирование, A/B-тестирование

Тестирование ClickHouse, которого мы заслуживаем

Александр Сапин

ClickHouse — это не только популярная поколоночная СУБД, но и быстроразвивающийся opensource-проект на языке C++. В неделю мы вливаем около 40 пул-реквестов, 15% из которых привносится внешними контрибьюторами. Такие темпы развития требуют хорошей автоматизированной инфраструктуры тестирования кода на всех уровнях.

В докладе я расскажу о том, как устроен CI ClickHouse и из каких компонентов состоит pipeline тестирования. Сначала речь пойдёт об особенностях покоммитных сборок ClickHouse с разными конфигурациями в различных OS. Затем будут рассмотрены все этапы тестирования, начиная от статического анализа кода и заканчивая интеграционными тестами и тестами производительности. В заключение я расскажу о преимуществах, которые нам дает CI: удобство в обнаружении багов, организация двухнедельного релизного цикла и улучшение работы с контрибьюторами.

Технологии виртуализации и контейнеризации
,
Непрерывная интеграция
,
Функциональное тестирование
,
Нагрузочное тестирование
,
Автоматизация тестирования
,
Интеграционное тестирование
,
Юнит-тестирование
Доклад принят в программу конференции

Элементы архитектуры

Как мы построили сервис распределённых очередей в Яндексе

Василий Герасимов

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

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

План доклада:
Архитектура
- Что такое распределённая очередь и зачем она нужна.
- API распределённой очереди.
- Yandex Database и её свойства, которые используются для решения задачи.
- Наивное решение и его проблемы.
- Понятие мастера: обработка всех запросов к одной очереди на конкретной машине кластера.
- Проблема нескольких мастеров.
- Кэширование информации по очередям в памяти.
- Как сделать меньше одной транзакции на пользовательский запрос.
- Что делать, если запросов слишком много.

Разработка
- Связывание событий по одному запросу на разных машинах.
- Борьба со слишком большим количество логов.
- Написание неудобных клиентов.
- Тест консистентности.
- Логирование медленных запросов.
- Трассировка по требованию.
- Включение подробных графиков.

Базы данных / другое
,
Организация системы кеширования
,
Архитектурные паттерны
,
Отказоустойчивость
,
Оптимизация производительности
,
Распределенные системы
,
Архитектура данных, потоки данных, версионирование
,
Архитектуры / другое
,
Профилирование и отладка кода
,
Приёмочные и функциональные тесты
Доклад принят в программу конференции

Хранилища данных на службе BI

Александр Крашенинников
Алексей Еремихин

Когда в компании надо принимать решения на основании показателей, отдел BI — главный помощник.

В ход идут пересечения потоков данных, витрины, data research и просто метод пристального взгляда.

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

В докладе рассмотрим, как мы в BI используем связку Exasol и Hadoop. Рассмотрим аспекты ETL и технические решения, которые мы используем для интеграции этих хранилищ.

Базы данных / другое
,
Hadoop
,
ETL
Доклад принят в программу конференции

Воркшоп "Получаем Bounded Contexts с использованием Event Storming"

Евгений Пешков
Дамир Атыгаев

Мы расскажем про Event Storming — отличный способ проектировать, используя Domain Driven Design.

Поговорим про DDD и обсудим опыт использования. Попробуем спроектировать систему с помощью Event Storming.

Чем хорош Event Storming?

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

Доклад принят в программу конференции

Распил монолита в Леруа Мерлен

Павел Юркин

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

Микросервисы, SOA
,
Архитектурные паттерны
,
Распределенные системы
,
Архитектура данных, потоки данных, версионирование
,
Архитектуры / другое
Доклад принят в программу конференции

Рабочие ситуации и задачи

Как переписать фасетный поиск с Solr на Elastic и выдержать 4K RPS

Денис Сотников

* Что такое фасетный поиск, общие принципы работы.
* Как это было реализовано на Solr. Как мы обновляли данные в поиске. Почему мы решили взять ElasticSearch. * Как работать с legacy-кодом. Какая конфигурация кластера нам подойдет. Как обновлять данные в реальном времени без downtime.

Доклад принят в программу конференции

Голосовое управление в облачных веб-проектах с помощью Яндекс.Станции и Google Assistant

Александр Сербул

В докладе мы расскажем, как используем устройства и технологии Яндекс.Станции, Google Home, Irbis A и DEXP Smartbox для управления корпоративным порталом Битрикс24. Поговорим об алгоритмах и возможностях Google Ассистента и Яндекс.Алисы для распознавания голоса, определения намерения и разбора текста. Расскажем, как мы подружили эти технологии с нашими для создания Задач, событий в Календаре, Встреч, Совещаний и отправки Сообщений сотрудникам компании.

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

Доклад принят в программу конференции

Переход от Rest API к GraphQL на примере реальных проектов

Антон Морев

Разбор трех реальных кейсов внедрения GraphQL.

• Доводы за и против перехода на GraphQL.
• Как безопасно делегировать логику группировки данных на frontend и разгрузить backend-разработчиков.
• Использование на примере проекта с микросервисной архитектурой, монолита.
• Недостатки, которые мы осознали, только столкнувшись с ними.
• Инструменты для разработки с сервисов GraphQL в продуктах от Jetbrains.

API
,
PHP
,
Взаимодействие с серверной стороной (REST, GraphQL, gRPC)
Доклад принят в программу конференции

Фаззинг или тестирование мусорными данными

Максим Бакиров

Поисковый запрос в 2ГИС содержит 25+ параметров, начиная c введенного текста и заканчивая персональными предпочтениями пользователя. Чтобы обеспечить стабильную работу приложения, мы решили не ограничиваться тестовыми запросами, сгенерированными человеческой логикой. Так в нашей жизни появился фаззинг — тестирование приложения на неправильных, неожиданных или случайных данных.

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

C/C++
,
Поисковые системы
,
Бэкенд / другое
,
Отказоустойчивость
,
Оптимизация производительности
,
Автоматизация тестирования
,
Интеграционное тестирование
,
Профилирование и отладка кода
,
Big Data и Highload в Enterprise
Доклад принят в программу конференции

Базы данных

Остаться в живых. Крупный проект на одной NoSQL

Айк Саргсян

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

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

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

Бэкенд / другое
Доклад принят в программу конференции

Нельзя просто так взять и скопировать, или Как оптимизировать модель данных для cloud-based-хранилищ

Александр Токарев

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

Я попробую доказать, что копирование традиционных star- и snowflake-схем не позволяет получить максимальную производительность в таких хранилищах как Amazon Redshift и Google Big Query, но и приводит к дополнительным финансовым затратам.

Мы обсудим, почему модели данных одного и того же хранилища должны быть разными между Redshift и Big Query, как эффективно использовать возможности данных СУБД.

Большинство советов по работе с данными СУБД сводится к "увеличьте размер кластера" или "добавьте sort key". Порой это уменьшает скорость выполнения запросов при гораздо более высокой стоимости владения.

Будет продемонстрировано несколько примеров с production, как с уменьшением мощности кластера общая производительность системы повысилась, а также рассмотрен ряд радикальных подходов, как системы с единственной сверхширокой таблицей фактов вместо star-схемы с таблицами фактов и измерений.

Оптимизация производительности
,
Работа с облачными сервисами
,
ETL
Доклад принят в программу конференции

nbtree-индексы в PostgreSQL. Полезные новинки

Виктор Егоров

nbtree-индексы существуют в PostrgeSQL более 20 лет, это основной и самый используемый тип индексов. В 12-й версии были внесены существенные изменения в то, как работают эти индексы.

Для начала мы рассмотрим устройство и принципы работы таких индексов: внутренние структуры, основные операции, а также проблемные места при эксплуатации этих индексов (да, это связано с распуханием).

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

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

Доклад принят в программу конференции

Обзор решений для PostgreSQL High Availability

Алексей Лесовский

Как обстоят дела с High Availability в PostgreSQL в 2019 году.

Очень коротко и быстро посмотрим на решения, которые были созданы в до-облачную эпоху... pgpool, bucardo, postgres-xc/xl. Разберем их недостатки (и преимущества?) и почему эти решения остались за бортом прогресса.

Более подробно остановимся на современных молодых решениях, таких как repmgr, patroni, stolon. Рассмотрим их перспективы, преимущества и недостатки, отличия и ниши для применения.

PostgreSQL
,
Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
,
Администрирование баз данных
Доклад принят в программу конференции

Как не «проспать» проблемы в базах данных Postgres: автоматизируем проверку здоровья

Николай Самохвалов

Чтобы поддерживать базы данных в здоровом состоянии, необходимо периодически заглядывать «под капот», «прощупывать» её на наличие ранних симптомов — другими словами, делать профилактическое исследование, оно же технический аудит БД, оно же healthcheck.

Проведение такого исследования вручную у нас занимало обычно несколько недель, особенно в случаях, когда БД мы видим впервые. В эру облаков и автоматизации это никуда не годится, пришло время соптимизировать эту процедуру. Так появился новый открытый проект: postgres-checkup (https://gitlab.com/postgres-ai-team/postgres-checkup). С ним аналогичные исследования стали длиться всего несколько часов.

Десятки различных отчётов, включающие в себя опыт DBA из различных компаний, объединены в удобный для запуска и использования инструмент. Среди основных его качеств:
- малозаметность (эффект наблюдателя сведён к минимуму),
- отсутствие требования установки чего-либо на машины с СУБД,
- форматы отчётов, удобные для потребления как людьми (markdown, HTML, PDF), так и машинами (JSON).

Мы поговорим о том, как postgres-checkup помогает нам диагностировать проблемы с производительностью и масштабированием в различных проектах, от небольших стартапов до многомиллиардных компаний. Также обсудим следующие вопросы:
- расширяемость (добавление своих отчётов) и интеграция с существующими системами;
- автоматизация и встраивание в процессы организации;
- особенности доведения информации до инженеров, которые не являются специалистами по СУБД, так, чтобы слова превращались в действия, оптимизирующие состояние БД.

Подробнее остановимся на крупных темах:
* bloat & autovacuum,
* здоровье индексов,
* комплексных глубокий анализ запросов на основе pg_stat_statements и pg_stat_kcache.

PostgreSQL
,
Базы данных / другое
,
Администрирование баз данных
,
Devops / другое
Доклад принят в программу конференции

Yandex Database: распределенные запросы в облаках

Сергей Пучин

Yandex Database (YDB) — геораспределенная транзакционная база данных, позволяющая выполнять декларативные запросы над данными с низкими задержками и строгой консистентностью. В докладе будут рассмотрены основные моменты, связанные с выполнением распределенных запросов в YDB.

Мы поговорим про применяемую модель транзакций и уровни изоляции, особенности SQL-диалекта Yandex Query Language (YQL), параметризацию и подготовку запросов, многошаговые транзакции и механизм оптимистичных блокировок.

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

Базы данных / другое
,
Распределенные системы
Доклад принят в программу конференции

Дизайн GraphQL-схем — строим схемы правильно (версия 2)

Павел Черторогов

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

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

Версия 2, доработанная с учетом правок от комьюнити и ревью от GraphQL-гуру Михаила Новикова и Ивана Гончарова.

API
,
Бэкенд / другое
,
Стандарты кодирования
,
Архитектура данных, потоки данных, версионирование
Доклад принят в программу конференции

Стендбай в бою: масштабируем приложение в топ-2 мировом классифайде

Константин Евтеев

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

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

Вторая часть выступления — о подводных камнях, о которых многие даже не подозревает, а другие принимают все риски. Речь пойдет о различных кейсах, которые могут привести к деградации вашего приложения и способах решения, а именно:
* высокий уровень TPS;
* применение DDL;
* отправка большого кол-ва WAL-файлов в архив и восстановление из архива;
* и др.

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

PostgreSQL
,
Tarantool
,
Организация системы кеширования
,
Архитектурные паттерны
,
Отказоустойчивость
,
Оптимизация производительности
,
Распределенные системы
,
Архитектура данных, потоки данных, версионирование
,
Масштабирование с нуля
,
Критерии выбора технологий для проекта
Доклад принят в программу конференции

Организация программного кода

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

Юрий Минаев

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

Java
,
C/C++
,
Стандарты кодирования
,
Непрерывная интеграция
,
Code Review
Доклад принят в программу конференции

Работаем с транзакциями в БД правильно: какие анти-паттерны любят разработчики, и чем это заканчивается для базы и для кода

Сергей Новиков

Работа с транзакциями в базе данных — одна из больных тем при разработке backend-приложения. При кажущейся простоте процесса ("сначала BEGIN, в конце COMMIT") в разных проектах периодически возникают одни и те же ошибки. Причина в одинаковых подходах к работе с транзакциями, которые правильнее назвать анти-паттернами. Я расскажу, как решать основные проблемы:
• Зависание транзакций (с помощью автоматизации операций ROLLBACK).
• Вложенные транзакции (средствами СУБД, и почему это опасно делать на уровне приложения).
• Выбор нужного сервера (мастер или реплика) в зависимости от ситуации.
• И ряд проблем поменьше, но от этого не менее важных.

Все решения я проиллюстрирую живыми примерами (PHP+PostgreSQL), взятыми из практики. Итогом доклада будет общая стратегия организации кода, позволяющая обойти рассмотренные грабли, и связывающая воедино транзакции, подключения к базе данных и обработку ошибок. Доклад будет полезен разработчикам, а также тем DBA, которые всё ещё страдают от выходок разработчиков.

PostgreSQL
,
Организация доступа к базам данных, ORM, собственные драйвера
,
Разработка библиотек, включая open source библиотеки
Доклад принят в программу конференции

Профессиональная конференция по DevOps

Инфраструктура как код

Что я узнал, протестировав 200 000 строк инфраструктурного кода

Лев Гончаров

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

Мы рассмотрим те подходы, которые сработали и нет, например, такие как:
* infrastructure as a bash history;
* SOLID для Ansible;
* пирамида тестирования инфраструктуры;
* парное администрирование.

Управление конфигурацией
,
Непрерывное развертывание и деплой
,
Непрерывная интеграция
,
Сетевое администрирование
,
Devops / другое
Доклад принят в программу конференции

Непрерывная поставка

Как доставить быстро и без боли. Автоматизируем релизы

Александр Коротков

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

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

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

Непрерывное развертывание и деплой
,
Непрерывная интеграция
,
Devops / другое
,
Автоматизация разработки и тестирования
,
Большие проекты/команды
,
Продуктовая разработка
Доклад принят в программу конференции

Как мы уменьшили количество откатов серверных релизов на 99%

Виктор Еремченко

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

Доклад содержит реальные примеры использования различных инструментов и технические детали CI/CD-процесса.

Логирование и мониторинг
,
Непрерывное развертывание и деплой
,
Непрерывная интеграция
Доклад принят в программу конференции

Аварии помогают учиться

Алексей Кирпичников

За три последних года в Контуре произошло примерно 1000 факапов разной степени эпичности. Среди них, например, 36% были вызваны выкатыванием некачественного релиза в продакшн, а 14% — работами по обслуживанию железа в дата-центре.

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

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

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

Доклад принят в программу конференции

werf — наш инструмент для CI/CD в Kubernetes

Давид Мэгтон
Тимофей Кириллов
Алексей Игрычев

За последние три года мы, компания «Флант», проделали огромный путь в борьбе за удобный и качественный деплой в Kubernetes. Это стало возможным благодаря постоянно растущему опыту обслуживания большого числа и разнообразия приложений, мигрированных и/или уже работающих в K8s.

В докладе мы подробно расскажем о тех проблемах и вызовах, с которыми сталкивается каждый при деплое в Kubernetes, а также о нюансах, которые могут быть заметны не сразу. Разбирая их, мы не только покажем возможные пути решения, но и продемонстрируем, как это реализовано в werf – нашем Open Source-инструменте для DevOps-инженеров, обслуживающих CI/CD в Kubernetes.

Непрерывное развертывание и деплой
Доклад принят в программу конференции

Бесчеловечный CI/CD

Андрей Куковеров

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

Фреймворки
,
API
,
Рефакторинг
,
Архитектуры / другое
,
Devops / другое
Доклад принят в программу конференции

Архитектура в DevOps, DevOps для CTO

Как в Айри.рф сократили SSD-задержки в 61 раз

Николай Мациевский

В декабре 2018 года в Айри.рф для SSD-дисков с кэшем под нагрузкой выявили большие задержки на отдачу файлов. В ходе профилирования задержек и точечных мер для их оптимизации удалось сократить число задержек на 2 порядка (с 1/1000 запросов до 1/100000 запросов).

Что мы сделали
* Внедрили метрики для отслеживания задержек по дискам. Несколько уровней метрик, включая ioping, prometheus, i/o wait, connect time.
* Выдвинули гипотезы, как улучшить производительность дисков. Снижение задержек тесно связано с утилизацией дисков.
* Пересобрали дисковые массивы, настроили файловую систему, поработали с логами, вынесли хранение в оперативную память, включили trim, изменили логику работы приложения и записи в кэш.

Логирование и мониторинг
,
Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
,
Аппаратное обеспечение
,
Теории и техники анализа
Доклад принят в программу конференции

DevOps-трансформация

50 millions deployments a year – The Story of DevOps Culture at Amazon

Tomasz Stachlewski

DevOps culture is one of the most important aspects in Amazon – it helps to quickly build, develop, test and maintain services and products which are then delivered to millions users around the world. It’s about removing barriers and improving the whole processes of delivering products. In this talk we will see how and why Amazon moved from building monolithic applications to building microservices with help of DevOps, we will see what kind of tools and procedures are being used to maintain the speed of building new services and how to keep being agile when you need to do deployment every second throughout the whole year.

Devops / другое
Доклад принят в программу конференции

Как заменить всю инфраструктуру и начать спать спокойно

Денис Лысенко

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

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

Логирование и мониторинг
,
Управление конфигурацией
,
Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
,
Автоматизация разработки и тестирования
Доклад принят в программу конференции

Azure DevOps - сервис для организации жизненного цикла программного продукта для любой платформы

Владимир Гусаров

Вы узнаете об эволюции и новых возможностях сервиса. Мы в деталях разберем все пять основных его компонентов и сделаем упор на Azure Pipelines - гибкую систему CI/CD c неограниченными возможностями собирать что угодно и деплоить куда угодно.

Управление конфигурацией
,
Непрерывное развертывание и деплой
,
Непрерывная интеграция
,
Devops / другое
,
Совместная работа, система контроля версий, организация веток
,
Автоматизация разработки и тестирования
,
Методологии и процессы разработки ПО; Сроки и приоритеты
,
Большие проекты/команды
,
Продуктовая разработка
Доклад принят в программу конференции

На пути к микросервисам...

Борис Ершов

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

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

В данном докладе я обобщу наш опыт в работе над такими проектами и приведу несколько наиболее полезных советов:
* Как выбрать подходящую для проекта архитектуру?
* Как избавиться от зоопарка?
* Какие инструменты использовать и как это делать?
* Какие подводные камни могут встретиться по пути и как их обойти?
* Что делать дальше?

Микросервисы, SOA
,
Менеджмент в эксплуатации
,
Непрерывная интеграция
,
Devops / другое
,
Автоматизация разработки и тестирования
Доклад принят в программу конференции

SRE-практики

ClickHouse и тысяча графиков

Антон Алексеев

Мы долго жили с самописным подсчётом метрик на местах. «Гибкость» этого подхода приводила нас в уныние. А потом мы попробовали ClickHouse и подсели. Так у нас появились те самые графики о работе:
* нашего CDN — от стандартных rps и трафика до выявления аномалий;
* транспорта статистики — вплоть до поиска потерь и дубликатов.

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

Доклад принят в программу конференции

Безопасность, DevSecOps

Внедрение SAST: теория vs практика

Ярослав Александров

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

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

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

В процессе доклада будут приведены примеры из опыта внедрения инструментов SAST.

Доклад принят в программу конференции

Безопасность Helm

Александр Хаёров

Helm - самый популярный пакетный менеджер для Kubernetes. Из-за новизны и отсутствия устоявшейся практики эксплуатация кластера с установленным Helm-сервисом может стать одной большой черной дырой или "root ssh" к вашей инфраструктуре.

В докладе будет подробно рассмотрена архитектура Helm и даны практические рекомендации, как сделать систему максимально безопасной. Остановимся подробно на взаимодействии с репозиторием чартов, серверной части - Tiller, настройке RBAC и service accout, а также переходу на использование K8s secrets для хранения релизной информации. Рассмотрим целесообразность tillerless-дизайна и его практическую применимость, а также поддержку нескольких профилей безопасности. Сделаем Helm полностью безопасным вместе!

Безопасность программного кода, SQL и прочие инъекции
,
Управление конфигурацией
,
Непрерывное развертывание и деплой
,
Непрерывная интеграция
,
Devops / другое
,
Безопасность инфраструктуры
,
HTTP/HTTPS
Доклад принят в программу конференции

Инфраструктурная платформа

Как мы меняли прописку сервисов с Mesos'а на Kubernetes

Александр Тарасов

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

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

Управление конфигурацией
,
Непрерывное развертывание и деплой
,
Менеджмент в эксплуатации
,
Devops / другое
Доклад принят в программу конференции

Развёртывание сервисов без downtime в производстве зубных протезов

Иван Голованов

В компании Adalisk (подрядчик крупнейшей в США компании по зубному протезированию Glidewell Dental) мы занимаемся автоматизацией производства зубных протезов – коронок, мостов, имплантов и т.д. Вся автоматизация производства находится в облаке и представляет собой микросервисную архитектуру.

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

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

Доклад принят в программу конференции

What's new in RRDtool and other stories from Tobi Oetiker's GitHub repo

Tobias Oetiker

I will give a short overview of RRDtools functionality and then go into some of the newer features. In the second part of the talk, I will present some other open source tools from my GitHub repo and tell the stories that lead to their creation.

Devops / другое
Доклад принят в программу конференции

История service mesh в Авито

Александр Лукьянченко

Расскажу о нашем пути в построении и внедрении Service mesh-решения. Посмотрим, какие проблемы такие решения позволяют устранить. Пройдемся по пути от внедрения Istio до написания собственного решения netramesh.

Технологии виртуализации и контейнеризации
Доклад принят в программу конференции

Логи не нужны?

Алексей Данилов

Современная разработка сильно изменилась за последние годы. Вместо монолитных приложений пришли микросервисы и функции. За ними базы данных из универсальных промышленных монстров стали более узконаправленными. Docker изменил взгляд на деплой. А изменилось ли наше представление о логах?

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

Логирование и мониторинг
Доклад принят в программу конференции

Инфраструктура компании как продукт

Артём Науменко

Задавали вы себе вопрос, сколько стоит ваша инфраструктура (сервера, зарплаты, внешние сервисы и тому подобное)?

* Можно ли рассматривать инфраструктуру как продукт?
* Можно и нужно ли считать ROI для инфраструктуры?
* Какие ключевые метрики выбрать для подсчета?
* Как работать над улучшением выбранных метрик?

Как мы строим инфраструктуру в Skyeng, и как это влияет на работу бизнеса. Реальный кейс из практики нашей команды.

Менеджмент в эксплуатации
,
Devops / другое
,
Методологии и процессы разработки ПО; Сроки и приоритеты
Доклад принят в программу конференции

Конференция фронтенд-разработчиков FrontendConf

Адаптация

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

Андрей Смирнов

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

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

Доклад принят в программу конференции

Новинки

Интерактивные проекции и 3D-маппинг с помощью web-технологий

Денис Радин

Многие из вас видели 3D-маппинг-шоу, но не многие из вас знают, что маппинг можно делать и с помощью web-технологий.

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

* Интерактивные проекции. Примеры.
* Почему web-технологии для проекций?
* Как это работает?
- CSS3D, метод, пример.
- WebGL, метод, пример.
* Преимущества.
* Проблемы.
* Как начать?

Фронтенд / другое
,
Оптимизация изображений
,
ES.Next
,
WebRTC, p2p
Доклад принят в программу конференции

Эмоциональное выгорание. История успеха

Анна Селезнёва

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

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

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

Доклад принят в программу конференции

Web Components, или Туда и обратно

Павел Малышев

* Что делать, если хочется больше ванилы?
* Готовы ли веб-стандарты для решения прикладных задач разработки?
* Есть ли жизнь после фреймворков?

Single page application, толстый клиент
,
Фронтенд / другое
,
React, Vue, Angular и другие JavaScript-фреймворки
,
ES.Next
Доклад принят в программу конференции

The state of CSS

Серёжа Попов

Ежегодный опрос https://stateofcss.com/ навёл много шуму, так как большое количество технологий, указанных в нём, оказалось для разработчиков новинкой. Хотя большинство из этих технологий уже используются теми, кто об этом знает.

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

Браузеры
,
Фронтенд / другое
,
Адаптивная вёрстка
Доклад принят в программу конференции

Простота. Надежность. WebAuthn

Алексей Носов

В Tomsguide пишут "It's Time to Kill Your Eight-Character Password". Но нет, настало время вообще избавиться от паролей, навсегда!

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

Безопасность в браузере
,
Мобильные приложения без native (PWA, AMP)
,
ES.Next
,
Node.js
,
Взаимодействие с серверной стороной (REST, GraphQL, gRPC)
Доклад принят в программу конференции

Производительность

New Adventures in Front-End, 2019 Edition

Виталий Фридман

The beast is alive! Have you optimized your JavaScript/CSS delivery for performance with HTTP/2 yet? How are you using service workers and server workers these days? What about critical CSS and Server Push? Are you compiling your code base into WebAssembly yet? How do you feel about ASCII-alike CSS Grid layout with polyfluid sizing and ch unit? Have you ever tried to work around nested CSS Custom Properties, untamed 3rd-party scripts, painful web font reflows, shady CSS Houdini tricks and multi-dimensional variable fonts? Well, let’s bring it on!

Take the techniques with a grain of salt — we do not take responsibility for sleepless nights and nightmares caused by the content of this session. Beware: you will not be able to unlearn what you’ll learn in the session!

Браузеры
,
Фронтенд / другое
,
Дизайн-системы
,
Мобильные приложения без native (PWA, AMP)
,
Препроцессоры CSS
,
Доступность (Accessibility - a11y)
,
ES.Next
,
Адаптивная вёрстка
Доклад принят в программу конференции

Самый низкий уровень: пишем на WebGL и WebAssembly без фреймворков и транскомпиляторов

Антон Хлыновский

Говоря о WebGL, часто имеют в виду three.js или другие похожие фреймворки. Новичок на поле веб-технологий WebAssembly уже начинает ассоциироваться с языками C или Rust. А как же, ведь нужные утилиты и обёртки WebGL и WebAssembly сложны и непонятны. Или же нет?

Мы познакомимся с самыми основами WebGL и WebAssembly и напишем на их основе несложное визуальное приложение, используя только базовое API.

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

Фронтенд / другое
,
WebRTC, p2p
Доклад принят в программу конференции

История одной анимации

Юрий Артюх

Будет рассказано об истории создания одной анимации от получения макета до сдачи клиенту. История включает в себя язык WebGL, Three.js, GLSL, Canvas 2D, графы и немного математики.

Фронтенд / другое
,
WebRTC, p2p
,
Производительность и мониторинг фронтенда
Доклад принят в программу конференции

Быстрые приложения в 2019

Иван Акулов

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

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

Доклад принят в программу конференции

Приложения

Разработка UI для банкоматов

Дима Королев

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

Single page application, толстый клиент
,
Мобильные приложения без native (PWA, AMP)
Доклад принят в программу конференции

Как стать свободным от "всех цепей" старых браузеров

Денис Красновский

Что делать, если ваше приложение собрано по фэн-шую, но несмотря на это, оно все еще остается слишком тяжелым? Настало время обратить внимание на старые браузеры.

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

Single page application, толстый клиент
,
Пакетные менеджеры и организация модульности
,
Браузеры
,
Производительность и мониторинг фронтенда
Доклад принят в программу конференции

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

Виктор Накоряков

- Какое бывает железо, что умеет, как с ним разговаривать.
- Способы физического сопряжения с PC.
- Какие варианты коммуникации есть у приложения на JS.
-- Пакет serialport + Firmata.
-- Пакет serialport + самописная прошивка на C++.
-- Espruino: программируем контроллер прямо на JS.
-- Raspberry Pi: обычный Linux-сервер, но с управляемыми ногами.
-- HTTP в локальной сети.
-- HTTP и MQTT через облако.

ES.Next
,
Взаимодействие с серверной стороной (REST, GraphQL, gRPC)
Доклад принят в программу конференции

WebGL на карте. Карта на WebGL

Мстислав Живодков

Недавно мы запустили обновленную версию 2gis.ru с новой 3D-картой, работающей на WebGL. Заходя на сайт, вы видите готовую картинку. Но карта — сложный механизм, в нем скрыто множество интересных деталей, о существовании которых можно даже и не подозревать.

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

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

WebRTC, p2p
Доклад принят в программу конференции

Как мы делали свой визуальный (WYSIWYG) редактор статей для Life.ru и не только

Алексей Авдеев

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

Доклад принят в программу конференции

«Алиса, пойдём во фронтенд!»

Никита Дубко

Голосовые помощники — уже не далёкое будущее, а реальная действительность. Алекса, Сири, Алиса и прочие встроенные в "умные" колонки боты постепенно меняют наш способ взаимодействия с приложениями.

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

Мобильные приложения без native (PWA, AMP)
,
Взаимодействие с серверной стороной (REST, GraphQL, gRPC)
Доклад принят в программу конференции

Особенности переноса нативного приложения в WEB, опыт KeepSolid Sign

Тимофей Лавренюк

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

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

Single page application, толстый клиент
,
Offline-приложения
,
ES.Next
,
Взаимодействие с серверной стороной (REST, GraphQL, gRPC)
Доклад принят в программу конференции

Качество

Hit Points вашего сервиса

Никита Мостовой

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

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

Давайте разбираться.

ES.Next
,
Производительность и мониторинг фронтенда
Доклад принят в программу конференции

Продвижение опенсорс-проектов

Андрей Ситник

Андрей Ситник, создатель популярных Автопрефиксера, PostCSS, Браузерлиста и Nano ID расскажет про свой опыт продвижения опенсорс-проектов.

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

Доклад принят в программу конференции

Синдром качества

Максим Соснов

Илья - крутой разработчик! Он многое знает и многое умеет, а главное, он умеет быстро поставлять ценность для пользователя и для бизнеса. Илья сделал неимоверное количество фич. Вроде все довольны и так бы оно и продолжалось, если бы, однажды, Илья не сказал: "Тут совсем плохой код, я буду делать фичу минимум полгода. Давайте лучше все перепишем!". Бизнес даёт добро и Илья проваливается на полгода в переписывание, которое завершается полным провалом.

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

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

Code Review
,
Автоматизация разработки и тестирования
,
Корпоративная культура и мотивация
,
Поиск и развитие команды
,
Продуктовая разработка
Доклад принят в программу конференции

From bloody to sweety Enterprise

Зар Захаров

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

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

За время работы в Альфа-Банке — от продукта к продукту — я развивал и оттачивал приложения, делая их лучше и удобнее в разработке; менял библиотеки, стараясь снизить порог вхождения для новых сотрудников, совершенствовал существовавшие и предлагал новые практики и подходы. В этом докладе я хотел бы рассказать о пройденном пути и опыте: показать, как устроен стек, объяснить, зачем используем NodeJs и что помогает сделать нашу работу легкой и непринужденной.

Доклад принят в программу конференции

Drag&Drop-компоненты для слепых пользователей. Вы шутите?

Сергей Кригер

Передвигать вещи для нас настолько естественно, что мы перенесли это из мира вещей в веб. Сортировка todo-списков, организация дашбордов, загрузка файлов — мы просто не можем себе представить все эти события без перетаскивания элементов на странице. А что, если бы мы не могли видеть экран? Было бы перетаскивание элементов все еще возможно и настолько же удобно, как прежде? Смогли бы мы выполнить все эти задачи без зрения?

В этом докладе вы узнаете основные принципы drag&drop-паттерна и как создавать перетаскиваемые элементы на странице доступными для людей с ограниченным зрением.

Фронтенд / другое
,
Доступность (Accessibility - a11y)
,
ES.Next
Доклад принят в программу конференции

Сравниваем ApolloClient и Relay, учимся работать с GraphQL-фрагментами

Павел Черторогов

В начале разберу архитектуру Apollo Client'а и Relay. Расскажу, что такое "волосатый" GraphQL, чем он полезен и чем отличается от RestQL. Покажу, как правильно использовать GraphQL на стороне клиента в react-apollo, как писать запросы «снизу-вверх» через фрагменты (прям как в фейсбуке). Все это дело подружу с TypeScript'ом, чтоб получить суровый интерпрайзный статический анализ.

Single page application, толстый клиент
,
ES.Next
,
QA / другое
,
Взаимодействие с серверной стороной (REST, GraphQL, gRPC)
Доклад принят в программу конференции

Инструменты

Реактивная печать PDF

Виталий Слободин

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

Браузеры
,
Фронтенд / другое
Доклад принят в программу конференции

Production Ready Design

Ксения Лушникова

В нашей команде Яндекс.Денег мы выработали подход разработки и дизайна веб-интерфейсов.

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

CSS фреймворки
,
Адаптивная вёрстка
Доклад принят в программу конференции

Автоматический рефакторинг кода с помощью codemodes

Александр Мышов

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

Сodemode - это скрипт, работающий с абстрактным синтаксическим деревом (ast) JavaScript. Цель codemode - автоматизировать рефакторинг кода.

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

Доклад принят в программу конференции

Токены в дизайн-системах

Юрий Ветров

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

Доклад принят в программу конференции

Lottie-web. Используем Adobe After Effects для анимации в web

Наталья Габитова

Существует ряд библиотек, позволяющих анимировать SVG: Snap.svg, Paper.js, Velocity.js и другие. Но им не хватает наглядности. Это делает работу над сложной анимацией прерогативой опытных креативных разработчиков и дистанцирует их от дизайнеров.

Поэтому наша команда взяла на вооружение еще один инструмент для работы над векторной анимацией: Adobe After Effects. В сочетании с плагином Bodymovin он позволяет создавать анимацию в формате json и воспроизводить при помощи библиотек Lottie не только в браузере, но и в мобильных приложениях на разных платформах.

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

Я расскажу о нашем опыте использования plugin’а, с какими сложностями мы столкнулись во время сложного анимационного проекта и как преодолевали их.

Оптимизация изображений
,
Дизайн-системы
,
WebRTC, p2p
Доклад принят в программу конференции

Как разрабатывать сотни A/B-экспериментов

Иван Бабков

А/Б-тестирование — это способ измерить эффективность нового функционала путем сравнения.

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

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

Фронтенд / другое
,
Методы и техника разработки ПО
,
Логирование и мониторинг
,
React, Vue, Angular и другие JavaScript-фреймворки
,
Внедрение и поддержка
,
Теории и техники анализа
Доклад принят в программу конференции

Самый мягкий и пушистый путь в Machine Learning и Deep Neural Networks

Алексей Охрименко

Если вы пытались научить машину чему-либо, если зачитали от корки до корки Machine Learning for Dummies, если вы заплатили за самые дорогие курсы по Deep Neural Networks, но у вас так ничего не получилось... то этот доклад для вас!

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

Мы научимся работать с TensorFlow.js - javascript-библиотекой для работы c Deep Neural Networks, отлаживать нейронные сети, генерировать данные для обучения и решать задачи, о решении которых вы раньше не могли и мечтать.

Доклад принят в программу конференции

В поисках Стилевого Грааля

Артур Кенжаев

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

В докладе мы обсудим преимущества и недостатки различных подходов к стилизации приложений в контексте дизайн-системы Яндекс.Маркета, обслуживающей несколько сильно различающихся проектов. Я поделюсь нашей историей этого непростого приключения в поиске Стилевого Грааля, когда Performance не мешает Developer Experience, и также расскажу про наши решения и инструменты, позволяющие проводить гибкие и сложные A/B-тесты с помощью стилизации и Dependency Injection.

Фронтенд / другое
,
Дизайн-системы
,
Мобильные приложения без native (PWA, AMP)
,
Препроцессоры CSS
,
CSS фреймворки
,
ES.Next
Доклад принят в программу конференции

Как перестать выбирать фреймворки и начать жить

Саша Шинкевич

Представьте, что перед вами стоит задача повесить полку. Как вы её будете решать? Можно сразу взяться за любимый инструмент: молоток и гвозди. Если вы Senior MolotokJS Developer, то сможете молотком забить не только гвозди, но и шурупы. А можно выделить время на исследование, нужна ли вам вообще полка.

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

Single page application, толстый клиент
,
React, Vue, Angular и другие JavaScript-фреймворки
,
ES.Next
Доклад принят в программу конференции

Анимация в вебе

Юлия Миоцен

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

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

Фронтенд / другое
,
Оптимизация изображений
,
Дизайн-системы
Доклад принят в программу конференции

Удобный CI своими руками

Дмитрий Кузнецов

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

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

Непрерывное развертывание и деплой
,
ES.Next
,
Тестирование фронтенда
Доклад принят в программу конференции

Конференция про качественную разработку IT-продуктов

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

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

Максим Цепков

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

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

Методы и техника разработки ПО
,
Методологии и процессы разработки ПО; Сроки и приоритеты
,
Проектные артефакты, инструментарий
,
QA / другое
Доклад принят в программу конференции

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

Дмитрий Емельянов

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

Доклад принят в программу конференции

Вкусный BDD с секретным ингредиентом

Александр Здрачек

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

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

Я расскажу, как у нас получилось оживить BDD, превратить Gherkin-сценарии в пользовательские истории и привлечь аналитиков к написанию автотестов.

Внедрение и поддержка
,
Проектные артефакты, инструментарий
,
Автоматизация тестирования
Доклад принят в программу конференции

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

Михаил Никитин

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

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

Доклад принят в программу конференции

Инженерные практики, способствующие созданию качественного продукта

Как Stop the Line помог нам ускорить выкладку в 10 раз за 3 месяца

Антон Бевзюк

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

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

Я расскажу о практике «Stop the Line», которая помогла нам системно решить проблему развертывания. Всего за три месяца нам удалось полностью избавиться от ручного тестирования, исправить нестабильные тесты и ускорить развертывание более чем в 10 раз. Сегодня релизный цикл монолита — всего за 4-5 часов.

Непрерывное развертывание и деплой
Доклад принят в программу конференции

How to keep the software soft?

Артем Малышев

Одна из основных задач во время разработки программного обеспечения — это минимизация сроков. Сроков выхода новых фич и исправления багов. Принимаемые нами решения, такие как выбор Web-фреймворка, базы данных, синхронного или асинхронного подхода, влияют на это минимально. Основные проблемы создаём мы сами, отвязывая код нашего продукта от предметной области. Мы перестаём мыслить системно, потому что весь день смотрим на хитросплетения HTTP-запросов с ActiveRecord. Игнорируя необходимость грамотного структурировать проект, мы закладываем бомбу технического долга, которая может рвануть в любой момент.

На самом деле это не мы такие плохие и ленивые, не хотим читать умных книжек по Domain Driven Design. При всём желании грамотно построить сервис на абстрактных Django или Rails очень тяжело. Инструменты как будто сопротивляются изменению привычных подходов "тяп-ляп и в production".

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

Примеры будут на dry-python. Но доклад не про python, а про ценные общие подходы, которые применимы к другим языкам программирования.

Любителям DDD, BDD, TDD и *DD быть обязательно!

Фреймворки
,
Python
,
Архитектурные паттерны
,
Стандарты кодирования
,
Разделение представления и бизнес-логики, шаблонизация
Доклад принят в программу конференции

Особенности мониторинга высоконагруженных frontend-приложений

Артур Хинельцев

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

Я расскажу, как видоизменяются общепринятые практики мониторинга при росте нагрузки приложения на примере проекта "Почта Mail.ru" - крупнейшего SPA рунета, а именно:

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

Фронтенд / другое
,
ES.Next
,
QA / другое
,
Производительность и мониторинг фронтенда
Доклад принят в программу конференции

Can Distributed Teams Deliver Quality?

Егор Бугаенко

It is a well known trend: software teams are becoming more distributed. Programmers work from home, communicate remotely, contribute via pull requests, and chat in Slack. How does it affect the quality of software? Can those distributed teams compete with co-located ones? Many managers think that it’s impossible, because real quality is achievable only when people know each other personally and have direct face-to-face contacts on a daily basis. How true is that? I will demonstrate that it’s not true and will illustrate my thoughts with practical examples.

Модели руководства
Доклад принят в программу конференции

Как создать качественный статический анализатор

Сергей Хренов

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

Доклад принят в программу конференции

Blameless environment: никто не должен писать качественный код

Никита Соболев

Мы все тысячи раз слышали тезис "программисты должны писать качественный код". И все всегда кивают головами и соглашаются с ним. А меня никак не покидает вопрос: кому они должны?

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

Скажу даже больше: попросите определить слово "качество" группу людей – так они все переругаются. Может быть, даже подерутся.

А могут ли, вообще, программисты писать качественный код? Штука в том, что все мы – люди. Мы не можем писать качественный код. Он слишком сложен для нас. Мы будем стучаться головой о сложность, допускать ошибки проектирования, пропускать баги и наступать на одни грабли: просто потому, что можем.

Могут ли люди писать качественный код? Нет.
Должны ли они? Решать вам.
Есть ли способ повысить качество без регистрации и смс? Есть.

О нем – на докладе.

Доклад принят в программу конференции

Тестируем на проде: Canary Deployment

Андрей Маркелов

Мониторинг — это тоже тестирование?!

Современные сервисы хотят релизиться несколько раз в день. Devops уже проник в сознание, написано множество автоматизированных тестов на хипстерских (и не очень) фреймворках. Но действительно ли вы уверены, что ваши тесты покрывают все случаи? А есть ли возможность повторить сценарии на разных окружениях? Иногда бывает, что нет :-(

Бывает, что тестировать на тестовом окружении слишком дорого, но не тестировать и жертвовать качеством слишком рискованно. Как раз в таком случае хорошо бы иметь возможность БЕЗОПАСНО проверить новую версию на проде и сделать это можно, используя подход Canary Deployment.

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

Фреймворки
,
Java
,
Прочие языки
,
Бэкенд / другое
,
QA / другое
Доклад принят в программу конференции

Моб-программирование. Системный взгляд

Роман Дорошенко

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

Но как же быть с эффективностью? Ведь все эти люди могли бы сделать больше, работая параллельно? Или нет?

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

Доклад принят в программу конференции

Процесс, ориентированный на качество

Allure server: cкладываем тестовые артефакты в одну корзину

Антон Башкиров

Когда у вас на проекте несколько десятков тысяч тестовых кейсов, а кейсы на разные уровни системы описаны в различных местах и зачастую дублируют друг друга, то их анализ и актуализация превращается в полный хаос и вызывает боль. Мы смогли побороть подобный хаос путём перехода к единой упорядоченной экосистеме. В этом нам помог Allure Server (не путать с Allure Report). В докладе я расскажу о нашем переходе к Test Cases as a code, как мы научились использовать все артефакты тестирования в качестве структурированной документации о нашем продукте и как такой подход помогает нам сделать пирамиду тестирования прозрачной на всех ее уровнях.

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

Доклад принят в программу конференции

Метрики - индикаторы здоровья проекта

Руслан Остропольский

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

Для этого нужны метрики!

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

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

Доклад принят в программу конференции

Автотесты есть? А если найду?

Алексей Петров

В погоне за качеством эволюционно развивая тестирование компании, ее сотрудники в определенный момент сталкиваются с потребностью в автоматизированных тестах. Одними движет хайп на уровне "У всех есть, пусть и у нас будут! Зачем? Потом разберёмся!", другими — реальные потребности в сокращении временных затрат на ручное тестирование (вплоть до полного отказа от ручного тестирования), третьими — желание ускорить получение обратной связи о качестве продукта на разных этапах производственного цикла.

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

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

Доклад принят в программу конференции

Key quality indicators. Качество работы сервиса, как его видит пользователь. Измеряем и улучшаем

Евгений Михин

Внедряем customer-driven-подход к управлению качеством.

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

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

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

Логирование и мониторинг
,
Доступность (Accessibility - a11y)
,
Управление / другое
,
Общение с заказчиком, извлечение требований
,
Аналитика / другое
Доклад принят в программу конференции

Вредные советы по тестированию фронтенд-приложений

Александр Казаченко

* Зачем нужно писать тесты на фронте.
* Какие виды тестов можно и нужно писать.
* Тестирование — это коллективная работа.
* Пирамида тестирования — это важно.
* Каким должно быть приложение, чтобы его можно было тестировать.
* И самое главное — чего НЕ нужно делать в тестах.

Single page application, толстый клиент
,
Фронтенд / другое
,
Автоматизация разработки и тестирования
,
Автоматизация тестирования
,
Юнит-тестирование
,
Тестирование фронтенда
Доклад принят в программу конференции

Круглый стол "Что такое качество?"

Анастасия Асеева-Нгуен

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

Мы разберём эти вопросы с экспертами из разных областей.

Доклад принят в программу конференции

Стратегии тестирования во время перехода от монолита к микросервисам

Екатерина Засухина
Екатерина Корзина

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

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

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

Непрерывное развертывание и деплой
,
Непрерывная интеграция
,
Методологии и процессы разработки ПО; Сроки и приоритеты
,
Продуктовая разработка
,
QA / другое
Доклад принят в программу конференции

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

Запад

Подводные камни межкультурных коммуникаций

Алексей Куксенок

Задумывались ли вы, почему сотрудники, работающие в иностранных компаниях, жалуются на некоторые проблемы на работе, про которые даже не упоминают их российские коллеги? Например, «не нравится мне наш иностранный заказчик, какой-то он нелюдимый, ни улыбнется, ни пошутит!», «новый начальник из Европы робот какой-то! Не отпустил меня вчера с обеда домой! А мне в налоговую надо было!», «позвал нового коллегу из Германии в ресторан, так сказать, проект обсудить, а он отказал! Сказал, что все вопросы надо решать на работе! Я к нему, как к человеку, а он вон как! Не понятно...» и т.д.?

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

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

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

Доклад принят в программу конференции

Продукт

Управлять невидимым: о внутренних IT-продуктах без прикрас

Ольга Алексеева

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

Я расскажу об этом и о других вызовах управления внутренними продуктами. Меня зовут Ольга, я больше 12 лет работаю в IT. Сейчас я руководитель группы продуктового развития в Operations компании Lamoda. Итак:

* Продакт-менеджмент в крупных компаниях. Почему это часто выглядит не так, как себе представляют после хороших бизнес-школ и курсов начинающих продактов?
* "Внешние" продукты (b2b, b2c, b2g...) VS продукты для внутреннего использования. В чем разница для продакт-менеджера? Почему может показаться, что идти развивать внутренний продукт не так интересно, как любой внешний сервис?
* Как на внутренний продукт смотрят бизнес-стейкхолдеры (спойлер: внимательнее, чем вы думаете). Как увидеть во внутреннем продукте business value / business fit и уметь их показать.
* "Работает — не трогай", или на что ради вас готов стейкхолдер. Как снизить страх перед изменениями и заработать кредит доверия.
* SNAFU: откуда берется продуктовый конфликт, как им управлять и чем он может быть полезен.
* Управление требованиями, управление ожиданиями и управление внутренним продуктом: в чем разница? В какой момент вы становитесь из менеджера продукта менеджером бэклога? Как этого избежать?
* Незаметное превращение из отважного рыцаря в ужасного дракона: немного о cамых опасных ошибках управления продуктом. Что нужно сделать для того, чтобы случайно не остановить всю разумную деятельность одним своим приходом на встречу? Каким нужно быть, чтобы не быть самым бесполезным человеком в компании?

Методологии и процессы разработки ПО; Сроки и приоритеты
,
Оценка сложности проекта
,
Продуктовая разработка
,
Управление изменениями, управление требованиями
,
Общение с заказчиком, извлечение требований
Доклад принят в программу конференции

Agile

Как выжать максимум изменений и не умереть

Михаил Вязанкин

Вы задаетесь вопросами:
* Сколько стоят изменения?
* Когда они окупятся?
* Как это работает?
* Сколько изменений можно запускать одновременно и как это работает?
* Как выжать из вашей трансформации максимум и не остановить бизнес?
* Почему изменения откатываются?

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

Доклад принят в программу конференции

Бизнес и финансы

Мастер-класс "Как презентовать стартап потенциальному инвестору"

Александр Горный

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

1. Суть идеи. Коротко как выстрел. Простым и понятным языком. "Uber для мусоровозов". Вы должны объяснить, о чем идет речь, что это вообще такое. Иногда полезно рассказать ещё и зачем оно нужно. Иногда все очевидно.
2. Рынок. SAM, TAM, SOM - что значат эти заклинания, зачем нужны и как их считать. Инвестор хочет знать, до каких масштабов может дорасти компания. Вырасти в 2 раза или в 2000.
3. Экономика одной продажи. Инвестор хочет понять, а будет ли когда-нибудь прибыль, а не только выручка.
4. Исторические результаты. Что показывать и с какой точностью? А почему именно так? Инвестор хочет увидеть, что уже сделано, и как быстро вы бежите вперед. Команда (а не идея) оценивается именно по этому слайду.
5. Прогнозы. Понятно, что хорошие. Но насколько?
6. Команда. Обязательно подчеркиваем сочетание "умения" и "знания".
7. Предложение инвестору. Здесь ещё раз показываем свою вменяемость. Это тоже оценка команды.

Бонус-трек: вообще-то, основатель — главный инвестор в свое детище. Часто полезно посмотреть на него со стороны, глазами человека нейтрального.

Доклад принят в программу конференции

Финансовое планирование в ИТ. Что от вас хочет финансовый директор или инвестор

Наталья Баранова

* Можно ли обойтись без финансового планирования?
* Какие бюджеты надо составлять и зачем. CAPEX и OPEX для IT, почему это важно.
* Планирование текущих расходов — методы, убедительные для финансового директора и бизнес-заказчика.
* Планирование инвестиций в ИТ — разработка ПО, железо, модернизация, автоматизация процессов и т.д. На каком горизонте времени считать.
* Оценка эффективности инвестиций в ИТ — возможная или обязательная опция финансового планирования?

Доклад принят в программу конференции

Формирование ставок и тюнинг рентабельности для аутсорс-продакшна

Андрей Рыжкин

Рано или поздно у любого руководителя аутсорс-продакшна встает вопрос: сколько реально стоит час моего специалиста? И за сколько его можно продавать?

Есть разные подходы к формированию стоимости часа: сделать «среднюю по рынку», умножить ставку за час от зарплаты на число ПИ, платить разработчику х% от ставки часа — «а там за сколько купят» и т.д.

Каждый из подходов имеет свои подводные камни, например:
— На сколько часов делить ЗП специалиста? 164 ч? А отпуска? А болезни? А сколько эффективного времени заложить? А гарантийные и не оплачиваемые работы куда включить? А сколько рисков должно быть в ставке?
— Как учесть условно-постоянные расходы (УПР), если они постоянно разные?
— Как учесть менеджмент? А при аутстаффе?
И еще очень много подобных вопросов!

В нашей компании более 370 специалистов трудятся в единый момент времени, у нас большой офис в центре Москвы и при этом мы умудряемся держать рентабельность производства >=20%.

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

В своем докладе я постараюсь рассказать, как мы этого добились, и раскрыть следующие тезисы:
* подходы к формированию стоимости часа: от затрат, от «среднерыночной», от ставки конечного специалиста;
* как разделить УПР на специалистов; инхаус и аутсорс;
* как правильно закладывать гарантийные работы, менеджмент, риски в ставку часа специалиста;
* что такое «оверхед», как его считать и для чего;
* что меняется при разных моделях работ (fix price, T&M, выкуп) и на что это влияет: менеджмент, кол-во часов для расчета, риски;
* нюансы при разных моделях работ: контроль сметы, таймтрекинг и таймшиты, простой специалистов;
* грейды по специалистам (зарплаты и ставки);
* контроль рентабельности с разной детализацией: компания, департаменты, отделы, команда, проект;
* система мотивации для разных ролей: топ-менеджеры (руководители компании/отделов), менеджеры/тимлиды;
* окупаемость и загрузка специалистов (это не одно и то же! давайте разберемся, почему).

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

Продажи, конкуренция и аналитика
,
Работа со внешним заказчиком/исполнителем
,
Управление / другое
,
Другое
Доклад принят в программу конференции

Анализ

Когортный анализ в Google Analytics дешево и сердито

Ирина Назарова

Пошаговая инструкция, как начать тестировать гипотезы в разработке продукта, используя те инструменты, которые у вас уже есть: Google Analytics, Google Sheets и ни единой строчки кода. Мы взламываем GA, чтобы получить те функции, которые недоступны из интерфейса — возможность строить когорты и получать данные, которые позволяют отслеживать воронки внутри каждого инструмента и фичи, гибко подсчитывая интересующие нас действия.

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

Доклад принят в программу конференции

Истории успеха

Бизнес со смыслом: как построить компанию, которая переживет 20-летие

Владимир Рахтеенко

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

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

Доклад принят в программу конференции

Проектирование

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

Евгений Романовский

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

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

Доклад принят в программу конференции

Стратегия

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

Аркадий Морейнис

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

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

Доклад принят в программу конференции

Шеф, все пропало! Что делать предпринимателю, если он понял, что его стратегия не работает

Слава Злобин

1. «А был ли мальчик?» - Была ли у нас стратегия, и придерживались ли мы её? Реконструкция понятия.
2. "А нужен ли нам мальчик?" - Стратегии малого и микробизнеса - миф или реальность.
3. Способы выхода из ситуации неработающей стратегии: купить, узнать, не обращать внимания.
4. Стратегия ничто. Стратегирование - почти все. Устройство и ловушки процесса.
5. Элементы стратегической игры: поле, игроки, предметы и представления.
6. SOODA - Stop-Observe-Orient-Decide-Act и другие способы играть. Какие перки и тулзы нужны предпринимателю.

Доклад принят в программу конференции

Нетология-групп: (неоконченная) история одного стартапа

Максим Спиридонов

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

Рассказ о 8 годах жизни предпринимателей. О росте от 2 сотрудников до 1000+. О продаже квартиры, машины и вложения всех личных денег в проект. О попадании в список "20 самых дорогих компаний Рунета" от Forbes с оценкой $72 миллиона. И выводах, которые мы из этого сделали.

Доклад принят в программу конференции

Процессы

Управление производством на основе анализа данных в агентстве заказной разработки

Сергей Кожемякин

* HR. Подбор и работа с персоналом на основании анализа конверсии воронок и анализа данных опросов.
* Оценка эффективности сотрудников. Рентабельность производства во главе угла, иерархическая вложенность целей сотрудников от топов до исполнителей, замеры рентабельности на всех уровнях. Принятие кадровых решений на основании эффективности.
* Client service. Обзвоны клиентов, сбор CJM, маппинг с внутренними регламентами, внедрение улучшений.
* Продуктовые метрики. Учёт продуктовых метрик в качественных KPI сотрудников. Нацеленность на качество продукта и учёт данных Client service в KPI.

Большие проекты/команды
,
Модели руководства
,
Корпоративная культура и мотивация
,
Поиск и развитие команды
Доклад принят в программу конференции

Как спланировать полгода разработки 40 команд за 3 дня

Анжела Дружинина

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

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

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

Доклад принят в программу конференции

Бюрократ и художник. Искусство баланса в процессном управлении

Дмитрий Смирягин

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

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

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

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

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

Доклад принят в программу конференции

Как мы не любили HR. История факапа, превратившаяся в историю успеха

Ольга Куликова

Articul Media — одно из ведущих digital-агентств на российском рынке. Компания являлась одним из основных подрядчиков по разработке digital-экосистемы Олимпиады Сочи-2014, включая олимпийский сайт. У нас более 100 наград российских и международных фестивалей рекламы, включая Webby Awards (интернет-оскар).

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

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

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

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

Доклад принят в программу конференции

Команда

Инженерная культура. Что в нее нужно включить и как ее внедрять

Дмитрий Круглов

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

Инженерная культура — это про другое. Это про такие вопросы, как:
* что такое хороший код?
* какими должны быть комментарии к pull request'ам?
* почему антипаттерны — это зло?

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

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

Корпоративная культура и мотивация
,
Поиск и развитие команды
,
Профессиональное развитие инженера
Доклад принят в программу конференции

Клиенты и продажи

4 модели построения отдела продаж

Михаил Кондратенко

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

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

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

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

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

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

Выбор стратегии долгосрочного развития, KPI
,
Продажи, конкуренция и аналитика
Доклад принят в программу конференции