Продуктовый подход в разработке ИТ-продукта

Ксения Чаусова
Product Manager Doczilla

В процессе создания ИТ-решения возникает много идей, которые сразу же кажутся блестящими. Модные тенденции ИТ-рынка, такие как импортозамещение, Low Code/No Code, искусственный интеллект, анализ данных и другие, выглядят компонентами формулы создания идеального продукта. Однако по-настоящему важно видеть потребности клиента. Оценивать идеи нужно с точки зрения того, какую пользу принесет продукт конечному пользователю и бизнесу в целом.

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

Фокус

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

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

Основные преимущества

Бизнес-ценность

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

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

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

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

Четко определенная бизнес-ценность позволяет делать продукт, который нужен и приносит пользу

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

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

Качество продукта

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

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

Команда, ориентированная на продукт, направляет все усилия и средства на создание идеального продукта.

Гибкость

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

Как работает наша команда?

Командная работа

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

Методология согласования продукта

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

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

Команда роста

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

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

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

Постоянный контакт с пользователями

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

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

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

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

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

Вовлеченность пользователей позволяет нашей команде не сбиться с пути при разработке продукта.

Итерации. Работа по этапам

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

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

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

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

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

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

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

Оценка результата состоит из следующих блоков:

Метрики успеха

  • Насколько у нас получилось достичь метрик успеха?

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

  • Что получилось?
  • Что не получилось и почему?
  • Чему научились?
  • Как это поможет нам в будущем?

Вывод

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

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

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

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

44
Начать дискуссию