Бриф на разработку приложения: шаблоны для автоматизации и стартапа

0

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

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

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

Почему не подходят универсальные опросники 

В интернете можно найти много универсальных опросников на разработку сайта. Там вы найдете вопросы о том, нужна ли вам страница “О компании”, будете ли размещать портфолио, нужен ли раздел “Наша команда” и подобное. Потенциальные клиенты, заходя на сайт, ожидают найти информацию об опыте компании, ее товарах и услугах, изучить отзывы. И владельцы сайтов создают контент, соответствующий их запросам.

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

В разработке индивидуального продукта не все так просто. Создаваемая программа может не иметь аналогов, и не существует никаких “ожидаемых” запросов. Или она имеет аналоги, но большое количество программ-близнецов не нужно пользователям, а значит должна быть “фишка” сервиса. Клиент может сразу знать в чем она заключается, а может еще не сформулировал и ожидает, что в этом ему поможет команда разработки.

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

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

Бриф на разработку приложения

Бриф на разработку индивидуального решения

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

1. Цель разработки 

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

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

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

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

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

3. Пробовали другие варианты решения этой проблемы? Почему не сработали? 

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

4. Имеются ли на рынке подобные сервисы? Что вам нравится/не нравится в этих программах? 

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

5. Что вы видите “фишкой” своего сервиса? 

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

6. Целевая аудитория сервиса. Для кого разрабатывается? 

Важно четко определить своего пользователя, так как в процессе разработки нужно учитывать именно его потребности. Если вы затрудняетесь в определении своей целевой аудитории, можете воспользоваться рекламным кабинетом Google AdWords. Подберите несколько сервисов-конкурентов, впишите в строку URL Landing page их сайты и вы узнаете демографические данные пользователей и устройства, которыми они пользуются. С помощью кабинета на Facebook вбейте в строку интересов название конкурента и перед вами окажется ценная информация — пол, семейное положение, уровень образования и т.д. его аудитории. Так вы сможете отследить совпадения характеристик аудитории, и это поможет вам ближе узнать своего клиента и сформулировать свою целевую аудиторию наиболее четко.

7. Планируется ли монетизация сервиса? Каким образом? Выбран ли платежный агрегатор? 

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

8. Имеется ли логотип, фирменные цвета? Если нет, нужна ли разработка логотипа?

Этот вопрос важен потому, что если логотип и фирменные цвета не определены, то:

  1. Эти работы нужно включить в смету;
  2. Или, если логотип разрабатывает сторонняя организация, то нужно учесть при планировании время ожидания;
  3. Дизайн сервиса отталкивается от лого, установленных цветов и шрифтов. Если начинать дизайн без них, то на него уйдет больше времени, чем если бы они были. Поэтому в этом случае оценка дизайна будет выше.

9. Есть ли пожелания/предпочтения по дизайну сервиса?  

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

10. Как планируете внедрять в работу (будет ли обучение сотрудников, нужно ли руководство пользователя)?

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

11. К какому времени вы хотите выпустить первую версию программы?

Информация о сроках нужна для планирования работ. Чтобы определить сколько и каких специалистов лучше задействовать. Высокая срочность может сказаться на стоимости работы.

12. По каким критериям вы определите, что разработка программы прошла успешно? 

Команда разработчиков сразу должна определить критерии, по которым будет тестировать результат. Ведь формально разработка может быть сделана, но она бесполезна, если не выполняется поставленная перед ней бизнес-цель. Сформулируйте измеримые и достижимые критерии. Условие “должно быть удобно пользователю” невозможно объективно оценить. Сформулируйте его так “Время на оформление заказа пользователем не должно превышать 1 минуты”.

13. Комментарий для команды разработчиков: 

 Дополнительная информация, которую вы считаете важной.

Резюме 

Надеемся, что эти вопросы помогут вам лучше сформулировать свою идею, а разработчикам её воплотить! 

В качестве бонуса оставляем ссылки на два брифа. Как пользоваться:

  1. Скопируйте документ,
  2. Ответьте на вопросы,
  3. Рассылайте потенциальным исполнителям.

Бриф для задачи на автоматизацию

Бриф для стартапа/сервиса

Чтобы отправим бриф для оценки нам, перейдите на страницу Оставить заявку , или напишите на почту: info@itbrick.ru.

Поделиться в соцсетях:
Понравилась статья?
Подпишись!
Полезные статьи в сфере разработки и маркетинга, рекомендации и лайфхаки от IT Brick. Не более 2-х писем в месяц.
Ваш email

Оставить комментарий

avatar
1000