Что продакт менеджер должен знать об API?

Опытный продакт строит только то, что нужно, а для всего остального просит команду интегрироваться с готовыми API. Чтобы написать хорошие требования к продукту и понять предложения API других команд, продакт должен понимать структуру API: endpoint, input, output, errors.

API — это способ попросить систему выполнить за нас работу. Мы даем что-то на входе (input) и получаем ответ (output) на выходе. При этом нам совершенно все равно, что именно система делает для получения результатов — в этом вся суть.

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

Представим, что вы — продакт приложения для бегунов и хотите интегрировать прогноз погоды в приложение (не всем нравится бегать под дождем). Вы немного погуглили и нашли этот документ (платного) API погоды:

Что мы здесь сразу видим? Вы можете передать город (он у вас есть!), дату/время (они тоже есть) и получить температуру в градусах Цельсия, а также погодные условия. А еще:

— У пользователей будут проблемы в пригородах подальше от городов (поскольку API не поддерживает простые координаты, а только города).

— Температура указана только в градусах Цельсия (пострадают клиенты из США и прочих стран, где используют Фаренгейты). Поэтому надо будет добавить свой простой "переводчик" между температурами.

— Ничего не говорится о ветре (бегунам может быть некомфортно, если ветер будет сильнее определенного порога).

Этого достаточно, чтобы либо поставить команде задачу по интеграции с этим API, либо продолжить поиск и найти что-то еще. Обратите внимание, что мы, как продакты, сделали этот анализ всего за несколько минут, даже не поговорив с техническими специалистами!

Предположим, что мы хотим добавить в наше беговое приложение новую крутую фичу — маршруты для бегунов. Да, Google может построить маршрут для водителей и пешеходов, но бегунам нужно немного другое. Мы предполагаем, что пользователь может указать параметры тренировки и получить идеальный маршрут для пробежки. Запрашиваем у бэкенд команды следующий API:

Заметьте, как мы перешли от невнятного «маршрут для бегунов» к более конкретному соглашению по input / output. Это уже можно обсуждать с технической командой: смогут ли они это построить, чего не хватает и т.д.

Мы не упоминаем, как это будет реализовано: хитрым ML-ем или с помощью какого-то простого набора правил. Но мы четко говорим, что пользователи будут отправлять и что мы ожидаем в ответ — это хорошее ограничение для того, чтобы начать работу.

Продакт должен помнить следующее:

— API состоит из input & output (включая возможные ошибки).

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

— Если нужно выдать требования для других сервисов, вы можете сделать это в форме API input/output. Это применимо, если вы хотите предложить (или продать) часть своего функционала через API.

Хотите попробовать вызвать API своими руками? В реальности это проще, чем кажется. Ссылка на тренажер в первом комменте - без регистрации и СМС. Будет полезно любому IT-лидеру, которому хочется говорить с командой на одном языке.

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