🕵️ Как создать продукт, до которого не доберутся кибермошенники

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

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

Об этом мы и поговорим с коллегами на четвертой встрече клуба «Ecom и Вино». Она пройдет 6 сентября в офисе AGIMA. Мы позвали Ecom-экспертов и специалистов по кибербезопасности из Ростелеком, Flowwow, Ozon, F.A.C.C.T, и AGIMA.

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

В программе — дискуссия с экспертами в формате круглого стола, бизнес-игра, много живого общения, хорошие напитки и вкусная еда.

Встреча вновь будет закрытой — только для Ecom-директоров и CMO.

Зарегистрироваться и узнать детали можно на странице события.

Как сделать так, чтобы тебя читали: 3 простых правила при создании текста

По данным NN/g, люди не вчитываются в каждое слово на странице с текстом, а воспринимают только 20% контента. Они сканируют и вычленяют отдельные слова и фрагменты.

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

1. Создавайте сканируемый контент.

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

2. Помогайте людям сканировать ваш контент.

Расставьте по тексту крючки, за которые зацепится глаз читателя.

3. Сделайте так, чтобы человек перешел к чтению после сканирования.

Если человек сканирует интересный и полезный текст, он начнет его читать подробнее. А это и есть ваша цель — донести сообщение до клиента.

>> Больше интересных примеров и кейсов из мира диджитал найдете в Telegram-канале нашей дизайн-команды.

4 принципа из художки, которые помогают в работе дизайнера

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

1. Сперва общая композиция, потом — детали.

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

2. Результат зависит от контекста.

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

3. Критика — не руководство к действию.

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

4. Сложные вещи лучше упрощать.

Любой предмет — это набор геометрических фигур. Упростить объект до базовых форм и сохранить его характерные черты — задача не из легких. Но это полезно не только для иконок и логотипов, но и для поиска концептуальной визуализации в целом. Всё, что не требует много размышлений, запоминается лучше.

>> Полная версия статьи Юли — по этой ссылке.

Как JIT в PHP 8 ускоряет парсинг CSV-файлов

С выходом PHP 8 появилась одна из самых мощных функций — JIT-компиляция. Она ускоряет выполнение PHP-скриптов, и это особенно полезно при парсинге больших CSV-файлов.

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

Как это помогает при обработке файла:

1. Ускорение циклов: Цикл обрабатывает строки файла быстрее благодаря компиляции его тела в машинный код.

2. Оптимизация работы со строками: Функции типа fgetcsv становятся эффективнее, что особенно важно при сложной обработке данных.

3. Снижение накладных расходов: JIT минимизирует затраты на вызов функций, делая их выполнение более быстрым.

Можно провести эксперимент: подготовить CSV-файл с 10 миллионами строк и запустить PHP-скрипт — с включенным JIT и без него. Получится, что включение JIT позволит сократить время на парсинг файла примерно на 33%.

Больше деталей и пример скрипта найдете в Телеграм-канале Саши Шутая, нашего руководителя отдела PHP.

Плюсы шаблона Saga для микросервисной архитектуры

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

Например, вы разработали систему для покупки билета на самолет. В нем три сервиса: оплата, уведомление, бронирование. Сервис успешно списал деньги, выслал уведомление о покупке, но возникла ошибка на этапе бронирования. Как откатить изменения, когда у нас три независимых сервиса? В монолитном приложении нас бы спасли транзакции ACID. А в случае с микросервисами — Saga. 

Принципы работы Saga:

1. Разбиение на шаги: Saga состоит из шагов (транзакций) в каждом микросервисе, таких как списание средств и бронирование.

2. Компенсирующие транзакции: если один шаг не удался, запускаются компенсирующие действия для отмены изменений предыдущих шагов.

3. Асинхронное выполнение: шаги могут выполняться асинхронно, а при ошибке запускаются компенсирующие транзакции.

Стратегии реализации:

• Оркестрация: один сервис или оркестратор управляет всем Saga, что упрощает реализацию, но создает единую точку отказа.

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

Читайте больше про веб-разработку в канале нашего руководителя отдела PHP Саши Шутая.

🛠️ Главные инструменты Rive

Для работы с Rive Animation лучше использовать их UI-интерфейс, в котором и происходит создание и настройка самой анимации. Анимация состоит из нескольких составляющих. Они больше знакомы дизайнерам, но, если кратко, вот некоторые из них.

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

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

3. Shape: Rive позволяет создавать, редактировать и анимировать векторную графику, используя процедурные или пользовательские фигуры. Из них чаще всего и состоит весь интерфейс.

4. Pen: это инструмент, который позволяет делать очень сложные кастомные фигуры.

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

Про количественные и качественные показатели сотрудников

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

• легко контролировать эффективность каждого сотрудника и принимать кадровые решения на основе данных;

• каждый сотрудник, зная свои целевые KPI, стремится к хорошему финансовому результату;

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

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

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

2. Слаженная команда показывает хорошие Throughput и Lead time. Через полгода выясняется, что они хакнули систему и накрутили красивые метрики, не поставляя бизнес-ценности.

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

Больше об управлении IT-командами рассказываем здесь.

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

Каждый год мы с компанией ездим за город на AGIMA Camp. Это летний корпоратив, где мы общаемся с коллегами, строим планы и просто отдыхаем. В этот раз главной темой поездки был американский фестиваль Burning Man. Его участники возводят в пустыне всякие безумные скульптуры и сооружения. Вот и мы решили провести что-то наподобие — конкурс инженерной мысли.

Как раз для конкурса одна из команд собрала своими руками настоящий винный фонтан.

Вот как они это сделали:

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

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

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

В салатнике просверлили отверстие под диаметр слива. Слив выбрали самый обычный, который используют в большинстве раковин. Трубка от слива вела обратно в резервуар с вином.

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

Подробная смета, видео и фотографии механизма — в нашем блоге.

Lottie vs. Rive

Это два популярных инструмента для создания анимаций в приложениях на Flutter. Сравнили их плюсы и минусы.

Lottie

Плюсы:

• Простота использования: благодаря поддержке JSON, Lottie доступен для разработчиков любого уровня.

• Кроссплатформенность: позволяет использовать одни и те же анимации на разных платформах.

• Широкое комьюнити: в сети есть большое количество готовых анимаций.

• Гибкость: Lottie позволяет настраивать анимацию и эффекты, что дает больше контроля над результатом.

Минусы:

• Ограничения по сложности: Lottie не подходит для очень сложных анимаций с большим количеством элементов и эффектов.

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

Rive

Плюсы:

• Интерактивность: Rive поддерживает интерактивные анимации, которые реагируют на пользовательские действия.

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

• Производительность: с Rive получается быстрая и плавная анимация благодаря формату файлов.

Минусы:

• Сложность использования: у Rive более сложный интерфейс, чем у Lottie, новичкам с ним работать трудно.

• Размер файлов: Rive-анимации могут быть тяжелыми, и это влияет на вес всего приложения.

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

Подробнее про Rive писали в большой статье и в тг-канале о мобильной разработке и ИТ.

Как мы измеряем узнаваемость HR-бренда компании

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

Чтобы результаты были релевантными, добавили в начале вопрос «Работаете ли вы в IT?». Это было нужно, чтобы отсеять ответы, которые нам менее интересны. В итоге на сегодняшний день в опросе приняло участие уже около 1500 человек. Почти все вопросы так или иначе связаны с брендом компании. Но в первую очередь мы спрашиваем, что в целом, кроме зарплаты, мотивирует соискателя принять оффер.

Цели такого опроса:

• понять, что на рынке думают и что знают о нашей компании;

• уточнить, какие каналы привлечения кандидатов работают, а какие нет;

• выяснить, где в HR-бренде слабые места и над чем нужно поработать.

Также благодаря опросу мы имеем доступ к другим, не менее интересным данным. Например, знаем, спецы какого возраста и стека чаще слышат про AGIMA. И в этом случаем мы тоже улавливаем связь с нашими PR-активностями. Скажем, провели митап для дизайнеров — выросло количество дизайнеров, которые про нас знают. 

Больше подробностей про исследование HR-бренда в нашей статье.

4 совета про стажировки от Junior-разработчика

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

1. Не HH.ru единым

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

2. Изучайте инфу о компании

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

3. Учите Git

Многие новички пропускают этот пункт и думают, что Git — это несложно. Но даже изучения основных команд Git недостаточно. Советую сделать пет-проект в команде с такими же новичками — потренируете командную работу и важные навыки в Git: правильное название коммитов (commitlint), разработку отдельных задач в отдельных ветках и т. д.

4. Тренируйте навык тайм-менеджмента и умение отдыхать

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

Это часть большой статьи, где разрабы и их менторы дают советы, как выжить на стажировке в IT — enjoy!

Волшебник Изумрудного города, или Как тестировать MVP сложного продукта

Расскажем об интересном методе тестирования продуктов. Он называется — «Волшебник страны Оз».

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

Например, компания разрабатывает голосовое управление для онлайн-кинотеатра, но в приложении такого функционала пока нет. Приглашают пользователя для теста. Он говорит: «Хочу посмотреть сериал "Друзья"».

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

Обычно этот метод используют для продуктов, в которых сложный функционал. Интегрировать такой в MVP дорого и накладно. Это может быть то же самое голосовое управление, AI-поиск, VR/AR.

Метод также может быть открытым, закрытым и смешанным.

✓ Открытый — когда у исследователя нет готовых реакций/ответов.

✓ Закрытый — когда они уже четко проработаны.

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

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

Больше о тестировании MVP и UX-исследованиях читайте в нашем Телеграмм-канале.

Новые условия IT-ипотеки

Правительство России продлило программу льготной IT-ипотеки до 2030 года, но исключило из нее Москву и Санкт-Петербург. Ранее сотрудники аккредитованных IT-компаний могли без проблем купить себе квартиру по льготной ставке, причем где угодно — география не влияла на применение льготы. Теперь же расположение компании и самой квартиры имеют значение.

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

Также, согласно новым условиям, процентная ставка выросла до 6%, а размер льготного кредита уменьшился до 9 млн рублей. Кроме того, раньше после оформления ипотеки человек должен был отработать в IT не менее 5 лет. Теперь же менять сферу нельзя, пока ипотека не будет погашена.

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

Как вы оцениваете новые условия IT-ипотеки?

Сперва определяем ценность для пользователя, потом придумываем решения

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

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

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

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

Проверочный вопрос для вашего решения: «Какими еще способами можно дать эту ценность пользователю?» Если решение проработано хорошо, вы сможете дать список подобных и объяснить, почему вы их отвергли в пользу вашего варианта. 

P. S. Это часть статьи о ловушке форм-фактора, читайте ее полную версию тут.

Два основных подхода к разработке UI-китов

1. All-in подход. Подключение компонента вместе со стилями или без них. Здесь любой компонент — это самостоятельная единица, которая уже содержит всё нужное. Внутри этого подхода можно выделить два подвида:

• Инлайн-стили через Styled Components (возможно, добавить просто подключение стилей внутри компонента). Этот метод позволяет писать стили непосредственно в компоненте. При этом стили изолированы, что уменьшает возможность конфликтов между стилями разных компонентов.

• Без добавления стилей (Headless). В этом случае компоненты предоставляют только логику без UI, что позволяет самостоятельно управлять стилями. Для создания подобной библиотеки нужно также ознакомиться с паттерном Compound component.

2. Dependency CSS & Bundle CSS подход. Второй большой подход — когда стили и компонент подключаются по отдельности. В этом случае стили и логика компонента отделены друг от друга.

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

• Bundle CSS предполагает подключение всех стилей сразу и отдельно — компонента. По сути, в этом случае все стили объединены в общий бандл и импортируются в корне проекта. 

Но при написании они схожи, и стили к компоненту подключаются как модули.

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

Про скоринг кандидатов

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

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

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

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

Немного цифр:

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

Больше об управлении IT-командами рассказываем здесь.

Кластеризация с использованием Etcd

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

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

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

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

Что касается кластера Etcd, разделенного между Data-центрами, то, если мы будем использовать два Data-центра, система не будет High Availability. В таком случае лучше использовать третий Data-центр, так называемую кворумную площадку. Это может быть любая виртуальная машина в третьем месте, вплоть до ноутбука системного администратора.

Об опыте работы с Etcd рассказываем в большой статье. Делитесь мнением в комментариях.

Зачем мы вкладываем столько времени и сил в стажеров

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

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

• стажеры потенциально закрывают кадровые вопросы, которые по-прежнему на рынке стоят остро;

• стажеры куда более лояльны к компании — у нас, например, они работают не менее 2–3 лет;

• стажеры освобождают время мидлов и сеньоров для более сложных творческих задач;

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

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

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

Интересные кейсы использования Data Science

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

1. Сбербанк использует Data Science для анализа огромных объемов данных о клиентах.
   
   + Помогает предлагать более персонализированные продукты и услуги, а также эффективно бороться с мошенниками.

2. Благодаря анализу данных, Яндекс.Такси может прогнозировать спрос на такси в разных районах города и даже в разное время суток.
   
   + Помогает оптимизировать распределение машин и сокращать время ожидания для пассажиров.

3. Магнит — один из крупнейших ритейлеров в России — использует Data Science для управления запасами и прогнозирования спроса на товары.
   
   + Позволяет избегать дефицита и излишков на полках магазинов, а значит, экономить деньги и повышать удовлетворенность клиентов.

Больше подобных кейсов мы подробно разобрали на подкасте One Two Prod с Олегом Рудаковым, Data Science Head of Analytics крупной FMCG-компании. Ну а еще спросили у Олега о разнице работы в агентстве и продукте, о трендах в аналитике, кому вообще нужен Data Science и где больше платят.

One Two Prod — это совместный подкаст AGIMA и ONY, где мы говорим о развитии диджитал-продуктов. Первый выпуск уже доступен на YouTube и Яндекс Музыке, а второй выйдет на следующей неделе — не пропустите. В нем мы обсудим стратегии и метрики продуктов вместе с Павлом Аксеновым, ex CPO «Самолет Плюс».

Какие качественные и количественные исследования стоит проводить в рамках Discovery-процесса?

Качественные:

1. Глубинные интервью
   
   Помогают получить искреннее мнение вместо социально одобряемых ответов, в отличие от фокус-групп. К глубинным интервью еще относят и другие форматы, например, CustDev, которые выявляют проблемы и потребности пользователей.

2. CJM

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

3. Юзабилити-тестирование

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

Количественные:

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

2. A/B-тесты
   
   Делим респондентов на 2 группы: тех, кто видит старый интерфейс, и тех, кто видит новый или экспериментальный. Иногда показываем два варианта дизайна для выбора лучшего. После сбора достаточного количества данных завершаем тест и подводим итоги.

Подробнее о Discovery пишем тут.