Продуктовый подход в разработке ИТ-продукта
В процессе создания ИТ-решения возникает много идей, которые сразу же кажутся блестящими. Модные тенденции ИТ-рынка, такие как импортозамещение, Low Code/No Code, искусственный интеллект, анализ данных и другие, выглядят компонентами формулы создания идеального продукта. Однако по-настоящему важно видеть потребности клиента. Оценивать идеи нужно с точки зрения того, какую пользу принесет продукт конечному пользователю и бизнесу в целом.
Применять продуктовый подход при разработке IT решения — значит делать акцент именно на практической пользе сервиса для бизнеса, а также быстро реагировать на изменяющиеся требования конкурентного рынка и адаптироваться к сложному поведению пользователей.
Фокус
В разработке Doczilla Pro мы фокусируемся на пользовательском опыте и постоянном развитии. В то же время стараемся сохранять максимально возможное качество и скорость работы продукта.
Используя продуктовый подход, мы создаем IT-решение, которое клиенты хотят получить. Наша задача на любом этапе развития продукта выпускать улучшения на основании удовлетворения потребности клиентов.
Основные преимущества
Бизнес-ценность
Продуктовый подход предполагает, что создаваемый продукт решает конкретную задачу. Любую идею нужно проверять.
Прежде чем автоматизировать бизнес-процесс или выпускать новую фичу, необходимо ответить на вопрос: «Зачем?». Ответом может быть:
- Чтобы сотрудникам не нужно было готовить типовые документы вручную.
- Чтобы шаблоны типовых договоров могли автоматизировать юристы, а не разработчики.
- Чтобы все типовые формы хранились в едином облаке.
Полученный ответ и есть реальная бизнес-ценность, которую принесет будущий продукт.
Четко определенная бизнес-ценность позволяет делать продукт, который нужен и приносит пользу
Ключевые вопросы, на которые нужно ответить перед запуском проекта:
- Кто такой будущий пользователь системы?
- Какую проблему он хочет решить?
- Какие действия он будет выполнять внутри продукта?
- С кем он взаимодействует в процессе решения проблемы?
- Как устроен процесс сейчас, и как он должен выглядеть в будущем?
- Чего достигнет пользователь при помощи продукта?
Качество продукта
Когда внимание всей команды сосредоточено на выпускаемом продукте, его качество повышается. Если команда больше беспокоится о сроках, то все внимание уходит на то, как можно быстрее выпустить фичу, при этом упускаются детали реализации, меньше времени тратится на тестирование. Это снижает качество кода, а вследствие и продукта, что отодвигает команду от основной цели.
Когда внимание всей команды сосредоточено на выпускаемом продукте, его качество растет. Если команда больше беспокоится о сроках — качество кода снижается.
Команда, ориентированная на продукт, направляет все усилия и средства на создание идеального продукта.
Гибкость
Продуктовая команда легко адаптируется к движению бизнеса и учится по мере разработки продукта. Мир разработки IT-решений очень быстро развивается. Это развитие не может не влиять на изменение требований и потребностей со стороны бизнеса. Смена приоритетов и отклонение от первоначального плана не мешает продуктовой команде продолжать работу над достижением результата.
Как работает наша команда?
Командная работа
Вся вовлеченная в продукт команда участвует как в исследованиях, так и в анализе выпускаемых на рынок фич. Все работают вместе и несут ответственность за продукт.
Методология согласования продукта
В Doczilla мы запустили методологию запуска в работу и релиза фич. Цель методологии — поиск оптимальных решений и обеспечение совместной работы, обмена знаниями в продуктовой команде по мере ее развития. В этой работе принимают участие представители разных команд: разработка, проектное управление, менеджеры по работе с клиентами, продажи, маркетинг.
В результате вся команда живет в одном информационном поле и каждый участник влияет на продукт.
Команда роста
Команда роста отвечает за рост и продвижение продукта и компании в целом. Мы регулярно генерируем и проверяем гипотезы, которые могут касаться продукта, маркетинга, поддержки, продаж и даже найма. Источником для генерации гипотез могут быть разные процессы: анализ конкурентов, сбор статистических данных о поведении пользователей, анализ процессов внутри команды, CustDev интервью клиентов и др.
Очень важно говорить с пользователями на разных этапах разработки продукта и оперативно получать обратную связь
Работа по увеличению роста позволяет нашей команде не упустить ни одной возможности для развития.
Постоянный контакт с пользователями
Очень важно говорить с пользователями на разных этапах разработки продукта и оперативно получать обратную связь. У нашей команды есть разные инструменты для разных задач.
Например, на этапе анализа пользовательского пути мы формируем макеты и прототипы фичи, которые направляем пользователям. В рамках короткого созвона или голосования получаем обратную связь. По итогам либо уходим на доработку либо переходим на следующий этап выпуска решения.
Для получения информации о том, как прошел этап тестирования или удалось ли пользователю достичь конечного результата, мы регулярно проводим CustDev интервью. По его итогам мы выделяем инсайты. Инсайты позволяют создавать, проверять и оптимизировать идеи по развитию продукта и компании.
Для оценки удовлетворенности мы регулярно проводим опросы среди клиентов. Опросы позволяют оценить, насколько успешным оказался пользовательский опыт.
И, что самое главное: у нас своя команда юристов, которые сами работают в Doczilla и постоянно дают нам обратную связь, а также участвуют в выпуске новых фич.
Вовлеченность пользователей позволяет нашей команде не сбиться с пути при разработке продукта.
Итерации. Работа по этапам
Предположим, появилась потребность в новой функции. Наш дизайнер совместно с продакт-менеджером готовят макет, команда описывает пользовательский путь. При детальной проработке решения команда приходит к выводу, что у разработки данной фичи есть несколько этапов. Поэтому, чтобы не затягивать процесс и не упустить детали, принимаем решение выпускать фичу поэтапно.
Самое важно в этом подходе — уже с первой итерации мы выпускаем рабочее решение, пусть и не самое изящное.
Итерационный подход используется и тогда, когда выпущенная фича не соответствует ожиданиям пользователей. С каждой итерацией команда изменяет объем продукта. За это время любой член команды может придумать творческие альтернативы.
Итерации помогают команде изучить новые сценарии и определить следующие шаги.
Оценка результата
После того, как решение разработано и запущено, а результаты эксперимента проанализированы, команда оценивает, достигли ли мы целей, что мы узнали и что может быть полезно для нас самих.
Подобная оценка проводится не только после выпуска нового релиза, но и на регулярной основе по итогам каждого квартала. Анализ ошибок позволяет избежать их в будущем, а анализ побед дарит возможность делиться и радоваться успеху.
Оценка результата состоит из следующих блоков:
Метрики успеха
- Насколько у нас получилось достичь метрик успеха?
Ретроспектива
- Что получилось?
- Что не получилось и почему?
- Чему научились?
- Как это поможет нам в будущем?
Вывод
Мы в Doczilla используем продуктовый подход не только для развития продукта, но и в проектном менеджменте, маркетинге и других командах. Мы строим свою работу вокруг: «То, что мы делаем, должно приносить пользу».
У нас есть клиенты с конкретными сроками и ТЗ, но даже в таком случае мы стараемся не сбиваться с пути и ориентироваться на конечный результат, качество и ценность, хоть иногда это бывает непросто.
Надо сказать, что наш продуктовый подход все еще развивается и мы продолжаем проводить исследования о том, почему людям нужна Doczilla и какие задачи она может решать. Мы продолжаем выстраивать процессы внутри команды и внедряем новые подходы в разработке, проектировании, тестировании и поддержке.
Я уверена, что по мере того, как Doczilla будет расти, наше видение будет меняться, и мы обязательно поделимся новостями.