Портал Mail

Главная страница

При открытие Главной страницы Портала Mail пользователю доступны различные сервисы Портала. А именно:

  • авторизация/регистрация на платформе Mail (если пользователь ранее не был авторизован на сервисе);
  • Почта;
  • Облако;
  • Новости;
  • Рекомендательная система Пульс;
  • Поиск;
  • Погода;
  • Игры;
  • Гороскопы;
  • Пробки (для некоторых городов);
  • Курсы валют;
  • Одноклассники;
  • ВКонтакте;
  • ТВ-программа;
  • другие.

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

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

Далее использование сервиса Портал Mail заканчивается, т. к. пользователь переходит непосредственно в интересовавший его сервис и продолжает его использовать.

Если пользователь хочет воспользоваться ещё каким-то из доступных на портале сервисов, то достаточно снова открыть в браузере страницу портала по адресу https://mail.ru

Описание процессов, обеспечивающих поддержание жизненного цикла

Команды, участвующие в разработке и обслуживании продукта

  1. Команда разработки — разработчики, которые отвечают за разработку продукта.
  2. Команда аналитики – аналитики, настраивающие сбор аналитики и вывод собранных данных.
  3. Менеджер продукта – менеджер, ответственный за развитие продукта.
  4. Команда дизайна — разрабатывают визуальный стиль продукта и UX.
  5. Команда разработки бэкенда – разработчики, отвечающие за серверную разработку.
  6. Команда тестирования — разработчики, отвечающие за качество продукта и дистрибуцию бета-сборок.
  7. Инфраструктурная команда — системные администраторы и разработчики, обеспечивающие поддержку продукта на инфраструктурном уровне.
  8. Переводчики, редакторы — обеспечивают продукт всем необходимым текстовым наполнением, переводят интерфейсы на другие языки.
  9. Маркетинг — отвечают за привлечение аудитории в продукт, его продвижение на рынок.

А также команды:

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

Разработка продукта

Целеполагание

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

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

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

Цели прорабатываются с точки зрения метрик и конкретных значений.

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

Планирование квартала

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

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

Все задачи декомпозируются на подзадачи. Тимлид команды составляет диаграммы Ганта, по которым прогнозируют сроки передачи задачи в тестирование и выпуск версии с этой задачей.

Работа над задачей

Менеджер продукта вместе с дизайнером прорабатывают UI и UX задачи.

Макеты проходят дизайн-ревью команды.

Менеджер передает прототипы в UX лабораторию. После проведения UX и количественных тестов вносятся правки в макеты/прототипы.

После чего задача ещё раз проговаривается менеджером с тимлидом разработки.

Тимлид назначает задачу конкретному исполнителю.

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

После прохождения тестирования задача вливается в альфа-ветку.

Создаются графики KPI фичей (как технических, так и продуктовых).

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

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

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

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

Успех и достижение целей отслеживается по графикам.

Незапланированные задачи

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

Кейсы:

  • Важная и срочная для компании задача. Это может быть маркетинговая акция; задача, связанная с репутацией компании; фича, которую нужно немедленно доставить пользователям. Важность задачи определяет менеджер продукта. Менеджер обсуждает с тимлидами, какая вероятность взять эту задачу в работу, не сдвинув план, или подвинув что-то менее критичное.
  • Если ничего, влияющего на OKR не съезжает, то задача добавляется. Например, некоторые заложенные риски могут не сыграть и освободится немного времени для небольшой задачи.
  • Если задача вытесняет что-то из стека запланированных задач – продуктовый менеджер обсуждает с продуктовым директором квартальный план и возможные изменения. После чего планы либо остаются изначальными и задача откладывается до следующего квартала, либо согласовывается новый план.

Баги

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

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

Новые баги чинятся сразу же в том же релизе, если они нетривиальные.

Баги, уже живущие в боевых версиях, чинятся в дежурства.

Приоритет бага устанавливается автоматически в багтрекере, на основании нескольких параметров:

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

У каждого приоритета свой SLA по фиксу.

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

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

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

Команда может использовать различные подходы: Разработка в отдельной ветке и тестирование в ней же; Итеративная разработка через feature toggle.

Поддержка и модерация

Команда поддержки в курсе всех выходящих релизов.

Есть согласованные шаблоны для ответов.

Отзывы разделены на типы, ведется статистика по каждому типу отзывов.

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

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

Статистика и аналитика

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

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

Для оценки эффективности запуска и влияния на другие сервисы используется одна система для A/B-тестов.

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

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

Маркетинг и пиар

Команде маркетинга/пиара/рекламы доступно подробное описание продукта, а по возможности организован доступ к тесту. При необходимости согласован список партнеров для раннего тестирования от пиара/ маркетинга/рекламы.

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

Целевая аудитория для продвижения продукта описана в критериях таргетингов рекламного движка, а также по возможности сегментирована на подгруппы.

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

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

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

Подготовлен и согласован медиаплан для размещения, при необходимости внешнего размещения согласован бюджет.

Сотрудникам, ответственным за продвижение, доступны статистика и аналитика продукта.

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

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

Юридическая чистота

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

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

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

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

Пострелизное обслуживание

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

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

Баги оперативно чинятся.

Сбор обратной связи

Пользователь из Поддержки или партнёр присылает свой фидбек о продукте.

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

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

Задачи, являющиеся багами связываются с уже известными дефектами в трекере. Если такого дефекта в системе не было – заводятся новые и связываются, чтобы после разрешения бага дать фидбек репортеру.

Ретроспектива

После реализации больших задач проводится ретроспектива.

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

Почему успели или не успели. Делаются выводы на следующий раз.

Эксплуатация

Программное обеспечение Портал Mail является сервисом, размещённым в сети Интернет. Для его эксплуатации требуется ЭВМ с браузером (программным обеспечением) для работы в сети Интернет. Браузер должен быть на основе Chrome версии 56 или выше.

Модернизация и обновление программного обеспечения

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

Техническая поддержка и решение вопросов

Техническая поддержка пользователей осуществляется по адресу: https://help.mail.ru/

Вопросы, возникающие в ходе работы с продуктом, следует направлять в службу поддержки по адресу: support@corp.mail.ru

Помощь Mail
Обновлено 1 ноября 2022 г.
Служба поддержки
Поможем решить проблему
Служба поддержки
Поможем решить проблему
Чат-бот
Подскажет быстрое решение
Чат-бот

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

Чат-бот поддержки
Нажмите на иконку и задайте вопрос — чат-бот быстро найдёт ответ