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

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

Бизнес-ценность – прежде всего

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

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

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

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

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

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

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

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

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

Понятные цели, измеримые результаты

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

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

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

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

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

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

Стратегическое планирование с первых спринтов

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

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

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

Выводы

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