Продуктовый подход в разработке LegalTech-решений

Найдите фокус

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

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

Не забывайте: бизнес – ценность

Продуктовый подход предполагает, что продукт позволит решить конкретную задачу. Прежде чем автоматизировать бизнес-процесс или выпускать новую фичу, нужно ответить на вопрос «зачем?». Например: чтобы сотрудникам не нужно было готовить типовые документы вручную; чтобы шаблоны типовых договоров могли автоматизировать юристы, а не разработчики; чтобы все типовые формы хранились в едином облаке и т.п.

Ответы на вопрос «зачем?» и есть бизнес-ценность, которую принесет IT-решение. Если четко ее определить, получится сделать продукт, который будет нужен.

Мы в работе используем еще несколько вопросов, чтобы лучше понимать потребности клиента и фокусировать на них продукт:

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

Думайте о качестве продукта

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

Все усилия и средства команда должна направить на создание идеального IT-решения.

Будьте гибкими

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

Сохраняйте командный дух

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

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

Создайте команду роста

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

Поддерживайте связь с пользователями

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

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

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

Работайте поэтапно

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

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

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

Оцените результат

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

Оценка результата может состоять из нескольких блоков.

• Метрики успеха: смогли ли мы достичь показателей, отражающих успешность продукта?
• Ретроспектива: что получилось? Что не получилось и почему? Чему научились? Как это поможет нам в будущем?

У нас подобная оценка проводится по итогам каждого квартала. Анализ ошибок позволяет избегать их в будущем, а обсуждение побед дарит возможность радоваться успеху.

***

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