ManyChat приглашает 22 сентября в 19:00 (мск) на Product Engineering Meetup #2 — вторую встречу из серии митапов, посвящённых особенностям продуктовой разработки в ИТ-компаниях.
В прошлом году мы провели первый митап, чтобы разобраться, кто такой продуктовый инженер, зачем разработчику развивать продуктовое мышление и как находить баланс между техникой и продуктом.
На предстоящей, второй, встрече мы сфокусируемся на культуре разработки в продуктовых компаниях.
Вместе со спикерами из Badoo, ManyChat, Додо Пицца и Работа.ру поговорим о том, какие практики помогают командам создавать качественные продукты. Обсудим, какие процессы разработки помогают фокусироваться на донесении ценности пользователям и соблюдать сроки. Рассмотрим, как находить компромисс между бизнесом и разработкой и определять границы ответственности.
Доклады
История эволюции фичи: от MVP до одной из основных функциональностей продукта — Евгений Жуков, Backend Developer (ManyChat)
Я расскажу историю интеграции ManyChat с Shopify — одной из ведущих платформ в электронной коммерции. Из доклада вы узнаете, как собранный за неделю на коленке MVP эволюционировал в течении года и вырос в полноценное отдельное направление в нашем продукте. Поделюсь проблемами версионирования, с которыми мы столкнулись. И расскажу о метриках: какие используем мы, и как именно они нам помогают.
Как перестать беспокоиться и начать верить А/Б тестам — 2 — Максим Кислов, Frontend Engineering Manager (Badoo)
После того как вы победили А/Б тесты и интегрировали их в свое рабочее окружение, кажется, что все позади. На самом деле приключение только начинается: у команды нет накопленной экспертизы, процессы не налажены, а бизнес хочет полагаться на А/Б тестирование для принятия ключевых решений и ожидает результатов. Я расскажу:
- как организовать работу с А/Б тестами внутри компании;
- как дать бизнесу ответ на вопрос «ну как там наш тест?»;
- как определить границу ответсвенности техлида и разделить ответственность с продактом.
Инициатива не наказуема. Почему разработчика важно погружать в продуктовую жизнь — Лаша Харчилава, Ведущий Менеджер Продукта (Работа.ру)
- Что нужно сделать в первый день новому продакту, чтобы жизнь разработчика стала лучше.
- Что такое продуктовый онбординг и зачем он разработчику.
- Для чего нужны разработчики в краткосрочном и среднесрочном планировании продуктовых задач.
- План к действию: есть проблема — сначала спроси у разработчика.
- Какая связь между разработчиками и результатами АБ-теста.
Как релиз продукта вышел на полгода позже, а пересмотр процессов разработки научил нас попадать в сроки — Борис Герн, B2C Product Lead (Додо Пицца)
Существует много различных методологий разработки, мы в Додо постоянно экспериментируем с ним комбинируя разные фреймворки.
У каждой команды в Додо свой подход в построении процессов, важно как можно раньше найти свой, иначе компании будет сложно масштабироваться.
В презентации рассказывается о том, как команда одного из наших продуктов приходила к своему рабочему процессу:
- Какие ошибки были совершены на старте
- В какой момент мы поняли, что что-то идет не так
- Какие шаги предпринимали, чтобы исправить ситуацию
- Какие практики и процессы оказались рабочими, что мы используем сейчас
- Какие выводы мы сделали и как планируем применить это в будущем
Product Engineering Meetup #2 «Культура разработки в продуктовых компаниях»
- Анонс
- Программа
- Участники
- Спикеры
ManyChat приглашает 22 сентября в 19:00 (мск) на Product Engineering Meetup #2 — вторую встречу из серии митапов, посвящённых особенностям продуктовой разработки в ИТ-компаниях.
В прошлом году мы провели первый митап, чтобы разобраться, кто такой продуктовый инженер, зачем разработчику развивать продуктовое мышление и как находить баланс между техникой и продуктом.
На предстоящей, второй, встрече мы сфокусируемся на культуре разработки в продуктовых компаниях.
Вместе со спикерами из Badoo, ManyChat, Додо Пицца и Работа.ру поговорим о том, какие практики помогают командам создавать качественные продукты. Обсудим, какие процессы разработки помогают фокусироваться на донесении ценности пользователям и соблюдать сроки. Рассмотрим, как находить компромисс между бизнесом и разработкой и определять границы ответственности.
Доклады
История эволюции фичи: от MVP до одной из основных функциональностей продукта — Евгений Жуков, Backend Developer (ManyChat)
Я расскажу историю интеграции ManyChat с Shopify — одной из ведущих платформ в электронной коммерции. Из доклада вы узнаете, как собранный за неделю на коленке MVP эволюционировал в течении года и вырос в полноценное отдельное направление в нашем продукте. Поделюсь проблемами версионирования, с которыми мы столкнулись. И расскажу о метриках: какие используем мы, и как именно они нам помогают.
Как перестать беспокоиться и начать верить А/Б тестам — 2 — Максим Кислов, Frontend Engineering Manager (Badoo)
После того как вы победили А/Б тесты и интегрировали их в свое рабочее окружение, кажется, что все позади. На самом деле приключение только начинается: у команды нет накопленной экспертизы, процессы не налажены, а бизнес хочет полагаться на А/Б тестирование для принятия ключевых решений и ожидает результатов. Я расскажу:
- как организовать работу с А/Б тестами внутри компании;
- как дать бизнесу ответ на вопрос «ну как там наш тест?»;
- как определить границу ответсвенности техлида и разделить ответственность с продактом.
Инициатива не наказуема. Почему разработчика важно погружать в продуктовую жизнь — Лаша Харчилава, Ведущий Менеджер Продукта (Работа.ру)
- Что нужно сделать в первый день новому продакту, чтобы жизнь разработчика стала лучше.
- Что такое продуктовый онбординг и зачем он разработчику.
- Для чего нужны разработчики в краткосрочном и среднесрочном планировании продуктовых задач.
- План к действию: есть проблема — сначала спроси у разработчика.
- Какая связь между разработчиками и результатами АБ-теста.
Как релиз продукта вышел на полгода позже, а пересмотр процессов разработки научил нас попадать в сроки — Борис Герн, B2C Product Lead (Додо Пицца)
Существует много различных методологий разработки, мы в Додо постоянно экспериментируем с ним комбинируя разные фреймворки.
У каждой команды в Додо свой подход в построении процессов, важно как можно раньше найти свой, иначе компании будет сложно масштабироваться.
В презентации рассказывается о том, как команда одного из наших продуктов приходила к своему рабочему процессу:
- Какие ошибки были совершены на старте
- В какой момент мы поняли, что что-то идет не так
- Какие шаги предпринимали, чтобы исправить ситуацию
- Какие практики и процессы оказались рабочими, что мы используем сейчас
- Какие выводы мы сделали и как планируем применить это в будущем