Процессы Discovery & Delivery в Аврора Центре

Привет, Хабр! На связи Александр Конин, ведущий менеджер продукта в Открытой мобильной платформе. В рамках текущего материала хотелось бы рассказать как выглядят процессы Delivery и Discovery в продуктовых командах Аврора Центра.

Продукт «Аврора Центр» и приоритизация задач

Наш продукт — это корпоративная система управления парком мобильных и стационарных устройств, будь то мобильные телефоны на ОС Аврора или Android, или компьютер на Linux.

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

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

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

• запросы от стейкхолдеров;

• участие в тендерах на аналогичные системы;

• пилотирование нашего продукта у заказчиков;

• общение с пользователями;

• изучение рынков;

• конкуренты;

• брейнштормы.

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

Входящий поток идей приоритизируется в рамках работы продакт-менеджера и синхронизации задач между продактами разных направлений (поддержки и развития Авроры, Android и Linux). Обсуждение каждой задачи строится, исходя из критериев приоритизации:

1. Проекты внедрения в рамках действующих контрактов.

2. Зрелость платформы Аврора.

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

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

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

Этап Discovery

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

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

Например, в результате общения с рядом заказчиков по задаче с интеграцией данных из LDAP и назначением на группу из Active Directory политик через EMM-систему, удалось выявить уникальный запрос на подстановку «динамического» параметра из карточки LDAP, поскольку в корпоративном учете компании значились фейковые сотрудники с именами «user 1», «user 2», «user 3», и реального в них было лишь то, что они работали в определенной бригаде, а сами были временными сотрудниками без постоянной учетной записи. Подобный кейс оказался частотным и в других компаниях, поэтому при создании функционала мы реализовали и эту небольшую фичу по кастомному полю.

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

• Строим CJM пользователей и проектируем новые пути пользователя в продукте.

• Изучаем конкурентов, а также возможные продукты-заменители, которые могут решать схожую задачу.

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

• Строим пирамиду метрик по каждой крупной задаче.

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

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

1. Прототипирование и проверка на потенциальном заказчике. Зачастую мы делаем прототип в виде макетов или кликабельный прототип в Figma и в рамках интервью с пользователем обсуждаем данную реализацию. Обычно прототип получается реализовать за одну неделю с момента выработки решения, и пройдя по 3-5 потенциальным заказчикам, можно модифицировать решение до состояния, когда всем им реализация подходит.

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

3. Продажа. У нас были кейсы, когда мы решили выйти на новую платформу (Linux) и, провалидировав основные запросы, реализовали быстрый прототип, практически без доработок основного клиента под Аврору, смогли показать 1 сценарий работы под Linux и получили продажу. После данного кейса прототипы стали содержать меньше фейковых данных и были переписаны технически для продакшен работы, но сама продажа решения состоялась на этапе Discovery нового направления.

По результатам завершения процесса Discovery пользовательской проблемы аналитик совместно с продактом начинают процесс User story mapping, разбивая сформированную фичу на стори. Данные стори начинают обсуждаться с командой разработки, и начинается процесс технического Discovery.

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

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

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

Этап Delivery

Этап Delivery для команд выглядит повторяющимся событием с привычной рутиной. Продуктовая команда живет спринтами, которые длятся две недели. Спринты начинаются с планирования, в рамках которых команда обсуждает еще раз все взятые задачи и составляет сценарий спринта, в котором по дням расписывает, когда каждый член команды и чем занимается, и когда он передаст свою часть работы далее. Каждое утро у команды начинается с Дейли, где происходит быстрый синк по текущим задачам. В рамках двухнедельных спринтов происходит серия PBR, задачи в котором должны быть включены в следующий спринт. Мы осознанно ушли от PBR-задач на далекую перспективу, поскольку условно через 1-2 месяца команды уже забывают контекст обсуждения задач, и необходимо новое погружение.

Релизный цикл для «Аврора Центра» не имеет четких размеров, а зависит во многом от потенциальных заказов. Поэтому он может состоять как из 1-2 спринтов, по результатам которых мы проводим регрессивное тестирование и передаем заказчикам продукт с озвученными для них новыми фичами. Так и можем разрабатывать большие фичи несколько месяцев, подходя к заключению большого контракта с крупной B2B компанией.

Заключение

Рынок B2B продуктов подразумевает разные циклы заключения контрактов. И довольно часто от первой презентации продукта до заключения контракта проходит до 10 месяцев, в рамках которых проводится серия пилотов на инфраструктуре заказчика, а также согласование условий контракта и заключение договора. В рамках этого времени продуктовая команда успевает провести большое количество исследований и реализовать много фич, и гибкая релейная политика помогает выходить с готовым продуктом в нужный срок. В отличие от B2C рынка, частые релизы (например, каждую неделю) не нужны большинству заказчиков, поэтому скорость разработки динамично подстраивается под новые контракты и запросы уже существующих клиентов.