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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чем хорош Event Storming?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. Никто не знает, где находятся серверы, как они настроены, у кого спрашивать пароли, что с бэкапами. У вас есть только доступ к SSH к нескольким серверам с аптаймом больше года, на которых критические сервисы не добавлены в автозагрузку.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 Sheets и ни единой строчки кода. Мы взламываем GA, чтобы получить те функции, которые недоступны из интерфейса — возможность строить когорты и получать данные, которые позволяют отслеживать воронки внутри каждого инструмента и фичи, гибко подсчитывая интересующие нас действия.

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

В России постепенно формируется интерес к бизнес-моделям, ориентированным не на быстрый финансовый результат, а на долгосрочное существование и масштабные ценности — развитие, экологичность, социальную значимость. Естественно, что такой тип бизнеса имеет свою специфику в выборе рыночной ниши и целевой аудитории, развитии продуктовой концепции, выстраивании взаимоотношений с сотрудниками и партнерами. Основатель 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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