[Api Как Продукт] Взаимодействие С Разработчиками И Бизнес-Аудиторией

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

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

(В идеале также с конечными пользователями, но этот вариант редко доступен для поставщиков API.) Начнем с разработчиков.

Специфика программистов как аудитории API заключается в том, что:

• разработчики – высокообразованные люди с практическим и прикладным рациональным мышлением; как правило, выбор товара у них осуществляется крайне рационально (если только вы не раздаете бесплатно рюкзаки с прикольной символикой вашей службы);
  • это не исключает определенного вкуса в выборе, скажем, языков программирования или производителей мобильных ОС; однако влияние эти вкусы чрезвычайно сложны и часто выходят за рамки возможностей провайдера API;
• в частности, разработчики скептически относятся к громким рекламным заявлениям и готовы понять, насколько эти заявления правдивы;
• крайне сложно выйти на разработчиков через стандартные маркетинговые каналы; помимо того, что они получают информацию преимущественно от узкоспециализированных сообществ, программисты также смотрят в первую очередь на мнения, подкрепленные конкретными цифрами и примерами (желательно примерами кода);
  • мнения «влиятельных лиц» в такой среде значат очень мало, поскольку ничьё мнение не принимается на веру;
• идеи Open Source и бесплатного ПО довольно широко распространены среди разработчиков; попытки заработать тем или иным способом на вещах, которые должны быть бесплатными и/или открытыми (например, путем лицензирования интеллектуальной собственности на интерфейсах) будут встречать сопротивление, а представления об этих «должнах» сильно различаются .

• коллективные блоги (например, субреддит «r/programming» или dev.to);
• сайты вопросов и ответов (Quora, StackOverflow);
• образовательные услуги (CodeAcademy, Udemy и другие);
• технические конференции и вебинары.

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

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

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

По опыту автора этой книги, для техноPR критически важны две вещи:

• стимулы, даже номинальные – работа по продвижению должна как-то вознаграждаться;
• Методичность и стандарты качества — просмотр презентаций так же важен, как и просмотр кода.

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

Над текстами нужно работать: следить за структурой, логикой и темпом повествования.

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

Особо следует упомянуть «евангелистов»: так называют людей, обычно обладающих определенным авторитетом в ИТ-сообществе, которые продвигают ту или иную технологию или компанию — то есть делают все вышеперечисленное (пишут блоги, записывают курсы, выступать на конференциях) для вас (чаще всего являющихся внештатными, а иногда и штатными сотрудниками компании).

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

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

(Это не означает отказа от евангелизации; вы можете объединить эти две стратегии.

)

Открытый источник

У этого действия есть как преимущества, так и недостатки:

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

код. Решение здесь следует принимать максимально взвешенно, взвесив все «за» и «против».

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

Фрагментация аудитории

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

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

Правильнее было бы сказать, что вы работаете на две основные аудитории:

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

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

Бытует мнение, что невозможно угодить обеим аудиториям одновременно: первые ищут возможности глубокой кастомизации (поскольку работают в крупных ИТ-компаниях с устоявшимся подходом к разработке), вторым нужен максимально низкий порог входа.

.

Мы склонны не согласиться с этим мнением по причинам, которые будут рассмотрены в главе «Линейка API-сервисов».

Взаимодействие с бизнес-аудиторией

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

В остальном API «продается», как и любое другое программное обеспечение.

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

Решить эту проблему должна помочь интенсивная работа с сообществом (см.

соответствующую главу), благодаря чему появляется много фрилансеров и аутсорсеров, готовых помочь неИТ-бизнесу с интеграцией.

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

То же самое касается исследований рынка и обратной связи.

Бизнесы, далекие от ИТ, как правило, не могут сформулировать свои потребности, поэтому им следует творчески (и критично) подходить к обработке полученной информации.

Теги: #api #Управление продуктом #взаимодействие с аудиторией

• Умные Теги? Кто Говорит, Что Они Умные?

  19 Oct, 24

• Заметки Разработчика Dynamics Gp: Ловкость Великих Равнин

  19 Oct, 24

• В Чем Разница Между Подержанными Компьютерами И Восстановленными Компьютерами

  19 Oct, 24

• Основные Характеристики Android-Планшета

  19 Oct, 24

• Исследование: На Что Тратят Электронные Деньги В России?

  19 Oct, 24

• «Ужасающая Правда О Работе В It-Компании»: Ограничение На Суши, Отсутствие Дедлайнов И Несвежая Газировка

  19 Oct, 24

• Выпущена Версия Gwt 2.1.1

  19 Oct, 24

• На Ноутбуках Samsung Обнаружен Кейлоггер, Вероятно, Установленный Производителем [Не Подтверждено]

  19 Oct, 24

• Краткий Обзор Современных Инструментов Для Начинающего Drupal-Разработчика

  19 Oct, 24

• Как Образуются Пробки

  19 Oct, 24