mirror of
https://github.com/twirl/The-API-Book.git
synced 2025-03-17 20:42:26 +02:00
continue Section III
This commit is contained in:
Sergey Konstantinov
parent
72ff626ae8
commit
6883c6b84e
@ -6,22 +6,22 @@
|
||||
|
||||
2. API — это *очень специфический продукт*. Вы продаёте возможность некоторые действия выполнять автомизированно посредством написания кода, и этот факт накладывает большие ограничения на управление продуктом.
|
||||
|
||||
Для того, чтобы успешно распространять API, необходимо уметь отвечать именно на этот вопрос: почему ваши потребители предпочтут выполнять те или иные действия программно. Вопрос этот не праздный, поскольку, по опыту автора настоящей книги, именно отсутствие у руководителей продукта и маркетологов экспертизы в области работы с API и есть самая большая проблема развития продукта API. Конечный пользователь взаимодействует с каким-то решением, которое поверх вашего API написали разработчики, работающие на какой-то сторонний бизнес (причём иногда в цепочке между вами и конечным пользователем находится ещё и более одного разработчика).
|
||||
Для того, чтобы успешно распространять API, необходимо уметь отвечать именно на этот вопрос: почему ваши потребители предпочтут выполнять те или иные действия *программно*. Вопрос этот не праздный, поскольку, по опыту автора настоящей книги, именно отсутствие у руководителей продукта и маркетологов экспертизы в области работы с API и есть самая большая проблема развития продукта API. Конечный пользователь взаимодействует с каким-то решением, которое поверх вашего API написали разработчики, работающие на какой-то сторонний бизнес (причём иногда в цепочке между вами и конечным пользователем находится ещё и более одного разработчика).
|
||||
|
||||
С этой точки зрения целевая аудитория API — это некоторая пирамида, подобная пирамиде Маслоу:
|
||||
* вершиной пирамиды являются разработчики: именно они непосредственно работают с API, и они выбирают, какой из конкурирующих API им подходит;
|
||||
* средний ярус пирамиды — бизнес-заказчики; они строят продукт, опираясь на разработчиков;
|
||||
* наконец, основание пирамиды — пользователи; им важно решение их задач, и их обычно совершенно не интересует, каким образом оно достигается.
|
||||
* наконец, основание пирамиды — пользователи; в подавляющем большинстве случаев они не выбирают *технологию*, она их не интересует; пользователь выбирает из тех вариантов решения своих задач, которые предложит бизнес.
|
||||
|
||||
Непосредственный вывод из этой модели звучит так: в достоинствах вашего API в первую очередь необходимо убедить разработчиков; они, в свою очередь, примут решение о выборе технологии, ну а бизнес оттранслирует концепцию пользователям. Если руководителями продукта API являются бывшие или действующие разработчики, они зачастую склонны оценивать конкуренцию на рынке API именно в этом аспекте, и направлять основные усилия по продвижению продукта именно на аудиторию программистов.
|
||||
|
||||
«Постойте!» — воскликнет здесь внимательный читатель. Но ведь дела здесь обстоят с точностью до наборот:
|
||||
* разработчики, как правило, являются наёмными сотрудниками, выполняющими поставленные заказчиком задачи (и даже если мы говорим о каком-то разработчике-одиночке, он всё же выбирает API в интересах какого-либо проекта, т.е. выступает здесь как бизнес-заказчик для самого себя);
|
||||
* бизнес, в свою очередь, ставит задачи разработчикам не из чувства стиля и не из соображений красоты кода — заказчика интересует реализация конкретной функциональности, необходимой для решения задач пользователя;
|
||||
* наконец, пользователю совершенно не интересны проблемы и разработчиков, и бизнеса: он выбирает тот продукт, который ему нужен.
|
||||
* наконец, пользователь вообще не разбирается в технических аспектах решения: он выбирает тот продукт, который ему нужен, и требует наличия в нём определённой функциональности.
|
||||
|
||||
Получается, что на вершине пирамиды, таким образом, находится конечный пользователь: это его нам нужно убедить, что он хочет не какую попало кружку кофе, а именно приготовленную через наш API (и отдельный вопрос, как же мы будем доносить информацию о том, что за API работает под капотом, и почему пользователь должен своими деньгами проголосовать именно за наш API!); тогда бизнес поставит разработчику задачу интегрировать наш API, ну а разработчик уже никуда не денется и напишет код (что, кстати, означает, что вкладываться в читабельность и консистентность API не так уж и обязательно).
|
||||
|
||||
Истина, разумеется, лежит где-то посередине. В каких-то предметных областях и на каких-то рынках все решения принимаются разработчиками (например, какой фреймворк выбрать); в других областях и рынках конечно слово остаётся за бизнес-заказчиком и конечным пользователем. К тому же, многое зависит от конкурентной ситуации; новому игроку войти на рынок, например, мобильных операционных систем очень дорого и малоперспективно.
|
||||
Истина, разумеется, лежит где-то посередине. В каких-то предметных областях и на каких-то рынках все решения принимаются разработчиками (например, какой фреймворк выбрать); в других областях и рынках последнее слово остаётся за бизнес-заказчиком и конечным пользователем. К тому же, многое зависит от конкурентной ситуации; новому игроку войти на рынок, например, мобильных операционных систем очень дорого и малоперспективно.
|
||||
|
||||
Здесь и далее мы будем описывать некоторый «усреднённый» случай, в котором все три яруса пирамиды важны: и пользователи (которые выбирают качественный продукт), и бизнес (которому важны гарантии качества и стоимость разработки), и разработчики (которых интересует удобство работы с API и его функциональность).
|
||||
@ -0,0 +1,4 @@
|
||||
### Востребованность API
|
||||
|
||||
Описанная выше фрагментация целевой аудитории API, триада «разработчики — бизнес — конечные пользователи», делает управление продуктом API весьма нетривиальной проблемой. Да, базовый принцип — выяснить потребности аудитории и удовлетворить их — всё тот же; только аудиторий у вашего продукта три, причём их интересы далеко не всегда коррелируют. Из потребности конечного пользователя в качественном и недорогом кофе отнюдь не следует потребность бизнеса в API для работы с кофе-машинами.
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
### Бизнес-модели API
|
||||
|
||||
Как мы неоднократно упоминали в предыдущих разделах, предоставление некоторой функциональности посредством программируемых интерфесов — достаточно дорогое удовольствие. Для создания и поддержания API требуется соответствующий отдел разработки, и публикация API представляет собой принятие определённых обязательств по поддержке, от которых нельзя так просто отказаться. Возникает логичный вопрос, зачем и почему вообще предоставлять функциональность именно в виде API, т.е. продукта для программистов, вместо того, чтобы ограничиться продуктом для конечного потребителя. Рассмотрим здесь различные ситуации, когда публикация API может быть выгодна, а также соответствующие модели монетизации, прямой и косвенной. [В квадратных скобках будем приводить примеры подобных моделей применительно к нашему учебному примеру с API кофе-машин.]
|
||||
Как мы неоднократно упоминали в предыдущих разделах, предоставление некоторой функциональности посредством программируемых интерфесов — достаточно дорогое удовольствие. Для создания и поддержания API требуется соответствующий отдел разработки, и публикация API представляет собой принятие определённых обязательств по поддержке, от которых нельзя так просто отказаться. Возникает логичный вопрос, зачем и почему вообще предоставлять функциональность именно в виде API, т.е. продукта для программистов, вместо того, чтобы ограничиться продуктом для конечного потребителя. Рассмотрим здесь различные ситуации, в которых наличие API приносит выгоду компании, а также соответствующие модели монетизации, прямой и косвенной. [В квадратных скобках будем приводить примеры подобных моделей применительно к нашему учебному примеру с API кофе-машин.]
|
||||
|
||||
##### Разработчик = конечный пользователь
|
||||
|
||||
@ -37,7 +37,7 @@
|
||||
|
||||
Этот кейс — пожалуй что самый интересный с точки зрения разработчика API, поскольку существование программного интерфейса в этом случае действительно является мультипликатором возможностей: компания-владелец экспертизы чисто физически не может сама реализовать все на свете сервисы, эту экспертизу использующие. Предоставление API здесь является «win-win» стратегией: функциональность сторонних сервисов улучшается, а компания-провайдер зарабатывает на этом деньги.
|
||||
|
||||
Доступ к API в этом случае может быть безусловно платным, хотя чаще встречаются смешанные модели монетизации: API предоставляется бесплатно до достижения какого-то лимита либо при соблюдении определённых условий (например, для некоммерческих проектов). В отдельных случаях API является полностью бесплатным с целью популяризации определённой платформы, через которую он предоставляется (например, Apple Maps).
|
||||
Доступ к API в этом случае может быть безусловно платным, хотя чаще встречаются смешанные модели монетизации: API предоставляется бесплатно до достижения какого-то лимита либо при соблюдении определённых условий (например, для некоммерческих проектов). В отдельных случаях API предоставляется бесплатно с минимальными ограничениями с целью популяризации определённой платформы (например, Apple Maps).
|
||||
|
||||
Отдельно здесь следует отметить B2B-сервисы. Так как провайдеру сервиса выгодно дать клиенту как можно более разнообразные возможности, а клиенту, в свою очередь, часто требуется максимально гибко использовать имеющуюся функциональность, часто предоставление API — оптимальный выход для обеих сторон. Крупным компаниям, располагающим своими отделами разработки, чаще необходимо запрограммировать свои бизнес-процессы через API и интегрировать их со своими внутренними системами.
|
||||
|
||||
@ -70,12 +70,12 @@
|
||||
|
||||
### Подход API-first
|
||||
|
||||
В последние годы набирает силу тенденция предоставлять некоторую функциональность в виде API (т.е. продукта для разработчиков) там, где теоретически можно было бы предоставить сервис напрямую конечным пользователям. Этот подход известен как «API-first» и отражает нарастающую специализацию IT-сферы в целом: разработка API выделяется в отдельную компетенцию, которую бизнес готов отдавать сторонним компаниям вместо того, чтобы нанимать штат «универсальных солдат», которые могут разработать и приложение для конечного пользователя, и внутренний API для него. Тем не менее, пока этот подход не является универсально общепринятым, следует помнить о факторах принятия решений, когда можно запускать сервис в формате API-first:
|
||||
В последние годы набирает силу тенденция предоставлять некоторую функциональность в виде API (т.е. продукта для разработчиков) там, где теоретически можно было бы предоставить сервис напрямую конечным пользователям. Этот подход известен как «API-first» и отражает нарастающую специализацию IT-сферы в целом: разработка API выделяется в отдельную компетенцию, которую бизнес готов отдавать сторонним компаниям вместо того, чтобы нанимать штат «универсальных солдат», которые могут разработать и приложение для конечного пользователя, и внутренний API для него. Тем не менее, пока этот подход не является универсально общепринятым, следует помнить о факторах принятия решений, когда можно запускать сервис в формате API-first.
|
||||
|
||||
1. Целевой рынок должен быть достаточно «прогрет» — на нём уже должны действовать компании, обладающие достаточным ресурсом для разработки сервисов поверх вашего API, и готовых, к тому же, оплачивать его использование (если только вашей целью не является самореклама или улучшение климата);
|
||||
1. Целевой рынок должен быть достаточно «прогрет» — на нём уже должны действовать компании, обладающие достаточным ресурсом для разработки сервисов поверх вашего API, и готовых, к тому же, оплачивать его использование (если только вашей целью не является самореклама или улучшение климата);
|
||||
|
||||
2. Качество сервиса не должно страдать от того, что он предоставляется через API;
|
||||
2. Качество сервиса не должно страдать от того, что он предоставляется через API;
|
||||
|
||||
3. Необходимо реально обладать пресловутой экспертизой в разработке API, иначе велик шанс наделать неисправимых ошибок.
|
||||
3. Необходимо реально обладать пресловутой экспертизой в разработке API, иначе велик шанс наделать неисправимых ошибок.
|
||||
|
||||
Иногда раздача API является своеобразным «прощупыванием почвы» для того, чтобы компания-разработчик могла оценить рынок и решить, стоит ли выводить на него полноценный пользователский сервис (мы такую практику скорее осуждаем, поскольку она неизбежно приведёт к закрытию API в будущем: либо потому, что рынок оказался не столь привлекателен, как казалось априори; либо потому, что API начнёт создавать конкуренцию материнскому сервису и будет со временем закрыт или существенно ограничен).
|
||||
@ -1,4 +1,6 @@
|
||||
Специфика пользователей API заключается в том, что:
|
||||
### Взаимодействие с разработчиками
|
||||
|
||||
Специфика аудтории API заключается в том, что:
|
||||
|
||||
* разработчики — высокообразованные люди с практически-прикладным рациональным мышлением; как правило, выбор продукта ими осуществляется предельно рационально (это не исключает определённой вкусовщины в части выбора, скажем, языков программирования или вендоров программного обеспечения; однако *повлиять* на эти вкусы практически невозможно);
|
||||
|
||||
@ -16,4 +18,20 @@
|
||||
* профессиональных программистов, имеющих широкий опыт интеграции различного рода систем;
|
||||
* начинающих и полупрофессиональных разработчиков, для которых каждая такого рода интеграция является новой и неизведанной территорией.
|
||||
|
||||
Существует мнение, что угодить одновременно обеим аудиториям невозможно: первые ищут возможности глубокой кастомизации (поскольку работают в крупных ИТ-компаниях со сложившимся подходом к разработке), вторым необходим максимально заниженный порог входа. Мы с этим мнением склонны не согласиться по причинам, описанным в следующей главе.
|
||||
Существует мнение, что угодить одновременно обеим аудиториям невозможно: первые ищут возможности глубокой кастомизации (поскольку работают в крупных ИТ-компаниях со сложившимся подходом к разработке), вторым необходим максимально заниженный порог входа. Мы с этим мнением склонны не согласиться по причинам, описанным в следующей главе.
|
||||
|
||||
В силу описанных выше причин (низкая роль инфлюэнсеров, критическое отношение к рекламным заявлениям) доносить информацию до разработчиков приходится через специфические каналы:
|
||||
* коллективные блоги (такие, например, как субреддит ‘programming’ или dev.to);
|
||||
* сайты вопросов и ответов (Quora, StackOverflow);
|
||||
* обучающие сервисы типа CodeAcademy или Udemy;
|
||||
* технические конференции и вебинары.
|
||||
|
||||
Во всех этих каналах прямая реклама вашего сервиса затруднена или невозможна вовсе. Вам необходимо генерировать какой-то ценный и/или интересный контент для улучшения знания о вашем API, и эта работа тоже ложится на ваших разработчиков: писать тексты, отвечать на вопросы, записывать обучающие семинары, выступать с докладами.
|
||||
|
||||
Программисты любят делиться опытом, и с удовольствием будут заниматься всеми вышеперечисленными задачами (в рабочее время); однако хорошее выступление на конференции, не говоря уже об обучающем курсе, требует многих часов подготовки. По опыту автора настоящей книги две вещи критически важны для качественного технопиара:
|
||||
* поощрения, пусть даже номинальные — работа по продвижению должна как-то вознаграждаться;
|
||||
* методичность и стандарты качества.
|
||||
|
||||
Почти ничто не сделает вам худшей антирекламы, нежели плохо подготовленное выступление (см. выше — ошибки в вашей презентации непременно найдут) или плохо замаскированная реклама (по той же причине). Над текстами надо работать: следить за структурой, логикой и темпом повествования. И технический рассказ должен быть хорошо выстроен; по его окончании у слушателей должно сложиться чёткое понимание того, какую мысль им хотели донести (и хорошо бы эта мысль была как-то увязана с тем, что ваш API великолепно подходит для их нужд).
|
||||
|
||||
Отдельно следует упомянуть о «евангелистах»: так называют людей, обычно, обладающих определённым авторитетом в ИТ-сообществе, которые продвигают ту или иную технологию или компанию — то есть делают всё вышеперечеисленное (пишут в блоги, записывают курсы, выступают на конференциях) за вас (чаще всего будучи внештатными, а иногда и штатными сотрудниками компании). Евангелист, таким образом, разгружает команду от необходимости заниматься технопиаром. Мы же всё-таки склонны считать, что эту функцию лучше иметь внутри команды, поскольку прямое взаимодействие с разработчиками чрезвычайно полезно для понимая состояния продукта.
|
||||
@ -0,0 +1,11 @@
|
||||
### Взаимодействие с бизнес-аудиторией
|
||||
|
||||
Основные принципы работы с партнёрами несколько парадоксально полностью противоположны принципам взаимодействия с разработчиками:
|
||||
* с одной стороны, партнёры гораздо более лояльно и зачастую даже с энтузиазмом относятся к предлагаемым им возможностям, особенно бесплатным;
|
||||
* с другой стороны, донести до бизнес-аудитории смысл вашего предложения несравненно сложнее, чем до разработчиков, так как представителям бизнеса в целом гораздо сложнее объяснить, в чём вообще состоят преимущества API (как концепции) по сравнению с сервисом для конечных пользователей.
|
||||
|
||||
Как итог, работа с бизнес-аудиторией в первую очередь сводится к тому, чтобы максимально доходчиво объяснить свойства и преимущества продукта. В остальных же смыслах API «продаётся» как и любое другое программное обеспечение.
|
||||
|
||||
Как правило, чем дальше некоторая отрасль находится от информационных технологий, тем с большим энтузиазмом её представители воспринимают рекламу возможностей API, и тем менее вероянто, что этот энтузиазм будет сконвертирован в реальную интеграцию. Помочь этой проблеме должна интенсивная работа с комьюнити (см. соответствующую главу), благодаря которой появляется множество фрилансеров и аутсорсеров, готовых помочь не-ИТ бизнесам с интеграцией.
|
||||
|
||||
Аналогичным образом обстоит дело и с исследованиями рынка и получением обратной связи. Далёкие от ИТ бизнесы как правило не могут сформулировать свои потребности, поэтому к обработке полученных сведений следует подходить творчески (и критически).
|
||||
@ -1,11 +1,27 @@
|
||||
### Линейка сервисов API
|
||||
|
||||
Описанная в предыдущей главе фрагментация пользователей API по профессиональному уровню имеет несколько важнейших следствий, которые необходимо учитывать при разработке:
|
||||
Первое правило управления продуктом API, которое любой достаточно крупный поставщик API довольно быстро для себя откроет, звучит так: нет смысла поставлять всего лишь один какой-то API; есть смысл говорить о наборе продуктов, причём в двух измерениях.
|
||||
|
||||
#### Горизонтальное разделение сервисов API
|
||||
|
||||
Как правило, любая функциональность, предоставляемая через API, делиться на независимые блоки. Например, в нашем кофейном API есть функциональность поиска предложений и функциональность заказа кофе. Ничто не мешает нам как объявить эти эндпойнты разными API, так и считать их частями одного общего API.
|
||||
|
||||
Разные компании используеют разные подходы к определению гранулярности сервисов API, что считать отдельным продуктом, а что нет; это до определённой степени вопрос вкусовщины и удобства. Стоит задуматься о разделении API на части, если:
|
||||
* интеграция только с одной из частей имеет смысл, т.е. подсемейство API само по себе решает какую-то проблему пользователя без привлечения других API;
|
||||
* части API могут версионироваться отдельно и независимо, и это осмысленно с точки зрения разработчика (обычно в таких ситуациях «отделившиеся» API должны максимально поддерживать обратную совместимость и выпускать новые мажорные версии только в случае крайней необходимости, иначе поддержание в актуальном виде таблицы, какая версия API №1 совместима с какой версией API №2, быстро превратится в катастрофу);
|
||||
* имеет смысл тарифицировать и устанавливать раздельные лимиты на каждый из сервисов по отдельности;
|
||||
* аудитории различных сегментов API (разработчики, бизнес или конечные пользователи) не пересекаются, и «продать» гранулярное API потребителю проще, чем целый комбайн в нагрузку.
|
||||
|
||||
**NB**: при этом раздельные API могут предоставляться в рамках одного SDK, для удобства клиентской разработки.
|
||||
|
||||
#### Вертикальное разделение сервисов API
|
||||
|
||||
Часто, однако, имеет смысл предоставлять несколько сервисов API, оперирующих одной и той же функциональностью. Дело в том, что описанная в предыдущей главе фрагментация пользователей API по профессиональному уровню имеет несколько важных следствий:
|
||||
* практически невозможно в рамках одного продукта создать такой API, который одинаково хорошо подходит и начинающим разработчикам, и профессионалам; первым необходима максимальная простота реализации базовых сценариев использования API, вторым — возможность адаптировать использование API под конкретный стек технологий и парадигму разработки, и стоящие перед ними задачи, как правило, требуют глубокой кастомизации;
|
||||
* абсолютное большинство нагрузки на вашу техническую поддержку будет создавать первая категория: начинающим разработчикам гораздо сложнее найти ответы на свои вопросы или разобраться в проблеме самостоятельно, и они будут задавать их вам;
|
||||
* при этом вторая категория потребителей будет гораздо более требовательна к качеству как продукта, так и поддержки; при этом удовлетворить их запросы будет крайне нетривиально.
|
||||
* при этом вторая категория потребителей будет гораздо более требовательна к качеству как продукта, так и поддержки, и при этом удовлетворить их запросы будет крайне нетривиально.
|
||||
|
||||
Самый важный вывод здесь такой: максимально полно покрыть нужды всех категорий пользователей можно только разработав *семейство API*, т.е. множество продуктов с разным порогом входа и требовательностью к профессиональному уровню программиста. Можно выделить следующие подвиды API, по убыванию требуемого уровня разработчиков.
|
||||
Самый важный вывод здесь такой: максимально полно покрыть нужды всех категорий пользователей можно только разработав множество продуктов с разным порогом входа и требовательностью к профессиональному уровню программиста. Можно выделить следующие подвиды API, по убыванию требуемого уровня разработчиков.
|
||||
1. Самый сложный уровень — физического API и семейства абстракций над ними. [В нашем кофейном примере — та часть интерфейсов, которая описывает работу с физическим API кофе машин, см. [главу 9](#chapter-9) и [главу 17](#chapter-17).]
|
||||
2. Базовый уровень — работы с продуктовыми сущностями посредством формальных интерфейсов. [В случае нашего учебного API этому уровню соответствует HTTP API заказа.]
|
||||
3. Упростить работу с продуктовыми сущностями можно, предоставив SDK для различных платформ, скрывающие под собой сложности работы с формальными интерфейсами и адаптирующие концепции API под соответствующие парадигмы (что позволяет разработчикам, знакомым только с конкретной платформой, не тратить время и не разбираться в формальных интерфейсах и протоколах.)
|
||||
@ -21,6 +37,6 @@
|
||||
4. Кодогенерация позволяет вам манипулировать желательным видом приложений. Например, если для вас важным показателем является количество поисков через сторонние приложения, вы можете добавить в генерированный код показ панели поиска на видном месте; пользователи, прибегающие к помощи генератора кода, как правило, не меняют сгенерированный результат.
|
||||
5. Наконец, готовые компоненты и виджеты находятся полностью под вашим контролем, и вы можете экспериментировать с доступной через них функциональностью так же свободно, как если бы это было ваше собственное приложение. (Здесь следует, правда, отметить, что не всегда от этого контроля есть толк: например, если вы позволяете вставлять изображение по прямому URL, ваш контроль над этой интеграцией практически отсутствует; при прочих равных следует выбирать тот вид интеграции, который позволяет получить больший контроль над соответствущей функциональностью в приложении партнёра.)
|
||||
|
||||
**NB**. При разработке семейства API замечания, описанные в главе [«О ватерлинии айсберга»](#chapter-14) особенно важны. Вы можете свободно манипулировать контентом и поведением виджета, если и только если у разработчика нет способа «сбежать из песочницы», т.е. напрямую получить низкоуровневый доступ к объектам внутри виджета.
|
||||
**NB**. При разработке «вертикального» семейства API замечания, описанные в главе [«О ватерлинии айсберга»](#chapter-14) особенно важны. Вы можете свободно манипулировать контентом и поведением виджета, если и только если у разработчика нет способа «сбежать из песочницы», т.е. напрямую получить низкоуровневый доступ к объектам внутри виджета.
|
||||
|
||||
Как правило, вы должны стремиться к тому, чтобы каждый партнёрский сервис использовал тот вид API, который вам как разработчику наиболее выгоден. Там, где партнёр не стремится создать какую-то уникальную функциональность и размещает типовое решение, вам выгодно иметь виджет, который полностью находится под вашим контролем и, с одной стороны, снимает с вас головную боль относительно обновления версий API, и, с другой стороны, даёт вам свободу экспериментировать с внешим видом и поведением интеграций с целью оптимизации ваших KPI. Там, где партнёр обладает экспертизой и желанием разработать какой-то уникальный сервис поверх вашего API, вам выгодно предоставить ему максимальную свободу действий, чтобы, во-первых, покрыть тем самым уникальные продуктовые ниши, и, во-вторых, обладать конкурентным преимуществом в виде возможности глубокой кастомизации относительно других API на рынке.
|
||||
@ -24,4 +24,9 @@
|
||||
* если API приводит пользователя на сайт материнского сервиса — считать переходы;
|
||||
* если API используется для сбора обратной связи и UGC — считать оставленные отзывы и исправления.
|
||||
|
||||
Наиболее непростая ситуация с KPI наблюдается, если API в первую очередь способ (техно)пиара и (техно)маркетинга. В этом случае наблюдается накопительный эффект: наращивание аудитории не конвертируется в пользу компании моментально. *Сначала* вы набираете большую лояльную аудиторию разработчиков, *потом* репутация вашей компании улучшается, и ещё более потом эта репутация начинает играть вам на руку при найме. *Сначала* логотип вашей компании появляется на сторонних сайтах и приложениях, *потом* top-of-mind знание бренда увеличится. Нет прямого способа отследить, как то или иное действие (например, релиз новой версии или проведение мероприятия) сказывается на целевых показателях. В этом случае приходится оперировать косвенными показателями — посещаемость ресурсов для разработчиков, количество упоминаний в тематических сообществах и т.п.
|
||||
Наиболее непростая ситуация с KPI наблюдается, если API в первую очередь способ (техно)пиара и (техно)маркетинга. В этом случае наблюдается накопительный эффект: наращивание аудитории не конвертируется в пользу компании моментально. *Сначала* вы набираете большую лояльную аудиторию разработчиков, *потом* репутация вашей компании улучшается, и ещё более потом эта репутация начинает играть вам на руку при найме. *Сначала* логотип вашей компании появляется на сторонних сайтах и приложениях, *потом* top-of-mind знание бренда увеличится. Нет прямого способа отследить, как то или иное действие (например, релиз новой версии или проведение мероприятия) сказывается на целевых показателях. В этом случае приходится оперировать косвенными показателями — посещаемость ресурсов для разработчиков, количество упоминаний в тематических сообществах, помещаемость блогов и мероприятий и т.п.
|
||||
|
||||
Кратко суммируем вышесказанное:
|
||||
* считать прямые показатели, такие как общее число пользователей и партнёров, — гигиенический минимум, без которого сложно двигаться дальше, но это не KPI;
|
||||
* KPI для продукта API должен выставлять исходя из количества целевых действий, которые производятся через платформу;
|
||||
* определение «целевых действий» зависит от модели монетизации и может быть как прямолинейным «количество платящих клиентов» или «количество кликов по рекламе», так и достаточно опосредованным и эвристическим типа «количество посетителей блога команды разработки».
|
||||
@ -7,13 +7,13 @@
|
||||
|
||||
И тех, и других в большинстве случаев необходимо уметь идентифицировать, т.е. иметь ответы на следующие вопросы:
|
||||
|
||||
* сколько пользователей взаимодействуют с системой (одновременно, в течение дня, месяца, года)
|
||||
* сколько пользователей взаимодействуют с системой (одновременно, в течение дня, месяца, года);
|
||||
* какое количество действий совершает каждый пользователь.
|
||||
|
||||
Обладать этой информацией критически важно по двум основным причинам:
|
||||
|
||||
* чтобы понимать пределы прочности системы и уметь планировать её развитие;
|
||||
* чтобы понимать количество ресурсов (в пределе — денег), расходуемых на каждого пользователя.
|
||||
* чтобы понимать количество ресурсов (в пределе — денег), расходуемых (и зарабатываемых) на каждого пользователя.
|
||||
|
||||
В случае коммерческих API точность и своевременность сбора этой информации важна вдвойне, поскольку от неё напрямую зависит биллинг; поэтому вопрос *как* мы идентифицируем пользователей — отнюдь не праздный.
|
||||
|
||||
@ -33,14 +33,12 @@
|
||||
|
||||
Другая опасность заключается в том, что ключ могут банально украсть у добросовестного партнёра. В случае клиентских и веб-приложений это довольно тривиально; в случае серверных приложений проблема стоит гораздо менее остро, но популярный API рано или поздно столкнётся с тем, что украденные ключи будут выложены в свободный доступ (или владелец ключа просто будет делиться им со знакомыми по доброте душевной).
|
||||
|
||||
Мобильные приложения удобно отслеживаются по идентификатору приложения в соответствуюем сторе (Google Play, App Store и другие), поэтому разумно требовать от партнёров идентифицировать приложение при подключении API.
|
||||
|
||||
Другая опасность заключается в том, что ключ могут банально украсть у добросовестного партнёра. В случае клиентских и веб-приложений это довольно тривиально. К тому же ключи могут украсть и выложить в свободный доступ (или владелец ключа просто будет делиться им со знакомыми по доброте душевной).
|
||||
|
||||
Может показаться, что в случае предоставления серверных API проблема воровства ключей неактуальна, но, на самом деле, это не так. Предположим, что партнёр предоставляет свой собственный публичный сервис, который «под капотом» использует ваше API. Это часто означает, что в сервисе партнёра есть эндпойнт, предназначенный для конечных пользователей, который внутри делает запрос к API и возвращает результат, и этот эндпойнт может использоваться злоумышленником как эквивалент API. Конечно, можно объявить такой фрод проблемой партнёра, однако было бы, во-первых, наивно ожидать от каждого партнёра реализации собственной антифрод-системы, которая позволит выявлять таких недобросовестных пользователей, и, во-вторых, это попросту неэффективно: очевидно, что централизованная система борьбы с фродерами всегда будет более эффективной, нежели множество частных любительских реализаций.
|
||||
|
||||
Так или иначе, встаёт вопрос независимой валидации: каким образом можно проконтролировать, действительно ли API используется конечным потребителем в соответствии с пользовательским соглашением.
|
||||
|
||||
Мобильные приложения удобно отслеживаются по идентификатору приложения в соответствуюем сторе (Google Play, App Store и другие), поэтому разумно требовать от партнёров идентифицировать приложение при подключении API.
|
||||
|
||||
#### Идентификация конечных пользователей
|
||||
|
||||
Если к партнёрам вы можете предъявлять какие-то требования по самоидентификации, то от конечных пользователей требовать раскрытия информации о себе в большинстве случаев не представляется возможным. Поэтому все методы контроля, описанные ниже, являются неточными и зачастую эвристическими. Кроме того, следует иметь в виду, что сбор подобного рода информации может регулироваться законодательно (хотя большей частью речь пойдёт об анонимизированных данных, но и они могут быть регламентированы).
|
||||
|
||||
@ -38,9 +38,11 @@
|
||||
* how-to
|
||||
* примеры
|
||||
* песочница
|
||||
* Тестирование
|
||||
* Промис поддержки платформ
|
||||
* Поддержка пользователей
|
||||
* форумы
|
||||
* поддержка разработчиков
|
||||
* работа с комьюнити
|
||||
* обратная связь
|
||||
* обратная связь (глубина использования фич)
|
||||
* Продуктовое управление разработкой API
|
||||
35
src/ru/drafts/04-Раздел III. API как продукт/Поддержка.md
Normal file
35
src/ru/drafts/04-Раздел III. API как продукт/Поддержка.md
Normal file
@ -0,0 +1,35 @@
|
||||
### Поддержка пользователей API
|
||||
|
||||
Прежде всего сделаем важную оговорку: когда мы говорим о поддержке пользователей API, мы имеем в виду поддержку разработчиков и отчасти бизнес-партнёров. Конечные пользователи, как правило, напрямую с API не взаимодействуют, за исключением некоторых нестандартных сценариев.
|
||||
|
||||
1. Если до партнёров, использующих API, невозможно «достучаться» по иным каналам, и приходится отображать в их приложениях видимую конечным пользователям ошибку. Такое случается, если в фазе роста API предоставлялся бесплатно и с минимальными требованиями по идентфикации партнёров, и позднее условия изменились (популярная версия API перестала поддерживаться или стала платной).
|
||||
|
||||
2. Если разработчик API не может самостоятельно воспроизвести некоторую проблему, и вынужден обращаться напрямую к конечному пользователю с целью сбора обратной связи.
|
||||
|
||||
3. Если через API осуществляется сбор UGC-контента.
|
||||
|
||||
Первые два сценария по сути представляют собой ошибки продуктового или технического развития API, и их желательно не допускать. Третий сценарий не имеет особенной API-специфики, он по факту мало отличается от поддержки пользователей на основном UGC-сервисе. Поддержку же собственно API можно разделить на два больших раздела:
|
||||
* юридическая и организационная поддержка по вопросам условий использования и SLA сервиса (здесь скорее речь идёт об ответах на вопросы бизнес-партнёров);
|
||||
* поддержка разработчиков по возникающим техническим вопросам.
|
||||
|
||||
Первый раздел, несомненно, критически важен для любого здорового продукта (включая API), но вновь не содержит в себе какой-то особенной специфики. С точки зрения содержания настоящей книги нас гораздо больше интересует второй раздел, поскольку здесь специфика имеется.
|
||||
|
||||
Поскольку API — программный продукт, разработчики фактически будут задавать вопросы о работе того или иного фрагмента кода, который они пишут. Этот факт сам по себе задирает планку требований к качеству специалистов поддержки до очень высокого уровня, поскольку прочитать код и понять причину проблемы может только разработчик же. Но это полбеды: другая сторона проблемы заключается в том, что, как мы упоминали в предыдущей главе, львиная доля этих запросов будет задана неопытными или непрофессиональными разработчиками, что в случае любого сколько-нибудь популярного API приводит к тому, что 9 из 10 запросов *будут вовсе не про работу API*. Начинающие разработчики плохо владеют языком, обладают фрагментарными знаниями об устройстве платформы и не умеют правильно формулировать свои проблемы (и как следствие не могут поискать ответ на свой вопрос в Интернете перед тем; хотя, будем честны, в большинстве случаев даже и не пробуют).
|
||||
|
||||
Вариантов работы с такими обращениями может быть несколько.
|
||||
|
||||
1. Наиболее дружелюбный сценарий — набор людей с базовыми техническими навыками в первую линию поддержки. Эти сотрудники должны достаточно хорошо разбираться в механике работы API, чтобы опознавать непрофильные вопросы и отвечать на них по FAQ или переадресовывать вовне, если это требуется (например, в техподдержку платформы или комьюнити языка), и перенаправлять действительно релевантные вопросы разработчикам API.
|
||||
|
||||
2. Обратный сценарий — когда техподдержка предоставляется только на платной основе, и на вопросы отвечают непосредственно разработчики; пусть на качество и релевантность запросов такая модель не оказывает большого влияния (вашим API продолжают пользоваться, в основном, новички; вы лишь отсекаете тех из них, у кого нет денег на платную поддержку), но, по крайней мере, вы не будете испытывать проблем с наймом, поскольку сможете позволить себе роскошь поставить технического специалиста на первую линию поддержки.
|
||||
|
||||
3. Частично или полностью проблему с поддержкой новичков может снять развитое комьюнити (см. соответствующую главу). Как правило, члены комьюнити в состоянии ответить на вопросы новичков, особенно если им активно помогают модераторы.
|
||||
|
||||
Важный момент заключается в том, что, какой вариант оказания техподдержки вы ни выберете, финально на вопросы пользователей придётся отвечать разработчикам API просто в силу того факта, что полноценно разобраться в коде партнёра может только программист. Из этого факта следуют два важных вывода:
|
||||
|
||||
1. Время на оказание технической поддержки необходимо закладывать при планировании. Чтение совершенно незнакомого кода и удалённая его отладка — крайне сложная и отнимающая большое количество времени задача. Чем больше функциональности вы публикуете и чем больше платформ поддерживаете, тем выше будет нагрузка на команду разработки в части разбора обращений.
|
||||
|
||||
2. При этом программисты, как правило, не испытывают никакого восторга, занимаясь разбором обращений. Фильтр в лице первой линии поддержки всё равно не спасает от дилетантских и/или плохо сформулированных вопросов, что вызывает заметное раздражение дежурных разработчиков API. Выходов из этой ситуации несколько:
|
||||
* по возможности старайтесь найти людей, которым по складу ума нравится заниматься такой деятельностью, и поощряйте их заниматься поддержкой (в т.ч. материально); это может быть кто-то из команды (причём вовсе не обязательно разработчик) или кто-то из активных членов комьюнити;
|
||||
* остаточная нагрузка на команду должна быть распределена максимально равномерно и честно, вплоть до введения календаря дежурств.
|
||||
|
||||
Разумеется, полезным упражнением будет анализ вопросов и ответов с целью дополнения FAQ-ов, внесения изменений в документацию и скрипты работы первой линии поддержки.
|
||||
5
src/ru/drafts/04-Раздел III. API как продукт/Фрод.md
Normal file
5
src/ru/drafts/04-Раздел III. API как продукт/Фрод.md
Normal file
@ -0,0 +1,5 @@
|
||||
### Фрод
|
||||
|
||||
Фрод (т.е. использование API в нарушение пользовательского соглашения, как правло, для получения какой-то выгоды) можно условно поделить на две категории:
|
||||
* использование различных ухищрений для обхода ограничений на использования API;
|
||||
* использвоание уязвимостей API для несанкционированного доступа к конечным пользователям и/или их данным или ИТ-инфраструктуре самой компании-разработчика API.
|
||||
Loading…
x
Reference in New Issue
Block a user