Три кита продуктового подхода в ИТ-разработке

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

Мы в True Engineering занимаемся продуктовой разработкой уже около 10 лет – наши системы и приложения работают в S7, «Ингосстрахе», Leroy Merlin и других крупных компаниях. Все эти годы мы строим свои решения на базе продуктового подхода, так что все размышления в этой статье проверены на реальных проектах.

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

Цифровизировать можно, но сначала нужно задать вопрос: зачем? Может быть, чтобы сотрудникам не нужно было заполнять документы вручную? Или чтобы данные быстрее попадали в операционную аналитику? Или мы хотим получить от клиента больше информации, лучше его узнать и продать дополнительные услуги?

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

Ключевые вопросы, по которым надо пройтись перед запуском проекта:

- Кто будущий пользователь системы?

- Что он будет делать внутри продукта?

- С кем он будет взаимодействовать? Как устроен процесс сейчас, и как он должен выглядеть в будущем?

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

Бизнес-ценность очевидна: клиенты довольны, компания разгружает свои офисы, сотрудники меньше работают с документами, процессы двигаются быстрее. А когда грянула пандемия, наш заказчик оказался готов к удаленному обслуживанию. В результате в 2021 году клиенты «Ингосстраха» заявляли через приложение порядка 25 % страховых случаев по каско и значительную часть убытков по ОСАГО.

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

Из первого пункта следует вывод – продуктовый подход приносит измеримый результат. Это может быть сокращение звеньев в цепочке принятия решений – автоматический контроль избавляет от необходимости заносить бумажку в какой-нибудь кабинет. Или ускорение обработки данных – как сейчас андеррайтинг при проверке кредитных заявок в приложении проходит за полторы минуты без участия «живого» специалиста. Зачастую можно оценить эффект и в количестве новых пользователей, и росте продаж.

Чтобы выбрать метрики, нужно вернуться к вопросам, про которые мы говорили выше, и разобраться, чью жизнь упростит продукт и как. Если цель – сократить бумажную рутину и ускорить обработку клиентских заявок, то вы будете следить за скоростью этих процессов. Если вы переводите на цифровые рельсы какие-то «аналоговые» услуги, то нужно смотреть, как быстро клиенты привыкают к новому сервису. И так далее.

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

А вот как дела обстоят теперь:

7 шагов, на которые требуется 9 дней, против 4 шагов и 2 дней – эти цифры явно показывают ценность продукта для бизнеса.

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

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

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

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