Как найти подходящего человека для обзора функций API?

Question

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

Это уже реализовано и задокументировано.

Но я не уверен, что это очень полезно, и документация очень понятна для разработчиков.

Как мы можем найти людей для проверки этой функции? Каким человеком это должно быть?

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

Answer 1

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

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

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

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

Answer 2

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

То, что ваши пользователи считают irelevent, я думаю, потому что вы не можете судить о фреймворке, спрашивая произвольного программиста об этом. Его ответ будет зависеть от его уровня знаний и личных методологий, в то время как API разрабатывается для более широкой аудитории (я предполагаю, что это ваш случай). Чтобы закончить этот вопрос, в моей фирме программисты, использующие VB.NET, думают, что C # - это слабый язык из-за «проблем», таких как вы не можете написать Button = "Text" в C #, и позволить компилятору автоматически найти свойство по умолчанию для вас. Вы не хотите, чтобы такой человек судил ваши рамки.

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

Answer 3

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

Если у вас нет такой аудитории (т. Е. Вы разрабатываете API для продукта, который еще не является публичным), я бы посоветовал провести некоторое «тестирование юзабилити» - то есть выбрать разработчика, обладающего навыками примерно целевой аудитории, и дать ему какое-то задание, связанное с использованием API. Тогда получите от него обратную связь.

Answer 4

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

Answer 5

Во-первых, если вы разрабатываете API для использования другими, я бы порекомендовал почитать книгу вроде: http://www.amazon.com/Framework-Design-Guidelines-Conventions-Development/dp/0321545613

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

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

Answer 6

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