[Api] Формирование Видения Продукта

Это черновик третьей главы раздела «API как продукт».

моя книга о дизайне API. Описано в предыдущей главе фрагментация целевой аудитории API, триада «разработчики — бизнес — конечные пользователи», делает управление продуктами API весьма нетривиальной проблемой.

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

В целом продуктовое видение будущего API также должно включать в себя те же три звена:

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

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

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

• или на основе вашего понимания спектра доступных технических решений вы пытаетесь сформировать понимание того, как вы могли бы помочь бизнесу (первый шаг эвристики), а оттуда — общее представление о том, как ваш API будет помощь конечным пользователям (второй этап эвристики);
• или, исходя из вашего понимания задач, стоящих перед бизнес-партнерами, вы можете сделать «шаг вправо», обрисовав будущий функционал для конечных пользователей, и «шаг влево», рассмотрев возможные технические решения.

Здесь важно еще и то, что многие API проходят стадию «терраформирования» (см.

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

(Что, в свою очередь, отразится на моделях монетизации: по мере того, как форма будущего станет более детальной, вы будете переходить от все более абстрактных KPI и теоретических преимуществ наличия API ко все более конкретным.

) Эту же неопределенность следует учитывать при проведении интервью и сборе отзывов.

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

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

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

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

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

Тестирование гипотез по продукту

«Святой Грааль» управления продуктом — создание минимально жизнеспособного продукта (MVP), максимально дешевого с точки зрения затраченных ресурсов, — обычно недоступен API-менеджеру.

Дело в том, что ты не можешь просто проверять MVP, даже если вам удалось его разработать: для обзора MVP API партнеры должны написать код (читай – вложи свои деньги); Если по результатам этого эксперимента будет принято решение, что товар бесперспективен, эти деньги будут потрачены впустую.

Конечно, партнеры относятся к таким предложениям с некоторым скептицизмом.

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

помимо MVP API сразу разрабатывается и MVP приложения, использующего этот API).

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

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

Еще один вариант проверки гипотез — собственный сервис (или сервисы) разработчика API, если таковой имеется.

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

В целом концепция «ешь свою собственную тестовую версию» применительно к API означает, что команда разработчиков имеет несколько собственных тестовых приложений (так называемых «любимых проектов») поверх API. Учитывая трудоемкость разработки таких приложений, имеет смысл стимулировать их доступность, например, предоставляя членам команды бесплатные квоты на API и вычислительные ресурсы.

Такие любимые проекты также дают уникальный опыт: каждый может попробовать себя в новой роли.

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

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

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

Теги: #api #Управление продуктом #mvp #Продукт API

• Focuster — Список Дел, Который Автоматически Планирует Расписание Пользователя.

  19 Oct, 24

• 7 Примеров Использования Процедурной Генерации В Играх, О Которых Полезно Знать Всем Разработчикам

  19 Oct, 24

• Джемини Полетели На Орбиту?

  19 Oct, 24

• Lords Of Doom: Как Два Парня Создали Культовый Шутер И Всколыхнули Индустрию Видеоигр

  19 Oct, 24

• У Вас Есть Желание Поставить Много Минусов За Множество Глупых Комментариев.

  19 Oct, 24

• Проектирование Оконных Функций, Которые В Сумме Составляют Блок С Заданным Уровнем Перекрытия.

  19 Oct, 24

• Производительность Торговой Платформы На Простом Примере

  19 Oct, 24

• Spoj.pl - Попробуем Свои Силы!

  19 Oct, 24

• Батхерт Девелопмент: Как Победить?

  19 Oct, 24

• История Одной Технологии. Моб

  19 Oct, 24