Эссе о прохождении курса "Школа менеджеров Яндекса"

Эссе является результатом просмотра курса «Школа менеджеров Яндекса».

1. Как создавать полезные продукты.

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

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

Важные метрики для оценки успешности продукта.

Жизненный цикл продукта — разработка, запуск, оптимизация, точка зрелости, эволюция.

3 группы инструментов для тестирования продуктов: предварительный анализ (оценка по метрикам), качественное исследование (интервью с пользователями), количественные тестирования (А/В тесты).

2. О продуктовом мышлении. Спикер Юрий Подорожный. (отвечает за развитие Яндекс такси).

Анализируя ситуацию с рейтингом S&P за последние 10 лет, миром правит программное обеспечение — в топ 5 находятся IT компании.

Важность отказа и сказать «нет» в решении о развитии продукта.

Вопросы полезно задавать при решении о развитии продукта.

1. Насколько это соотносится с вашим видением продукта?
2. Будет ли это иметь смысл через 5 лет?
3. Что произойдет, если этого не делать?
4. Увеличит ли это прибыль?
5. Сколько будет стоить поддержка внедрения?

Идеальная воронка в продукте: осознание потребности, приобретение, активация, конверсия в целевое действие, возвращение.

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

Чтобы понять и избежать проблем, полезно ответить на вопросы:

1. Что если юзер не читал инструкцию?
2. Что если пропало соединение?
3. Что если пользователь прервался во время выполнения действия?
4. Что если не подтвержден почтовый адрес?
5. Что если в каком-то конкретном месте все пойдет не по плану?
6. Что если измениться место или контекст?

Распространенные сценарии при возникновении ошибок (на стыке взаимодействия дизайнера-разработчика-менеджера):

• пустые экраны;
• отсутствие результатов в поиске;
• отображение ошибок (валидация, получение, отправка);
• потеря интернет-соединения;
• местоположение (геолокация);
• контекст пользователя;
• локализация.

Задавая вопрос «Почему?» 5 раз, вы определяете характер проблемы, решение становится понятным. С. Тоёда.

3. Behavioral engineering. Дмитрий Мацкевич.

Лекция посвящается принципам работы мозга, восприятию информации человеком и психологии принятия решений.

80% контента человек забывает в течение часа. Основная задача - показать что в направлении есть интересные модели и удовольствие от решения проблем.

Существуют фильтры восприятия реальности, так как невозможно сфокусироваться на всем происходящем вокруг. Например, есть желание купить автомобиль «Тойота королла», мозг на этом фокусирует и начинает замечать вокруг авто данной модели.

Фундаментальные принципы восприятия:

1. Мозг эволюционно привык «лениться» чтобы экономить энергию.
2. Нет единого центра принятия решений в мозге. (Reptilian brain (наследие динозавров = инстинктивное), Limbic brain (эмоции), Neocortex(рациональное мышление).
3. Мозг пластичен, всегда принимает решение в контексте.
4. Эмоции были запрограммированы в мозгу химическими в процессе эволюции.
5. Большую часть времени человек находится в режиме Zombie mode = автоматизм.

4. Дизайн для менеджеров. Константин Горский. (руководитель службы дизайна веб-интерфейсов).

Лекция состоит из 7 историй про дизайн.

Есть ли у дизайна процесс?

Шаги: исследование — интерпретация (анализ, выводы, постановка задачи) — формирование идеи (мозговые штурмы, креативные техники) — эксперимент (макеты, прототипы, юз. тесты) — эволюция (разработка, запуск, изучение, совершенствование).

Когда заканчивается дизайн?

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

Место дизайна в разработке продукта не только на этапе эскиза/макета, чем раньше его подключить (на этапе создания ТЗ), тем лучше из-за большего понимания и вовлеченности.

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

Страх, содержание и форма.

Как форма влияет на содеражание? Рассматривается на примере слова «страх» или же FEAR на англ.

Меняя формы мы меняем восприятие того или иного объекта, в данном случае шрифта.

Красиво ли это?

По-большому счету все сводится ко вкусу человека.

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

Как ставить задачу дизайнеру?

Важные вопросы для постановки:

• Для чего этот проект?
• Как понять, что цель достигнута?
• Что именно предстоит сделать?
• Зачем это делать?
• Делал ли кто-то так до вас?
• Можно ли решить проблему проще?
• Не сломал ли текущее поведение пользователя?
• Как люди узнают о нововведении?

Что делать с дедлайном?

Чем больше времени, тем качественнее результат.

Открытость.

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

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

5. Продуктовые исследования. Иван Замесин.

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

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

Основное применение CustDev — валидация продуктовых идей.

CustDev делается постоянно, на протяжении всего жизненного цикла продукта.

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

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

6. Agile инструкция по использованию. Анна Мининкова.

Подходы к разработке:

Последовательный (waterfall).

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

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

Гибкий подход - agile.

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

Как выглядит процесс: короткие итерации, быстрая ос, противное планирование, фокус на продукте.

Манифест Agile

• Люди и взаимодействие важнее процессов и инструментов.
• Работающий продукт важнее документации.
• Сотрудничество с заказчиком важнее согласования условий контракта.
• Готовность к изменениям важнее следования первоначальному плану.

7. Про внедрение продуктов. Харитон Матвеев. (Сооснователь Skyeng).

Основная проблема — когда готовый продукт не приносит пользу/прибыль в должном объеме.

Цель нового продукта, глобально — сделать жизнь лучше.

Стадии в продукте.

• Продуктовый маркетинг.
• Производство продукта.
• Доставка продукта.
• Внедрение продукта.

Рассматриваем все стадии на разных примерах. (Изготовление пиццы, бургерная, тренажерный зал, стоматология и пр.)

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

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

Для хорошего внедрения нужно:

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

Невнедренные продукты — точка роста.

8. Как данные помогают строить продукты. Олег Якубенков. (ZeptoLabFacebook).

MVP — как понять что это действительно нужный продукт? Рассматривается на примере опыта спикера в игровой разработке.

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

Следующий шаг — привлечение пользователей за счет рекламы. Далее тестирование жизнеспособного продукта на небольшой группе пользователей, после успехов на маленьком рынке (Канада, Австралия) можно запускаться глобально.

В середине выступления спикер отвечает на вопросы слушателей.

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

Retention — показатель удержания текущих клиентов.

Product market fit — продукт для определенной группы людей, критерии - высокий ретеншен.

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

Важно нарабатывать экспертизу в выбранной отрасли.

9. Аналитика. Владислав Исмагилов. (Яндекс Маркет)

Кто такие аналитики и как с ними работать — главный вопрос лекции.

В разных компаниях и разных командах под аналитикой понимают разное (разработку статистики, интерфейс к данным).

1. Что такое аналитика? С др. греческого — искусство анализа. Суть аналитики - помощь в принятии решений на основе данных. Задача менеджера — управлять рисками, задача аналитика — в кратчайшие сроки находить те самые 70% желаемой информации.
2. Какая бывает аналитика? Бизнес-аналитика (контроль основных метрик компании и предложение возможных вариантов, если что-то идет не так), технологическая (тюнинг готовых решений, создание чего-либо на основе машинного обучения, академически сложны задачи), продуктовая (ответы на заданные и негаданные вопросы, теории и решение проблем). Требования к аналитикам: понимание сути и цели процессов, способность в сжатые сроки погрузиться в новую тематику, знание математики и статистики, навык работы с данными любого объема, умение говорить на понятном языке, умение программировать. Инструменты — SQL, Python, Exel. Важная методология — маркетинговые исследования и UX.
3. Кто такие аналитики? Люди, которые хорошо понимают, как устроена отрасль в которой он работает; разделяют субъективное и объективное; умеют распутывать причинно-следственные связи; разбираются в статистике; умеют работать с любыми объемами данными; обладают навыком программирования. Рассматривается пример по добавлению видеобзоров на Я-маркет. Этапность: проверка жизнеспособности идеи — MVP (чтобы подтвердить минимальным количеством ресурсов пользу) — полноценный запуск — поддержка (точечные улучшения).
4. Чем аналитики могут помочь проекту? На раннем этапе отсечь не значимые идеи; исследовать конкурентов и существующие решени; помочь сформулировать МВП и определить вилку решений полноценного запуска; определить KPI; обеспечить инструментами контролирующими процесс запуска; дать идеи для улучшений.

Формула хорошей задачи: понятная цель * описана проблема * понятен сценарий использования * (1 + предложенное решение).

10. Принятие решений на основе данных. Елена Бубнова.

Метрика — число, сонаправленное с характеристикой продукта.

Рассмотрим на примере жизненного цикла поискового продукта «ранжирование с учетом региональности».

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

Популярность не равно доход. Нужно понимать что продукт требует ресурсов и должен приносить деньги или существовать на инвестиции.

Что именно считаем в продукте — долю рынка (% пользователей), монетизацию (каким образом зарабатывать на приложении), расходы (аренда, оборудование, персонал).

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

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

Приемка продукта — офлайн (без пользователей, сравниваем 2 системы с разницей в одном аспекте) и онлайн (показатели метрик).

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

Дашборды — сбор показателей для разных людей в компании (команда, менеджемент, руководство).

Сколько метрик нужно? Четкого ответа нет, всегда нужно отталкиваться от конкретного продукта.

11. Ошибки менеджера проектов. Екатерина Лебедева. (ведущий менеджер проектов Яндекса).

Проект — четкие временные рамки + этапность = результат.

Цель проектного менеджмента — реализовать проект в том объеме, который обозначался ранее (риски) с минимальными затратами ($6 люди, нервы) при максимальных показателях качества и удовлетворенности заказчика.

Жизненный цикл проекта.

1. plan-driven.
2. change-driven.

Возможные ошибки:

• Попытаться запихнуть все в один «резиновый» релиз.
• Эксплуатация продукта во враждебной среде.
• Не верная расстановка приоритетов.
• Не собрать всю информацию.
• Забыть ответить на вопрос «что будет, если этого не сделать?»
• Забыть про распределение ролей.
• Развесить ответственность обязательства на всех.
• Выстраивать процессы тогда, когда инструменты и методы разные.
• Сверхдетализация.
• Помнить про источники проблемы.
• Вернуться на шаг назад/к началу.
• Забыли про аудит — нужен процесс мониторинга и контроля.
• Не проводить ретро.
• Забыть про технический долг.
• Забыть про документацию.
• Грубо оценивать задачу.
• Закрытая задача не равно выполнена.
• Не верная расстановка целей и kpi.
• Уникальность против типичности - проверяйте.
• Плохо поставленная задача.

Требования к задаче (как и у цели, smart):

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

Важно всегда уточнять процедуру действий с исполнителем!

Рекомендации ПМ:

• Ставьте дедлайн самому себе.
• Не забывайте о глобальной цели проекта.
• Приоритеты должны согласоваться с командой.
• Идентифицируйте проблемы, предотвращайте и решайте.
• Не ставьте задачи формально, фиксируйте договоренности.
• Старые и проверенные методы и инструменты иногда (чаще?) работают лучше.
• Заказчик отвечает за качественную постановку цели, вы отвечаете за ее исполнение.
• Не используйте PM book как методологию.
• Не стоит улучшать процессы ради улучшений.
• Планируйте и минимизирайте зависимости.
• Работа со срочными задачами должна быть спланирована.
• Рутинные задачи нужно делать.
• Умейте отключать микроконтроль.
• Ограничения — классно.
• Если архитектура не гибкая — ее нужно менять.
• Чек-листы — круто.

12. Организация работы и среды. Александр Садовский.

Факторы рабочей эффективности:

• оценка способностей сотрудников;
• автоматизация;
• обучение;
• мотивация;
• борьба с потерями времени;
• рабочая среда.

Из чего состоит личная продуктивность.

• Зачем? Целеполагание.
• Что? Приоритеты.
• Когда и как? Физиология продуктивности.
• Как заставить себя? Психотерапия.
• Где? Эргономик рабочего пространства.

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

13. Ненасильственное управление. Григорий Бакунов. (ex-директор по распространению технологий Яндекса, ныне занимается криптовалютами).

Как управлять разработчиками (без применения насилия)?

Спикер приводит различные ситуации из собственной практики разной степени давности.

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

• Удивляй, если не можешь предсказывать, предсказывай, если можешь.
• Работай совместно — если работают ночью — работай ночью.
• Шок как средство для возвращения в сознание, дефибриллятор как метафора.
• Нет лишний информации, если она используется во благо — знай все о каждом.
• Никто не любит, когда им руководят. Управляй, не дергая за ниточки.
• Даже, если ты — генеральный, бывают обстоятельства, помни, у тебя тоже есть босс.

14. Как мы делали Яндекс.Транспорт. Лиза Семяновская.

Речь идет о том, как создавался Я. Транспорт (работает с 2014 г.)

Используется для прокладывания маршрута, отображать местоположение транспорта, местоположение каршеринга на карте + может разбудить на месте прибытия.

Я. Транспорт родился из желания вырастить аудиторию геосервисов.

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

Для пешеходов — Мобайл ферст. При создании Я. Транспорта отталкивались от этого в первую очередь.

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

Основные проблемы стартапа (на примере Я. Транспорта в большой компании): малое количество ресурсов, нехватка данных, проблемы с их обработкой.

Плюсы: отсутствие затрат на маркетинг (тк является частью большой компании), есть у кого спросить/посоветоваться внутри компании по вашим вопросам, не живешь на своем деньги, а на деньги компании. Минус: MVP не настоящий, уровень продукта должен быть высоким.

По состоянию на 2017 г. дается рекомендация в первую очередь выкатывать на Андроид (в настоящее время не актуально).

Если фичу на этапе MVP делать дорого и сложно — лучше ее не делать!

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

15. Администрирование и эксплуатация в Яндексе. Вячеслав Агапов. (системный администратор — Я. Музыка, Я. фотки).

Кто такой сис. админ в настоящее время?

Любознательный человек, экстраверт, трудоголик (вероятнее всего).

Эксплуатация отвечает за:

• работу ИТ сервисов;
• оптимальное использование ресурсов;
• мониторинг;
• поиск проблем и их устранение.

Что требуется от менеджеров?

• Информация о релизах (крупных);
• информация о новых запусках;
• присутствие на встречах.

Как планировать релиз?

Большой релиз в четверг плохо, любой релиз в пятницу плохо, что угодно в пятницу вечером — плохо)

Хорошо: предупреждать заранее, выкатывать на часть аудитории, включение по кнопке.

Что нужно для запуска?

Оценка размера аудитории и нагрузка (Н: трансляция концерта — аудитория сайта 50 тыс., ожидаемое количество участников — 2 тыс., максимально возможно — 2*50=100 тыс. запросов); SLA (Service Level Agreement соглашение о доступности сайта); возможность отката; готовность к отказу.

Хороша практика — релизы «маленькими кусочками» (Н: одну кнопку, изменение формата баннера, изменение логотип и пр.)

Важно проводить нагрузочное тестирование.

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

Что именно делают администраторы?

Поддерживают сервисы, DecOps (может писать код и сам занимается деплоем ), SRE (инженер доступности сервиса — пишет внутренний код).

Сервис с точки зрения админа.

Актуальность и безопасность ПО.

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

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

Дата-центры на примере Я.

Текущие количество (на 2017 г.) 6 штук. Используется более 100 000 серверов.

ДЦ имеет 2 канала по 500 Гб/с. Стандарт IРv6.

Используемый стек в Яндексе.

Фронтенд (node JS) — бекенд (C++, Java, Python ) — база (изменяемые данные) и хранилище (неизменяемые данные на физическом носителе).

16. Юнит-экономика или поиск точек кратного роста. Илья Красинский. (AppCraft).

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

Факторы оценки — количество скачивали и оценка в звездах.

Метрики.

ARPPU (Average revenue per paying user, средняя выручка на одного платящего пользователя) = выручка / число пользователей, совершивших оплату.

ARPU (Average revenue per user, средняя выручка на одного пользователя) = доход / число пользователей.

CPI (cost per installation) — цена одной инсталяции.

Сколько стоит придуманная идея?

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

Мерять пользователя по себе неправильно! На деле менеджер продукта далек от потребителя продукта.

Revenue (выручка) — по факту выглядит как ступенчатое движение вверх, а не как экспонента. Рост возможен за счет новых компетенции.

Эльяху Голдатрат — Теория ограничений. Все метрики построены по этой книге.

Лучше начинать не с идеи, а с диагностики.

Алгоритм поиск точек роста:

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

Алгоритм расчета unit экономики:

• посчитать доход с платящего в месяц (арппю);
• посчитать конверсию в первую покупку (с1);
• посчитать доход с привлеченного пользователя (арппю*с1);
• сравнить стоимость привлечения пользователя с Cost pr Acquisition с ARPU.

17. Тестирование в Яндексе. Алексей Наседин. (Я. браузер).

Почему появляются баги?

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

Вопросы к команде при появлении бага:

• есть ли код ревью?
• был ли таск на изменение?
• был ли кейс на проверку поведения?
• почему не прошли кейс в регрессии?

Какое бывает тестирование? (Процедура сравнения результата фактического и ожидаемого).

• юнит тесты (проверка ПО «по модульно»);
• интеграционное тестирование (взаимодействие между модулями);
• системное тестирование (находит баги после проверки на предыдущих уровнях).

Что именно тестируем?

• функциональное тестирование (кнопки, формы и вот это вот все);
• нагрузочное тестирование (на количество запросов на сервер);
• стресс тестирование (проверяет корректность «падения» сервиса/приложения);
• тестирование производительности (скорость загрузки страниц);
• конфигурационное тестирование (на разных устройствах/браузерах);
• юзабилити тестирование;
• тестирование стабильности;
• smoke (на проверку минимальной функциональности);
• приемочное тестирование (после очередной фичи);
• регрессионное тестирование (корректность взаимодействия новой фичи с предыдущей).

По подходу тестирование делится на:

• ручное (человека сажаем на проверку);
• автоматизированное (пишем тесты);
• исследовательское (завязано на экспертизу ручного тестировщика, глобально не заменяет ни авто ни ручное).

Как сделать продукт качественнее?

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

В тестировании задействованы менеджеры, тестировщики и разработчики.

18. На что способен искусственный интеллект. Виктор Ламбурт. (Дзен, ранее рекомендации для маркета и музыки).

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

Слабый ИИ специализируется на одном классе задач. Сильный ИИ способен выполнять практически любые задачи.

Какие задачи умеет решать ИИ?

• Персональные рекомендации.
• Голосовые ассистенты.
• Распознание образов.
• Предсказание погоды.
• Нейро-поэзия.
• Сочинение музыки.
• Играет в игры.

Supervised learning — используется в поиске. Работает на основе формулы определения релевантности. (Примерный размер на 2012 г. — 40 Мб).

Основная идея Supervised learning — дать на вход алгоритма размеченный набор данных, чтобы он научился, какие факторы принимать во внимание и как именно это делать.

Применение — известные факторы — формула MatrixNet — предсказание неизвестного ответа.

Сверточные нейтронные сети.

Олимпиада по распознанию образов — imagent large scale visual recognition challenge. Проводится ежегодно с 2010, 20 тыс категорий, используют 14 млн изображений детально размеченных. Резкое улучшение результатов произошло после начала использования deep learning.

Основная идея сверточной сети — приложение разных шаблонов к изображению попиксельно. (Н: часть изображения 16*16 пкс накладывается на оригинал 240*240 пкс). По результатам выдается анализ по количеству тех или иных элементов на изображении.

Netflix Prize — 2006-2009 гг. Приз 1 000 000 $. Задача — улучшить предсказание оценки пользователя на 10%. На основе 100 млн оценок.

Победитель — Belkor’s Pragmatic Chaos.

Для решения этой задачи сейчас используется следующий алгоритм:

Идея алгоритма — так разложить в произведении матриц P и Q, чтобы в тех местах, где матрица R заполнена было максимально похожее на заполненные ячейки число.

Основная идея Unsupervised learning — создать модель, которая хорошо описывает все наблюдаемые данные и на основе которой можно делать полезные выводы.

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

Reinforcement learning — обучение с подкреплением. Идея — оптимально сочетать использование известной информации с получением новых данных.

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

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

Все перечисленные концепции используются в Яндекс.Дзен.

19. Управление творческим процессом. Дмитрий Быков. (Руководитель службы дизайна Я. Маркета).

Кто участвует в процессе?

• Дизайнер — находит решение проблем в рамках заданных ограничений.
• Продуктовый менеджер — аналитика, исследование, приоритезация задач.
• Тим лид/Тех лид — все технические моменты работы сервиса/продукта.
• Маркетолог.
• Аналитик.
• Проджект менеджер.

Классификация дизайнеров.

• UI (user interface) — выстраивает систему взаимодействия с пользователем.
• UX (user experience) — решает задачи организации логики продукта, описание сценариев взаимодействия.
• Motion designer — вопросы перехода одного состояния в другое, анимация, связь с материальным миром.
• Visual designer — графика в первую очередь, дизайн отдельных элементов.
• Product designer — собирает в себе все вышеперечисленные специализации.

Проектирование решения.

Процесс в продукте выглядит так: задача (правильная постановка почти сделанная задача) — концепт (требуется предварительная аналитика — различные исследования) — прототип (нужно пройти весь user flow, не вдаваясь в детали) — тест (убрать субъективизм на этом этапе) — решение (выделение mvp, проверка на соответствие гайдлайнам, финализации макетов, передача в верстку/разработку) + доп этап — проверка решения.

Хорошая практика — текстовое описание решения, помогает сэкономить время верстке/разработке.

Как критиковать работу дизайнера?

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

• AI (информационная архитектура — то, как устроена информация).
• Content (наполнение — нужно обращать внимание на заголовки, качество изображений, названия объектов, call-to-action).
• Visual style (стиль — состоит из цвета, шрифтов, композиции и графических конструкций).

Лайфхаки.

• Решение проблемы можно найти только при ее понимании и осознании.
• Критикуешь — предлагай.
• Дайте возможность ошибиться/ принять решение в мелочах.

20. Проектирование и прототипирование. Олег Левчук. (Менеджер продукта в Яндекс Картах).

Этапы создания прототипа: идея — предмет — кликабельные макет — живые данные — эксперимент.

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

Важно воплощать идеи в какую-либо форму.

Прототип приложения рекомендации одежды при нахождении человека у магазина одежды:

• каркас приложения;
• экран про бренды;
• фоновый трекинг;
• логика для пушей;
• пуш со скидкой.

Предварительная работа:

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

Важно не доверять статическим макетам, а проверять на кликабельном прототипе. (Пример на логике добавления нового объекта в картах).

Инструменты для прототипирования.

• Смекалка (при наличии только идеи).
• Keynote, Principe, Invision (для кликабельного макета).
• Framer, Browser (для работы с живыми данными).

21. Бренд и коммуникации. Дмитрий Степанов. (Директор по маркетингу в Яндексе на 2017 г.)

Коммуникация = аудитория + сообщение + канал (кому, что и где мы говорим).

Приводится пример стратегии на примере Я. Такси на 2014 г.

Действия — уточнить аудиторию (пользователи классического такси) и выяснить кто конкуренты? (в первую очередь не онлайн, а оффлайн сервисы).

Универсальное правило маркетинга — don't sell what you can build, build what you can sell.

Главный вопрос маркетинговых коммуникаций «Зачем?» — то, какой результат ожидаем и каковы параметры успеха?

Воронка в продукте.

Прямое стимулирование использования.

• Метрики — продажи, ROI, когорты, CAC
• Инструменты анализа — Я. Метрика, BI, Google Analitics.
• Аудитория — люди с конкретной задачей в момент потребности в ее решении.
• Сообщения — компактные, простые преимущества. (Н: цена).
• Каналы — приоритетное представление в местах продаж, сам продукт.

Формирование потребности в продукте.

• Метрики — спонтанное знание, первое упоминание (лидер в категории), атрибуты — вторые продажи, ROI.
• Инструменты — количественные исследования, качественные исследования.
• Каналы — долгий и частотный канал — ТВ, наружка, радио, продукт, соц сети.

Как выбрать сообщение?

• Исследования — качественные и количественные (фокус-группы).
• Инструменты — имитация landing page, TNS.
• Тестирование — качественные и количетвенные.

Как сделать коммуникацию эффективной?

• RTB (reason to believe ) — то, почему в вас верят. Н: безопасность Я. Браузера из рекламы, в частности уникальная технология защиты.
• Эмоции — человек запоминает что-то лучше в момент, когда испытывает эмоции.
• Исследования — очень важный момент, на всех стадиях создания рекламы.
• Тестирование — максимально на всех этапах.

22. Перфоманс и дистрибуция. Варвара Семенихина. (Маркетолог в Я. Музыке)

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

Целевое действие — ваша продуктовая воронка и вам важно ее знать.

• CPM — оплата за тысячу показов.
• CPI — стоимость привлечения одной установки.
• CPA — стоимость целевого действия.
• CPC — стоимость за клик.

Каналы продвижения. Бесплатные.

Фичеринг.

В разных сторах выглядит по разному. Проверка от самого Элла или Гугла на требования компании к выпускаемым продуктам.

AppStore VS GooglePlay

Что влияет на Store Optimization?

AS — слова в названии, ключевые слова, сториз. GP — частота упоминания слов в названии и описании.

Что влияет на рейтинг приложения?

AS — частота установок за последний час. GP — установки, скорость ответа на отзывы, как часто открывают и пр.

Оплата.

AS — только с привязанной карты (уже не так в настоящее время). GP — возможно и с сотового телефона.

Открытость компании.

AS — очень избирательна в общении с разработчиками, но сама замечает ярких представителей. GP — легко попасть в офис и получить личную консультацию.

PR.

Нужно искать тех, кто пишет для вашей аудитории.

Партнерства.

Старайтесь приводить сразу платежеспособную аудиторию. Win-win истории — партнерство должно быть выгодно обеим сторонам. Ищите интересные проекты с аналогичным размером аудитории или больше. Давайте то, что будет стоить минимум, но создавать ценность аудитории.

Реферальная программа.

Заставьте пользователя работать на вас.

Каналы продвижения. Платные.

Мотивированный трафик.

Не покупайте его никогда. Не нудно применять для андроида — это не поможет расти в ТОП. МТ конечен на определенной территории (оплата за установку). Не нужно пытаться превратить в лояльных пользователей.

Органический трафик.

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

Трафик рекламных сетей.

В России мало (на 2017 г.). Важно проверять его качество. Требует много ресурсов на подготовку креативов.

Трафик социальных сетей.

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

При разработке креативов важно:

• думать о ЦА;
• следить за трендами;
• смотреть на других;
• всегда добавлять немного вызова.

Таргетинги:

• пол/возраст/страна;
• платформа;
• интересы;
• сегменты/группы.

Стратегия закупки.

X = B/(lo+ln)

• B — бюджет.
• Lo — число органических установок.
• Ln — число неорганических установок.

Когда стоит остановиться?

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

23. Исследования в жизни продукта. Ольга Ржанова и Маргарита Рябцева.

Инструменты и возможности.

Потребности — профиль ЦА; цели и задачи ЦА; Привлекательность нового продукта.

Опыт — привычные способы решения; проблемы при решении задач продукте/ у конкурентов.

Отношение — лояльность; имидж; успешность коммуникаций.

К кому обратиться?

Аналитика (анализ логов, эксперименты, метрика).

Маркетинговые исследования (фокус-группы, опросы, интервью, этнография) — количественные/качественные.

UX исследования (юзабилити тесты, интервью) — качественные.

Если в компании нет отделов — есть ресурсы, предоставляющие готовые исследования (РБК, TNS, NNG), агентства неполного цикла (Tiburon), агентства маркетинговых исследований (GFK), юзабилити-лаборатории (Фабрика Юзабилити, Usabiliti-lab).

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

Когда исследование не требуется: от его результатов не зависит решение; нет ресурсов; цена ошибки невелика.

Цикл: идея — макет (оценка макетов, ux-тесты, тест названия/логотипа) — прототип (выбор одного варианта, выявление проблем, поиск идей) — продакшн (оценка успешности запуска, оценка удовлетворенности, поиск новых идей, выявление проблем) — коммуникация (тест концепции, поиск новой аудитории, писк способов правление аудитории, оценка эффективности коммуникации).

Роли.

Заказчик — собирает и хранит знания, принимает решения.

Исследователь — знает методы, находит ответы на вопросы, находит нужных людей.

Этапность.

• Что исследуем? Нужно определить какой информации не хватает для исследования?
• Поиск старых отчетов. Спросить у коллег. Поискать отчеты на близкие темы.
• Поиск готовых данных — поискать информацию в открытых источниках.
• Постановка задачи: четко обозначить цели; определиться с инструментами; понять какие материалы нужны; согласовать бюджет.
• Составление схемы исследования: определить выборку респондентов; составить сценарий проведения.
• Сбор данных: смотреть и наблюдать; добавлять вопросы; делиться впечатлениями; меняться данными исследований.
• Работа с результатами: различный формат отчета (текст, презентация, таблица, дашборд).
• Что не нужно делать после получения результата — не спешить; прислушаться к результату; не быть предвзятым; не доверять слепо.
• Что нужно делать — собрать все результаты; принять основные выводы; приоритизировать проблемы; сгенерировать варианты решений; запланировать дальнейшие действия; назначить ответственных.

Выводы.

Проводить исследования важно! Специалистам нужно доверять. Для полноты картины нудно совмещать исследования. Используйте результаты исследований.

24. Тексты в мобильных приложениях. Алексей Каданер. (Руководитель отдела текстов в Яндексе).

Все тексте в Мобайл делятся на 2 большие группы — Тексты интерфейсов и Маркетинговые тексты.

Тексты интерфейсов.

Охват очень большой и значение велико.

Виды интерфейсных текстов:

• надписи на кнопках;
• названия пунктов меню;
• системные уведомления;
• инструкции и подсказки.

Интерфейс — диалог пользователя и продукта. Непонятный текст = плохой интерфейс.

Как сделать лучше?

Пример непонятных сообщений:

Требование к функциональности предполагает, что текст нужен тогда, когда он решает какую-либо задачу.

Переспрашивать пользователя стоит только о критических моментах. (Н: удалить все письма).

Все тексты интерфейсов должны быть самодостаточны = Комбинироваться в любых сочетаниях.

Тексты должны быть выдержанны в едином стиле. (Одно и тоже название для одного и того же действия/элемента в разных экранах приложения).

Текст интерфейса должен быть: понятным, необходимым, кратким, атомарным, единообразным.

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

Виды маркетинговых текстов:

• название и описание приложения;
• что нового (ченжлог/ релизноутс);
• велком-скрины (интерактивные баннеры);
• пуш уведомления.

Существует проблема при написании маркетинговых текстов — переоптимизация.

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

Требованиям к пушам — релевантность, своевременность, персонализация.

Важно помнить, что у текста есть читатель!

25. Школа менеджмента — Саппорт. Павел Бывших. (Яндекс такси).

Зачем нужна служба поддержки?

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

Важные нюансы саппорта.

• прогноз нагрузки (формула Эрланг (для колл-центра), Defect Rate);
• команда: штат, аутсорс, краудсорс (публичный форум с наградами и рейтингом, куда отправляют заявки от саппорта, Н: Opera);
• тикет система (Zendesk, Freshdesk, OTRS, Omnidesk);
• блогмониторинг (Youscan, IQBuzz, Wobot);
• хелпцентр и фидбек;
• интеграция и сервис.

Откуда получать фидбек: почта, телефон, отзывы о продукте, smm, сторы приложений, проактив.

Организация работы отдела.

• SLA;
• приоритезация и вес тикетов;
• режим PLAY;
• отчетность и мониторинг;
• боты в телеграмме.

Лайфхак — индивидуальный подход в зависимости от типов характера пользователя из поступившего обращения.

26. PR. Юлия Бабикова. (отвечает за PR в медиасервисах).

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

Важно формировать стратегию: что хотим донести и кому, чем помогаем бизнесу и как будем оценивать эффективность.

Какие задачи решает пиар.

• рассказывает о новом продукте;
• привлекает новых пользователей;
• привлечение новых клиентов и инвесторов;
• собрать отзывы;
• сформировать восприятие продукта и повысь его узнаваемость.

Как сложить историю?

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

Как завоевать внимание журналиста?

Нужен интересный повод для построения новости. Важно понимать до какой аудитории нужно «дотянуться».

Требуется оценивать верно важность новости и стараться не пропустить интересное.

Лайфхак — выбирать интересные локации для проведения пресс-конференций. (Если бюджет позволяет).

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

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

Можно использовать необычные форматы — Н: тест о музыкальных предпочтениях; Н: Контрольная по математике (ЧТД).

Молчание — тоже пример пиара. В некоторых моментах лучше молчать, чем говорить.

Бывают внезапные PR проекты: Н: Центробанк спел про инфляцию.

Как оценить результаты?

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

27. Про презентации. Мария Кутузова. (Арт-директор презентационных технологий).

Три важных компонента презентации: структура, рассказ, дизайн.

Жизненный цикл презентации: идея (цель и постановка задачи) — аудитория (кому рассказывать? формулировка) — концепт (план рассказа) — тест (предварительный рассказ до выступления) — сценарий (построение проведения презентации — 20/60/20) — раскадровка — форма.

Презентация для выступлений.

7 принципов дизайна слайдов.

1. Читабельность (краткие и емкие тезисы, один шрифт — одна презентация).
2. Белое пространство (отступы по краям).
3. Выравнивание (единая сетка).
4. Акцент (оставляйте только самое главное, Н: если диаграмма — цветной остается только важная).
5. Единство (один контент — одна структура).
6. Контраст (выделяйте ключевое за счет контраста).
7. Расположение (близкие объекты нужно располагать рядом).

Что используется для создания?

28. Архитектура современных веб-сервисов для менеджера. Алексей Шелковин. (Яндекс почта).

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

Пользователь — видит интерфейс и взаимодействует с ним при помощи контроллера. (Controller, View, Model). Н: сервис «Заметки».

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

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

Как обеспечить надежное хранение данных?

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

Как обеспечить работу сервиса во время аварий?

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

Современный сервис требует медиа файлов.

Размер занимаемого места при использовании медиа существенно увеличится и снизится скорость ответа от БД. Можно разделить хранение текста и медиа и связать их между собой. Это позволит разделить продуктовый сценарии на 2 и позволит оптимально хранить 2 типа данных.

Как оптимизировать потребление ресурсов?

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

Дальнейшее развитие подхода — микросервсиная архитектура, позволяет ускорить релизной цикл.

29. UX в мобильных приложениях. Иван Горшунов. (Lead ментор в акселераторе).

На 2018 год в сторах было около 5,5 млн приложений.

Плюсы приложений:

• удобство пользования;
• всегда доступны;
• интегрируются в ОС.

Со временем количество устанавливаемых приложений у пользователя снижается и повышается лояльность к уже установленным.

75% пользователей открывает установленное приложение только один раз.

Что такое UX?

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

Продукт должен: преследовать цели бизнеса, решать проблемы бизнеса, решать проблемы пользователя, создавать доп.ценность для пользователя (помимо решения боли).

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

Зачем использовать Human Interface Guideline (Apple) и Google Material?

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

Различия (схожесть) в первой версии.

Что важно для приложения:

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

Что важно учесть (рекомендации от разработчиков):

• только портретная ориентация;
• модальные диалоги загрузки;
• маленькие цели (размер кнопки не меньше 46/48);
• старые элементы и заимствование;
• целостность (комбинация гайдов и фантазия дизайнера);
• смесь вебвью и наливного приложения;
• отсутствие онбординга.

30. Продуктовая аналитика. Дмитрий Тимко. (руководитель продуктовой команды Яндекс браузера).

А/В тестирование.

1. Случайным образом набираем две равных по размеру группы пользователей.
2. Одной группе раздаем экспериментальное улучшение.
3. Смотрим в конце на выбранную метрику.

Важное правило при АВ тестировании — нет такого признака у пользователя из выборки А, по которому он не может попасть в выборку В и наоборот.

Правила подбора и оценки метрик.

1. Важно придумать одну метрику.
2. Проверить нельзя ли вырастить выбранную метрику, ухудшив продукт.
3. Определяем, что не хочется ухудшить, если метрика вырастет.

На примере Я. Браузера.

Нужно понять что нужно продукту — суммарно количество переходов на сайты, которые делают люди, приводящие на промо страницу.

Пуши.

1. Ретеншн.
2. Уточненный ретеншн.
3. Переходы на сайт.

Работа с фонами.

1. Заходы в галерею.
2. Установки фонов.
3. Ретеншн.

Добавляем новости.

1. Суммарные переходы на сайт.
2. Ретеншн.
3. Заходы на главную Я.

Офлайн копии страниц.

1. Переходы на сайт.
2. Ретеншн.
3. Переходы.

Светофор.

1. Количество ДТП.
2. Максимальное количество ожидающих свой свет людей.
3. Пропускная способность (машин).

31. Процесс разработки мобильного приложения. Амир Биктимиров.

Рассматривается процесс на примере Я. Музыки.

Проектная команда. Роли:

• разработка клиента;
• разработка бэкенда;
• тестирование;
• дизайн;
• менеджер проекта.

Планирование релиза.

Сроки: по готовности; к конкретной дате; по готовности, но не реже чем; с определенной частотой.

Что входит в релиз: фичи (приходит от продукта в виде описания и дизайна), баги и тех долг.

Планирование команды.

Еженедельное (двухнедельное) планирование спринта (если не выполнено более чем на 50% то это проблема, менее — нет).

Стендап ежедневные.

Используется agile доска (канбан).

Планирование дизайна — макет, который пришел не конечный. Важно — адаптация для платформы, разрешение экранов, ориентация экранов, спецификация.

Разработка.

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

Релиз.

Важно взаимодействие со смежными отделами — маркетинг.

Выкатка на % — «канареечное» тестирование — релиз для малого числа пользователей.

Важно следить за количеством крашей и ошибок.

Хотфикс — срочная починка = исправление явной проблемы. Правится только одна проблема.

32. Бренд-маркетинг — Дарья Золотухина. (руководитель маркетинга Я. Такси)

Бренд не только реклама, но и любой контакт человека с продуктом.

Бренд-маркетинг — управление сознанием. 2 составляющие — заметность и атрибуты.

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

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

Свойства и позиционирования бренда зависят от знания категорий и конкурентной среды.

Модель построения коммуникаций от Ютуба.

Подход HXC (high-expectation customer) — поиск потребителя, который получит максимальную пользу от использования продукта. (Н: не женщина 30 лет с высшим образованием, а более углубленная направленность).

Как измерять эффективность бренд-маркетинга?

2 метрики — Знание бренда, атрибуты.

Вклад атрибутов:

• конверсия в привлечение пользователей;
• ретеншн;
• эластичность цены.

Как изменился бренд-маркетиг:

• появилось множество сегментов и сообщений;
• персонализация;
• превращение бренда в медиа;
• увеличилось количество кампаний до 100-200 в год;
• использование agile.

33. Советы тем, кто работает с данными — Илья Кацев. (руководитель группы анализа данных).

Данные.

• Важно понимать, что данные всегда плохие. Причины: ошибки в легировании; роботы; новые/устаревшие типы данных.
• Все починить невозможно, так как новое появляется быстрее. Как сделать лучше? Писать хороший код.
• Нужно смотреть на абсолютные значения, доля чего-либо может ввести в заблуждение.
• Данных не бывает много — чем больше данных, тем меньше дисперсия.

Измерения.

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

Как проводить исследования.

• Почти все попытки неудачные — это нормально.
• Нужен baseline — конкретные значения, от чего отталкиваться.
• Нужен план Б — иметь запасной вариант и выбрать момент икс, когда переходим к этой версии.
• Нужно помнить про естественность происходящего — модель должна удовлетворять свойствам реального мира, но иногда выходить за эти пределы.
• Простые методы должны давать профит — важно понимать стоит ли в это вкладываться?
• Локально обычно все функции линейны.
• Всегда нужно проверять результат разными способами.

Продакшн.

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

34. Разработка лендингов и креативов — Андрей Сивков. (Креативный директор маркетинговых коммуникаций в Я.медиа сервисе)

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

Сценарий пользователя выглядит так — пришел — понял — нажал.

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

Для эффективности лендинг важны: правильное таргетирование и работающий креатив (проверяем на статистике).

Правило — лендинг должен быть посвящен чему-то одному. Может призывать купить — купить — подписаться — попробовать. Если больше — есть риск что пользователь запутается.

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

35. От бизнес стратегии к маркетинговой, коммуникационной и медийной — Ольга Циос. (директор по маркетингу в Я. деньги).

Стратегия — глобальные цели и путь их достижения.

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

Универсальный сценарий:

Рассматривается пример на примере Я. Деньги.

Использовалась концепция «Стендап», основаная на привлечении комиков к рекламной компании для продвижения сервиса Я. Деньги.

36. Служба поддержки — Дмитрий Субботин и Екатерина Павлинцева. (служба поддержки медиасерсвисов).

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

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

Поддержка как инструмент: знакомит с сервисом, собирает пожелания, закрывает собой «несовершенства» продукта.

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

Важно определить место службы поддержки в продукте — ретранслятор (обслуживающая функция) или голос продукта (формирует лояльность). Н: Рокетбанк обработал запрос не относящийся к сервису — помощь в поиске больницы.

Кто такой саппорт?

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

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

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

Классификация обращений позволяет выстроить хорошую поддержку.

Важно стирать барьеры и ставить себя на место пользователя, который к вам обращается.

Рассматривается ситуация с возвратом билета, на примере покупки через Сбер Спасибо на мероприятие от Яндекса.

Цепочка действий: Я. Афиша — помощь — раздел про возврат — заполнение формы — письмо в поддержку — пересылаются письмо билетному партнеру — партнер пересылает организатору — заявка согласуется — партнер отправляет согласование обратно — одобрено возврат билета пользователю.

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

37. Взлом в поисках инноваций — Миша Чернышев. (директор по маркетингу Додо пицца).

3 составляющие последовательного роста.

1. Лидер и его стиль управления.
2. Корпоративная культура.
3. Реструктирация как постоянный процесс.

Как работает процесс «взлома»?

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

Нулевой шаг — постановка целей и метрик, шаг 4 — измерение после взлома.

Где искать новые элементы системы? 3 метода инноваций в бизнесе, маркетинге и не только. Можно «воровать» у конкурентов, так как желают это все и всегда. (Apple, Lego и прочее).

Книга «Кради как художник». Остин Клеон.

 

За чем стоит следить, чтобы вовремя украсть?

• Технологии и тренды (trandland.com, insider0trands.com, psfk.com);
• Big data (помогает в прогнозировании закупок, логистики и управлению с/с на примере ДоДо);
• Робототехника и сенсоры (дроны как способ доставки);
• Иммерсионные шоу;
• AR/VR;
• Co-creation.

Метод «двойное вороство».

«Чиндоугу» — самое популярное шоу на японском телевидении. Суть — смешать две чужие идеи, выжать из них все самое лучшее/полезное и в результате выдать третью идею, свою собственную.

Метод «Фрэнка Абигнейла».

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

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

38. Управление маркетинговыми проектами — Илья Борисов. (руководитель конкурентного маркетинга в Яндекс Go).

Что делает менеджер по маркетингу?

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

Амбиции и видение.

Какие компетенции нужны команде?

Brand, PR, product, SMM, creative, BTL, CRM, analytics, media, legal, pricing, research.

Как ставить задачи?

Задача должна быть SMART.

Инфраструктура.

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

Задача менеджера — «защитить» сотрудников/коллег от излишнего вмешательства в рабочий процесс.

Важно заряжать людей вокруг себя.

Хорошие идеи в офисе не рождаются — при постоянных переработках наступает выгорание и «замыливается» глаз.

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

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

Feedback sandwich — сначала позитивная реакция, далее негативная и далее еще более позитивная.

Как правильно давать фидбек:

• с холодной головой и сытым;
• заранее сформулировать ожидаемый результат;
• убедиться предварительно, что ос и правда нужна;
• в моменте;
• лучше лично 1 — 1;
• надо быть готовым к тому, что человек не услышит и разрешить себе его не убеждать;
• STAR (фреймворк, Situation Task Action Result).

Эскалация — возможна, но не стоит злоупотреблять этим. Проблемы на своем уровне нужно решать самостоятельно.

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

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

Как получать обратную связь?

• Фидбек надо воспринимать как подарок, вам решать что с ним делать.
• Нужно дать своему начальнику себя научить.

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

39. Пользовательские потребности и фреймворки — Михаил Карпов. (CEO ProductStar).

Базовые фреймворки: JTBD, Buisness Model Canvas, Value proposition.

JTBD.

Персоны и юзер стори — как определенный тип пользователя хочет получить результат, через какие действия? («Как я хочу получить?»).

Сложности модели: множество персон, большое количество информации, дублирование, мало контекста, мало причинно-следственной связи.

Job story — фокус на мотивации и контексте. (ситуация, мотивация, результат, «когда я хочу чтобы...»).

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

Применение JTBD: стратегия роста основных JTBD; стратегия подрывного роста; стратегия роста связанных JTBD; стратегия роста новых JTBD.

Business Model Canvas.

Не является хорошей прикладной моделью и чаще используется при запуске новых продуктов. (Книга — «Построение бизнес-моделей», А. Остервальдер).

Важно использовать «карту эмпатии», она позволяет больше детализировать список вопросов.

Дальнейший шаг — value map.

Что для каких задач использовать?

• JTBD — проще найти причины поведения и инсайты.
• CJM — поглядеть сверху и понять где ошибаемся.
• Working backwards — представить как оно будет и что про это поймут.

Использование нескольких фреймворков помогает снизить количество рисков и посмотреть на пользователя с разных сторон.

40. Современное техническое устройство сервисов — Павел Пушкарёв. (Технический менеджер).

Устройство и масштабирование сервиса на примере инстаграм.

Backend (приложение на сервере), АПИ (набор правил для взаимодействия с сервером), БД, клиент (приложение у пользователя), файловая система.

Для масштабирования сервиса добавляются сервера и устанавливается балансировщик нагрузки.

Микросервисы и облака.

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

Как поддерживать рабочее количество контейнеров когда их много (1000 и более)?

Использовать облачный распределитель.

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

Команды — Devops и SRE.

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

Лучшая схема — один человек, отвечающий за все 3 момента.

SRE — пишут код инфрастуктуры и CI как разработчики, выкатывают код и мониторят инфраструктуру как админы, пишут автотесты.

Инженеры QA — пишут код сложных интеграционных тестов, одобряют выкладывание кода и следят за релизами, пишут автотесты.

41. Культура принятия решений на основе данных — Игорь Яшков. (руководитель службы продуктовой аналитики).

Яндекс проводит АБ-экспериментов за год около 3000 шт.

Жизненный цикл фичи: идея — оценка потенциала — прототип — офлайн эксперимент — разработка — выделяем проект пользователей и выкатываем ан них физ — смотрим на метрики — продакшн.

Интервью/CustDev как тип исследования:

• + легко подготовить и провести; можно узнать глубинные причины; не требует наличия прототипа;
• - ловушка подтверждения; люди не в контексте использования; риск получить anecdotal evidence.

Usability Lab:

• + возможно посмотреть на взаимодействие пользователя с продуктом; можно проводить на дешевых прототипах; можно сделать быстро;
• - пользователь работает по сценарию; требует обученных исследователей; риск получить anecdotal evidence.

Опросы:

• + можно собрать большое разнообразие мнений; не требует наличие прототипа; можно привязать к фиче в продукте или состоянию пользователя;
• - self-selection bias; собираем мнение, а не поведение; сложно контролировать качество ответов.

UX без модераторов:

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

Аб-тестирование придумали в медицине.

Особенности АБ: надежный способ выявить причинно-следственную связь; сводит к минимуму влияние сезонности, активности и пр.; но не всегда отвечает на вопрос «Почему?»

Ловушка 1 — в эксперименте нужно стремиться заменить сложно вычислимый критерий успеха на понятную метрику.

Ловушка 2 — недостаток мощности = вероятность ошибки второго рода, то есть не заметить эффект при его наличии в реальности.

Ловушка 3 — p-value hacking — степень удивленности.

Ловушка 4 — оптимизм — переоценивающие вероятности позитивных событий. Если результат странный, но плохой в нем будут разбираться. Если результат странный, но хороший, его примут как успех.

Ловушка 5 — накрутка метрик.

42. Тренинг по CustDev — Михаил Войтко. (руководитель продуктов Сбер.)

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

Продукт создается именно для пользователя. Конкуренция идет не за деньги, а за внимание. Идет смещение к микросегментации пользователей. Фреймворк JTBD = работа на которую нанимают сервис. Пользователь должен быть всегда в центре внимания — все строится вокруг него, а не вокруг бизнеса и ограничений.

Основные черты поведенческой экономики:

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

Дизайн-мышление.

Гипотеза — утверждение о продукте/аудитории, которое нужно проверить. Формируется в утвердительной форме.

Виды гипотез: поведения; гипотезы проблемы; мотивации; гипотезы блокеров (что мешает?).

Где искать аудиторию для интервью? Друзья/коллеги; знакомые друзей; соц сети; среди лидеров мнений; на хабах; на спец сайтах (фрилансеры, Толока); на конференциях; встреча с потенциальными пользователями; опрос текущих пользователей; тик-ток.

Создание прототипа.

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

Полезные советы.

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

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

43. P&L и финансы — Иван Трошин, Александр Михайлов.

P&L — Profit & Loss statement — отчет о прибылях и убытках, содержит данные о доходах, финансовых результатах в сумме нарастающим итогом с начала года до отчетной даты.

Складывается из выручки, ОРЕХ (операционные расходы).

EBITDA = net income + D&A, taxes, interest.

Как структурирована успешная модель?

• Выручка — COGS = юнит-экономика.
• Юнит-экономика > фиксированные расходы.
• Юнит-экономика * LT > CAC (Customer Acquisition Cost).

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

От выбора финансовой модели зависит простота объяснений отклонений.

Top-down.

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

Bottom-Up.

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

Модели для оценки компании.

DCF (дистонтирование денежных потоков). Основной принцип — текущая стоимость компании есть сумма всех ее будущих денежных потоков, скорректированная на временную стоимость денег.

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

Исторически-транзакционный (анализ предыдущих сделок и слияний или поглощений) — сравнение с ценой покупки аналогичных компаний практике.

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

WACC — ставка, которая отражает веру инвесторов в бизнес и проекты, зависящая от:

• средней прибыльности аналогов на рынке;
• стоимости кредитов;
• риска, который видят инвесторы.

Чем выше показатель, тем дешевле компания.

Key Take-outs.

Деньги стоят денег и время стоит денег.

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

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

44. Современные процессы разработки — Дмитрий Сухолет.

Процесс разработки продуктов: оценить потенциал — найти продукт — создать продукт.

Создание продукта.

Невозможно создать продукт без команды.

Как навести порядок в работе команды?

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

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

Вопросы.

• Как разрабатывается сейчас?
• Как решаете что брать в работу дальше?
• Как оцениваете задачи?
• Как разбиваете роадмэп?
• Сколько стоит релиз?

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

Как действовать, если процесса нет?

• Брать и пробовать работать по методологии.

Почему agile?

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

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

Специфика в Я. Почте: релизы ограничены по времени, новый функционал выкатывается на маленький процент аудитории, все крупные изменения сначала проходят А/Б.

После высаживания процессов нужно понять, стало ли лучше — помогает ли нововведение чаще приносить пользу юзерам? Стали ли работать лучше? Всем ли понятно, чем мы занимаемся? Укладываемся ли в сроки? Какие части процесса мешают?

Заключение:

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

45. Тестирование и CI в мобильных и веб-продуктах — Егор Чехиевский. (руководитель службы тестирования).

Что такое качество?

Полнота соответствия ожиданиям конкретного критерия.

Тестирование — проверка соответствия фактического результата ожидаемому.

Качество продукта — интегральный показатель уникальной комбинации критериев и шагов проверки.

Достижение и удержание качества продукта — постоянное движение и командная работа.

Фазы проекта:

• проектирование (подготовка к тестированию);
• реализация (тестирование изменений — максимальная нагрузка на тестирование в момент релиза);
• эксплуатация (анализ сигналов и точечные проверки).

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

Фаза проверки — глубина тестирования, последовательная проверка с последующим расширением.

Исполнители — первыми тестирует команда, далее коллеги из соседнего продукта, далее лояльные пользователи (закрытая бета), далее — открытое бета-тестирование.

Советы и рекомендации.

Команда.

• Важно сформировать команду, которая должна искренне разделять ответственность за качество; понимать и быть согласна с процессами и kpi; разработка должна принять ответственность за качество кода.
• Определить ответственных за измерение и процессы обеспечения качества (QC и QA).
• Быть пользователем своего продукта в обычной жизни.
• Привить команде обязанность анализировать и исправлять причины пропуска и ошибки в продакшене — процедура разбора инцидентов (LSR — live site review).

Реализация.

• Определить критерии начала и окончания этапов создания продукта; окончание разработки — готовность — запуск публичной беты — выкладка релиза на 1-100%; комбинация значений: сделанный объем работ, глубина тестирования; характер ошибок.
• Описать продуктовые требования, макеты, тех реализацию.
• Убедить разработку писать тест кейсы. Этапность: code + test case, code review (dev team), test case review (dev + qa team), тестирование.

Планирование.

• Запланировать раннее тестирование продукта.
• Принять, что изменение объема или сроков разработки влияет на сроки тестирования.
• Заложить время на тестирование и реалистичное число итераций: чем больше изменений, тем больше ошибок; чем больше исправлений, тем больше новых ошибок, а часть старых будет переоткрыта; чем меньше проработан требования, макеты, сценарии — тем больше будет вопросов; нужен буфер по времени на исправление и рефакторинг; проверить наличие задача, требующих 0 часов разработки и 100 часов тестирования.

Тестирование.

• Согласовать ключевые метрики и целевые значения для тестирования; Coverage-Quality — успешность всех мер по предотвращению пропуска ошибок в прод, которые не стоит пропускать; time-to-result — скорость предоставления результат проверки. Важно смотреть отдельные показатели: время выполнения тестов, количество ошибок, задачи т анализировать это все в составе общей метрики time-to-market.
• Определить подходящую конфигурацию команды: в штате только сильные универсалы; мало штатных QA — они владеют экспертизой по продукту и отвечают за достижение целевых метрик; все типовые/простые работы лучше отдавать асессорам; в будущем — в команде нет постоянных QA, они приходят только в случае сигнала о помощи в текущих процессах либо чтобы помочь построить новые.
• Не забывать проверять работу продукта в реальных условиях, не ограничиваться искусственными.
• Возможные задачи тестирования: выполнение различных видов тестирования; актуализация тестовой документации; проверка готовности к новым требованиям (версия ОС, локализация, регион); исследование — воспроизведение проблем, запись ошибки; сравнение работы с конкурентами; анализ качества; воспроизведение старых ошибок; проверка готовности и участие во встречах.

Готовый продукт.

• Корректировать процессы по мере поступления новых вводных по ходу создания и эксплуатации продукта.
• Использовать в работе данные с прода: версии ОС, браузеров, производители и модели устройств, разрешения экранов.
• Анализировать как видят продукт пользователи и улучшать его; анализировать обращения в ТП и отзывы в сторах; смотреть метрику CSAT (удовлетворенность пользователя) по шкале от 1 до 5; регулярные командные калибровки и улучшение внутренних процессов.
• Посчитать и удерживать конечное качество продукта в цифрах (Zero Bug Policy).
• Следить за скоростью исправления ошибок.

Помощь тестированию.

• Ревью тест кейсов, групп и регулярность их выполнения; выполнять совместно с разработкой.
• Планировать ресурсы в помощь тестированию: логи, точечные утилиты; автоматизация + регулярные проверки: smoke; acceptance выборочно — не новая функциональность; regress выборочно — редко меняющаяся важная функциональность; часто выполняемые или длительные тесты и проверки большого числа схожих конфигураций.
• Выработать систему приоритезации ошибок и регулярно выполнять ревью; примеры факторов при определении ошибки: объем заблокированных работ на этапе создания, охват пострадавшей аудитории, характер неудобства.

46. Саппорт в продукте и для продукта — Саша Ширяева. (руководитель клиентского сервиса Медиасервисов).

Саппорт изнутри:

У поддержки много линий поддержки, чаще всего делится на 3 — первая решает простые вопросы, использует шаблоны, дешево обходится, может быть заменена на ML; вторая решает вопросы средней сложности, вопросы не требуют обратной связи от смежных отделов; третья решает сложные вопросы, где требуется тестирование или долгое общение с пользователем, тесно общаются с QA и разработкой.

Операционные метрики: качество (CSAT, DSAT, CES, FCR, LCR), скорость (AFRT, ART, RESOLUTION TIME), эффективность (CPT/CPO, AHT, ER, Backlog).

Зачем нужен саппорт продукту?

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

Общие метрики саппорта и продукта. CSAT/DSAT/CSI.

После завершения работы над обращением поддержка интересуется у клиента все ли ему понравилось и помогли ли ему. 50% ответов на такой вопрос содержат жалобы не на операционную, а на продукт. Работать с этими метриками = улучшать продукт и впесатлие клиента.

NPS.

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

LT/LTV/GVM/Retention/Churn.

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

Саппорт как источник инсайтов.

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

Анализируйте — дорабатывайте — анализируйте снова — предвосхищайте проблемы новых клиентов и решайте их заранее. (Например: авторизация в Кинопоиске на ТВ).

Взаимодействие саппорта и продукта.

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

Чем может продукт помочь саппорту?

• Информирование о грядущих акциях/событиях;
• помощь с доработками внутренних систем и продуктов;
• улучшить точку входа в саппорт (чем проще — тем лучше);
• вовлекайте саппорт в свою работу (зовите на встречи, обсуждайте запуски, обновления).

47. Инфлюенсеры — Женя Бондаренко. (дигитал-менеджер Я. Go)

Кто такие инфлюенсеры?

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

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

Существуют два основных формата: блогеры/инфлюнсеры (для разовых размещений) и амбассадоры/лидеры мнений (постоянно поддерживают бренд в своих аккаунтах).

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

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

• блогер с правильным имиджем;
• подходящий задачам;
• вменяемый ценник.

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

Боли:

• генетик контент (бездушный контент);
• понять — как оценить результат на берегу;
• если бюджет сливается — осознать произошедшее.

48. Работа с копирайтером — Ксения Витюк. (главный редактор Я. Плюс).

При работе с продуктом, в частности, с текстом, лучше сделать базу, и не сделать «кайф», чем сделать «кринж».

Роль текста в продукте.

Виды текстов.

• Продуктовые (онбординг, экраны, кнопки, чекбоксы, меню).
• Маркетинговые (письма, пуши, соцсети, лендинги, партнерские коммуникации).

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

Текстом можно решать разные проблемы. Важно задавать вопрос — может ли эту проблему решить текст?

Tone of Voice — код бренда, который поможем отличаться. Он должен прослеживаться во всей коммуникации продукта.

Что в тексте важно?

Работать из мира пользователя, а не из вселенной бренда.

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

Нужно учитывать эмоции и контекст, коммуникация должна быть уместна.

Тексты нужно тестировать, ошибаться не страшно, страшно не найти те самые решения.

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

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

Идеальная связка = продакт + дизайнер + редактор. Делитесь гипотезами, результатами экспериментов, сомнениями и открытиями.

Задачи надо ставить четко и подробно и давать понятный фидбэк.

49. Brain science — Александр Жестков.

Мозг человека в большей степени иррационален. Изначально мозг не предназначался для обработки сложной математической информации, вывод — производите все статические расчеты за пользователя (выдавайте итоговые цифры).

Мозг ленивый экономит энергию. 40-80% ежедневных решений происходит автоматически, это влечет за собой когнитивные искажения.

Давайте пользователю совету при выборе, сокращайте число позиций.

Мозг генерирует случайное поведение. Нужно использовать четкие CTA (призыв к действию) в своих коммуникациях.

Мозг иррационален по своему дизайну. Нужно рационализировать выбор.

Мозгом движут потребности. Потребность — эмоция — обучение — потребность.

Не нужно пытаться изменить глубокие привычки. (Н: сториз везде выглядят практически одинаково).

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

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

50. Продуктовый дизайн — Андрей Мануилов (руководитель группы дизайна сервисов).

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

Дизайнер продукта выступает соавтором концепции, прототипа и коммуникации.

Дизайн-процесс.

• Предпроектный анализ. (Выяснить какую проблему пытаемся решить? Как человек оказывается в сервисе? Как решается задача сейчас и что не устраивает в текущем решении? Какие цели преследует компания? Как оценить успешность?)
• Поиск решений. (Сначала решения генерируются, дальше выбираем самое лучшее, постепенно детализируем, проектируем желаемый user flow и логику работы).
• Выбор тактики. (MVP и итеративная разработка, выбор критериев успешности, формулировка состава первого шага).
• Дизайн (расписать флот и сценариев, учет дизайн-системы, важно вдеть тексты в интерфейсах,онбординг и обучение, в результате получаем детальное решение, которое содержит все сценарии и кейсы).
• Финализация (подготовка к разработке: корнер-рейсы, особенности платформы, микровзаиодействия и переходы).
• Внедрение (внедрение вместе с командой разработки и тестирования, важный момент - коммуникационная и ПР поддержка запуска).

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

51. Удержание — Дмитрий Субботин, Дина Нафикова.

Что такое удержание?

Retention rate = пользователи в конце периода — новые пользователи/ те, кто был в начале периода * 100%.

Что важно для удержания?

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

Что делать для удержания?

В зависимости от типа пользователя.

1. Те, кто пришел — обучение и онбординг.
2. Те, кто хочет уйти — опросы при отмене о причине; предложить более дешевый вариант; указать на преимущества еще раз; винбэкофер (Н: уменьшение стоимости подписки при попытке отмены).
3. Те, кто с вами — разговаривать с пользователем (велком письма, пуши); вера в классный пользовательский опыт тоже может быть идей удержания; экспериментируйте.

52. Приоритизация задач в новом и состоявшемся продукте — Гузель Филатова. (менеджер продукта в Кинопоиске).

Зачем уметь приоритизировать?

• Данных и информации очень много.
• Ограниченное количество ресурсов.
• Постоянно меняющийся мир.

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

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

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

Рецепт хорошего бэклога: состоит из конечного количества задач; приоритизирован; актуален.

Как сделать бэклог конечным: разделить на части имеющиеся и выкинуть ненужное.

Методы приоритизации.

Модель Кано.

• Уровень удовлетворенности пользователей зависит от качества и количества функциональностей.
• Все фичи делятся на 4 категории.
• Можно измерить уровень удовлетворенности при помощи опросов.

Опросник для пользователя.

Как вы относитесь к наличию/отсутствию данной функциональности?

• нравится;
• это то, что я ожидаю;
• все равно;
• могу это терпеть;
• не нравится.

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

Метод Rice.

• Reach — сколько пользователей воспользуется фичей ща месяц.
• Impact — как фича повлияет на цели: 3 — сильно, 2, 1, 0,5, 0,25 — минимально.
• Confidence — уверенность в предыдущем расчете 0-100%.
• Effort — трудозатраты.

Rice score = reach*impact*confidence/effrot.

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

Как делить бэклог на части?

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

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

53. Инструменты поиска и проверки гипотез — Михаил Высоковский.

Нужно держать баланс между скоростью (про реализацию) и уверенностью (про исследования).

Как растить уверенность?

Провести телефонный опрос в произвольное время. Провести личные интервью.

Ограничение любого метода — легко сделать ошибочный вывод.

В первую очередь нужно структурировать и вдохновить!

Классификация методов исследования.

Качественные (отвечает на вопросы «почему» и «зачем»: глубинные интервью, фокус-группы, экспертные интервью, дневники, отзывы, интервью в контексте) и количественные (показывают число приверженцев).

Про восприятие (понять что у человека в голове) и про использование (что человек делает: юзабилити-тестирование, айтрекинг, тестирование прототипов).

Количественные про использование: А/Б тестирование, тепловая карта исследования, автоматизированные массовые задания по использованию продукта, промо-страницы без продукта, фейковые страница стора для теста конверсии, только онбординг в приложении.

Количественные про восприятие: опросы (тестируйте до запуска, определитесь как будете анализировать данные, помнить про репрезентативность, котируйте позиции ответов, думать над открытым вопросом), воронка знания (спонтанное знание, первое упоминание, знание с подсказкой) и использования (когда-либо, за месяц, чаще всего, готовность рекомендовать), сравнение вариантов дизайна на большой выборке, количественный анализ отзывов, готовые исследования (проведенные компаниями открытые/закрытые).

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

54. Кризис-менеджмент — Владимир Тетерин. (маркетолог Я. Музыки).

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

Откуда возникает кризис?

Неконтроллируемые изменения: изменилась среда; не предусмотрели факторы среды; не предусмотрели мильтиплицирующие факторы.

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

Что нужно делать?

Определить, что мы знаем; определить, что не знаем; узнать то, что не знаем.

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

Без чего не может быть фокуса?

Без аналитики и целевой метрики. Требования к метрикам: может быть цифровой (измеримой количественно) и качественной.

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

Требования к процессам.

Особенности: частота коммуникаций; структурирование информации; осведомленность команды; принятие процессов командой.

Правила команды для кризисных задач.

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

Далее рассматриваются два примера — фрод на спецпроекте и подвел партнер.

Вопросы — что делаем/что не делаем, кто нужен для решения, статус-сообщение.

Менеджер проекта

Статьи

05 февраля 2023

---