В компании ИВИ, ведущем онлайн-кинотеатре, наша команда разработчиков занимается созданием приложения для платформы Android. Недавно мы успешно выпустили версию для Android TV, используя инновационный инструмент — Jetpack Compose. Несмотря на то, что библиотека Compose для ТВ еще находится в альфа-версии, мы хотим поделиться своим опытом, рассказать о трудностях, с которыми столкнулись, и обратиться к вопросу: стоит ли использовать Jetpack Compose, особенно для ТВ-приложений?
Привет, Хабр! Меня зовут Евгения Савельева, я руковожу отделом UX-исследований в Иви. С коллегами мы шутим: исследования как сериал - всегда есть что-то, что узнаешь только в следующей серии. А еще, по результатам исследований у нас самые интересные встречи! Решили рассказать, как устроены UX-исследования* в Иви: благодаря им растут не просто метрики, а нечто более важное – любовь пользователей.
Во многих компаниях UX-исследователи работают либо как агентства внутри компании, либо исследователь прикреплен к продуктовой команде. У нас получился гибридный подход: с одной стороны, наш UX-отдел универсален и делает исследования для всех. С другой, исследователи довольно сильно интегрированы в процесс разработки продукта.
В этой статье я расскажу о наших процессах, их влиянии на эффективность работы, а также о лайфхаках, как небольшая команда исследователей из двух человек может успевать делать все необходимое.
Приветствую тебя, %username%! Меня зовут Владимир Жуков, и я не хочу впаривать тебе очередную историю успешного успеха про Kubernetes. Я хочу рассказать о наших кластерах Kubernetes с необычной архитектурой. «Что же там необычного?» спросишь ты. Это самая сложная и непонятная часть кластера, это сеть. Я знаю, что идея плоской сети не новая и применяется много у кого, но кажется об этом еще не кто тут не писал.
На днях студент нашей совместной с МАИ магистратуры дал очень интересный комментарий. Это было по мотивам лекции, на которой я рассказывал о целях по SMART, тайм-менеджменте и способах планировать рабочее и личное время.
"Меня удивил лектор. Человек уже давно не подросток, имеется отличный статус в компании, многого добился, но не останавливается на своём развитии.
Раньше мне казалось, что учиться нужно в школе и универе, а потом устроиться на работу и отдыхать, ведь ты всё уже знаешь.
Но оказывается в развитии личности нет предела, можно стараться стать лучше сколько захочешь. Главное найти правильный вектор, "правильно ставить правильные цели" и окружаться себя такими же, желающими развиваться, людьми."
И, несмотря на сохраненную авторскую пунктуацию, на этом можно было бы закончить эту статью.
Но в этом случае наш HR-департамент меня не похвалит :-)
На IVI пользователи выбирают кино для просмотра, ориентируясь в первую очередь на постер и название фильма. Обычно правообладатель предоставляет один постер для каждого фильма и сериала, но бывают ситуации, когда могут понадобиться дополнительные/альтернативные изображения. Их создание — трудоемкая задача, потому что с помощью этих изображений нужно передать содержимое контента. Чтобы упростить её, мы прибегаем к генерации синтетических постеров. В этой статье я немного приоткрою занавес и расскажу о том, как мы удаляем визуальный мусор в процессе создания постеров.
Это вторая часть статьи про нашу дизайн-систему. Первая часть выходила раньше.
В этот раз речь пойдёт о философии нашей работы, взаимодействии с дизайнерами и клиентскими разработчиками; о трудностях, с которыми сталкиваемся, и как их преодолеваем; о том, как мы развиваем нашу ДС.
Дизайн-система в нашей компании существует с 2018 года. По поводу неё уже была статья от дизайнеров и выступление от техдиректора. Самое время рассказать, как ситуация выглядит изнутри самой дизайн-системы.
По мере написания стало понятно: материала слишком много, чтобы уложить его в одну статью. Поэтому чуть позже мы опубликуем вторую часть.
В первой же части статьи речь пойдёт о том, как и почему у нас появилась дизайн-система; как она устроена и что в ней хранится; как клиентские приложения IVI получают и обрабатывают данные из дизайн-системы; как мы добавляем в ДС новые сущности и как избавляемся от устаревших.
Меня зовут Святослав, в онлайн кинотеатре IVI я отвечаю за бета-тестирование. Хочу рассказать вам про то, как пользователи сервиса могут принимать активное участие в его тестировании, получать от этого удовольствие и вносить неоценимый вклад в его качество.
Как можно измерить успех бизнеса? Конечно, бизнес-метрики типа выручки и количества транзакций, продуктовые метрики и доля рынка помогают оценить, насколько востребован сервис, но этого не всегда достаточно. Очень полезно понимать впечатления и эмоции, которые получает клиент от использования продукта — это дает возможность понять, что нужно улучшать. Именно поэтому у нас в IVI действует целая система измерений пользовательского опыта, которая позволяет всей компании узнать альтернативную точку зрения на то, как клиенты оценивают наш сервис.
При этом впечатления и эмоции измерить очень сложно, потому что у нас есть много точек контакта и огромное количество часто противоречивой обратной связи от пользователей. Кроме того, у менеджеров и разработчиков есть личные ощущения от продукта — мы сами внутри очень часто обмениваемся мнениями, что нам в нашем сервисе нравится, а что нет.
Как же преобразовать все это восприятие в цифры и количественные показатели?
В нашей компании в стеке разработки есть язык Go. И иногда, при написании unit-тестов к приложениям написанным на Go, у нас появляются сложности. В этой статье мы расскажем о некоторых моментах, которые мы учитываем при написании тестов. На примерах разберём как их можно использовать.
В этой статье мы не откроем ничего нового об устройстве монолита и микросервисной архитектуры. Про это сказано немало слов, написано ещё больше. Мы расскажем о том, как через это прошла наша компания и какие преимущества и недостатки микросервисной архитектуры мы для себя обнаружили.
IVI – кросс-платформенный сервис, а значит, мы должны анализировать метрики всюду: на вебе, телевизорах и мобильных приложениях. Продукт непрерывно развивается, чтобы стать максимально эффективным, удобным и повысить ценность и привлекательность подписки. Перед тем, как внедрить какую-то новую фичу, мы проводим a/b-тесты и исследуем, на сколько востребованным окажется нововведение и как оно повлияет на конверсию или смотрение. Одновременно у нас может проверяться до 70-ти гипотез, от которых непосредственно зависят планы по развитию продукта.
Для того, чтобы правильно оценить успешность или неуспешность теста, требовалось технологичное решение. Новая схема ETL позволила нам иметь хранилище, толерантное к дубликатам. При ошибке в коде мы всегда можем откатить consumer offset в kafka и обработать часть данных снова, не прилагая лишних усилий для движения данных. Хотим рассказать о том, как мы в IVI используем ClickHouse, чтобы посчитать метрики для решения разных продуктовых задач и понять, что мы действительно делаем продукт лучше, а не придумываем фичи, которыми никто не будет пользоваться.
Недавно наш СТО Евгений Россинский @eross пообщался с ведущими подкаста “Подлодка” про роль СТО. По мотивам этого общения мы подготовили две статьи с основными вопросами о СТО - как им стать и каково им быть, как его найти и сколько это стоит. Сегодня мы публикуем вторую часть этого интервью (первую часть можно прочитать тут).
Недавно наш СТО Евгений Россинский пообщался с ведущими подкаста «Подлодка» про роль СТО. По мотивам этого общения мы подготовили две статьи с основными вопросами о СТО — как им стать и каково им быть, как его найти и сколько это стоит.
При возникновении необходимости миграции с одной конфигурации поставщика на другую, либо при обновлении доработанной конфигурации, если Поставщик позднее добавил тот объект, что был у нас добавлен самостоятельно, может оказаться, что старый и новый объекты имеют разные внутренние идентификаторы. При сравнении/объединении конфигураций видно, что старый документ не находит соответствие с новым, так как у них различные внутренние идентификаторы метаданных, а при загрузке (обновлении) новой конфигурации поставщика старый документ удаляется вместе со всеми введенными документами.
Всем привет! Меня зовут Владимир Касаткин, и я работаю бэкенд-разработчиком в компании ivi.ru, в команде "UX". Цель этой статьи — показать, как мы уменьшили объём клиентской разработки, но при этом увеличили количество проводимых A/B-тестов.
Раньше вся продуктовая разработка была разбита на большие направления ("платформы"): бэкенд, Smart TV, iOS, Android, веб. При этом фичи пилились достаточно долго (по полгода), а побочным эффектом были заметные различия внешнего вида и функционала одной и той же фичи на разных платформах.
Потом нас разбили по маленьким кросс-функциональным командам. Разработка пошла быстрее, костылей и платформенных различий на клиентах становилось всё больше.
