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

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

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

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

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

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

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

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

Помещение технических продуктов в контекст

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

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

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

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

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

Создание внутренних продуктов

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

Эти решения не предназначены для коммерциализации (по крайней мере, не в первый момент) и будут использоваться командой, которая их разработала, или связанными сторонами, у которых есть такая потребность.

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

Понимание взаимодействий

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

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

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

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

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

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

Это означает думать о том, как продукт будет поддерживаться, как он будет документироваться и как он будет интегрирован с другими системами в компании.

Разработка решений для других компаний

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

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

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

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

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

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

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

Что я узнал

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

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

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

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

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

Документирование процесса зависит от каждого человека. Некоторые люди используют Notion, Trello, Mic или другие инструменты. Важно документировать таким образом, чтобы другие люди могли получить доступ и понять проведенное исследование. Во многих случаях больше людей, изучающих доказательства, могут сделать ценные выводы, которые ранее не осознавались.

Я надеюсь, что я помог в некотором роде.

Увидимся в следующем посте.

Хотите улучшить свои технические навыки управления продуктом БЕСПЛАТНО?

Не упустите шанс подписаться на The Technical Product Manager, бесплатный информационный бюллетень с высококачественным контентом, который поможет вам преуспеть в этой области.

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

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

НАЖМИТЕ ЗДЕСЬ: https://thetechpm.substack.com/subscribe?

Не упустите эту ценную возможность!

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