Это вторая часть статьи про нашу дизайн-систему. Первая часть выходила раньше.
В этот раз речь пойдёт о философии нашей работы, взаимодействии с дизайнерами и клиентскими разработчиками; о трудностях, с которыми сталкиваемся, и как их преодолеваем; о том, как мы развиваем нашу ДС.
Дизайн-система в нашей компании существует с 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, веб. При этом фичи пилились достаточно долго (по полгода), а побочным эффектом были заметные различия внешнего вида и функционала одной и той же фичи на разных платформах.
Потом нас разбили по маленьким кросс-функциональным командам. Разработка пошла быстрее, костылей и платформенных различий на клиентах становилось всё больше.
