бриф на разработку приложения для android ios
Мы сделали чек-лист для идеального брифа на разработку MVP
Собираетесь создать мобильное приложение или MVP и думаете, что бриф для разработчика — всего лишь формальность? Будьте готовы потерять деньги и время.
Мы разработали чек-лист и удобный шаблон, который поможет быстро и эффективно выбирать исполнителей, а также сразу выделять сильные стороны продукта для грамотного MVP.
Привет! Меня зовут Ринат, я основатель NoCode-студии Zero To One. Общаясь с клиентами, которые только выбирают себе подрядчика, я часто замечаю, что они пренебрегают брифом и считают важным только ТЗ.
Оно и понятно, ведь ТЗ составляется уже после подписания договора и включает в себя все технические тонкости и особенности проекта.
Бриф же помогает исполнителю ознакомиться с задачей, оценить сроки. Позволяет понять, сколько стоит создать такое мобильное приложение или сайт, и прикинуть возможные инструменты для разработки.
Пренебрегая брифом, многие тратят в два раза больше времени, денег и нервов только на начальном этапе работы.
Специально для предпринимателей, которые хотят разработать мобильное приложение или выпустить MVP быстро и качественно, я написал чек-лист идеального брифа. А на у нас на сайте можно скачать готовый шаблон, который сразу можно заполнять и присылать в студии. Особенно он подойдет, если вы выбираете NoCode разработку.
Итак, как выглядит идеальный бриф на разработку продукта:
Самый очевидный и самый обязательный момент в брифе. Важно дать студии понять, на какие сроки вы рассчитываете, чтобы они могли сразу сориентироваться по собственным возможностям и загруженности. Напишите, когда вы хотите приступать к работе и в какие сроки приложение должно быть реализовано.
Это также поможет избежать дискоммуникации, если подрядчик затянет со сроками — вы сразу обозначили допустимые временные рамки, а значит соглашаясь на них, подрядчик подтверждает, что выполнит работу в срок, если не оговорено иного.
Нет, это не значит, что ребятам из студий разработки просто лень читать. Краткость нужна здесь в первую очередь для того, чтобы вы выделили главные УТП вашего продукта, не растекаясь мыслью по древу. Когда количество текста ограничено, невольно постараешься рассказать о самых важных вещах. Вот они то и нужны вашим разработчикам.
Приложение для чтения и прослушивания книг, у которого синхронизируются печатная и аудиоверсии. То есть закончив слушать книгу, вы можете продолжить ее читать с того же места.
В этом пункте необходимо пояснить, зачем вы вообще собрались разрабатывать продукт. От этого зависит результат, который вы получите на выходе, а также ясность коммуникации с исполнителем.
Объясните, зачем вы обращаетесь к студии, чего ждете на выходе.
Например, вы хотите создать мобильное приложение или MVP продукта, проверить, насколько он нужен на рынке. Для этого отлично подойдет NoCode разработка, и в этом случае не придется тратить время и деньги на написание кода, углубляться в детали. Можете прописать конкретные гипотезы, чтобы исполнители могли сразу сориентироваться, какие инструменты для этого понадобятся.
Если же у вас есть существующий бизнес и вы хотите автоматизировать в нем процессы, пропишите, какие метрики вы хотите улучшить и на сколько. Так, узнав стоимость разработки, вы сможете просчитать окупаемость этих инвестиций. А специалисты, которые будут работать над проектом, будут понимать, что и зачем они делают.
Вот что должно получится:
У меня есть служба доставки еды. Я хочу разработать мобильное приложение чтобы:
1. Увеличить LTV и перенаправлять людей с сайта в приложение.
2. Выйти в новые каналы и использовать новые воронки
3. Создать стабильный канал коммуникации с клиентами
С этой информацией студия сможет предложить лучшие пути решения.
Далее нужно указать, есть ли у вас дизайн (макет, бренд бук или пожелания в визуальном плане) или его нужно разработать. Если дизайна нет, но есть задумки — поделитесь пожеланиями. Дополнительным плюсом будут референсы — поищите сайты/приложения, дизайн которых вам нравится. Приложите ссылки и расскажите, что именно вам импонирует.
Далее напишите, какие технологии вы хотите использовать.
Например, вы можете описать необходимые вам для интеграции программы/сервисы, или просто указать, что хотели бы использовать NoCode разработку или обычный код.
Если же предпочтений и идей нет — просто оставьте поле пустым. В конце концов, вы обращаетесь к специалистам, чтобы не думать о сложном 🙂
В этом пункте нужно будет вспомнить портреты всех сегментов вашей аудитории, их боли и как следует их описать. Это нужно, чтобы оптимизировать будущий продукт и работать над действительно нужными функциями.
По нашему опыту, половина планируемого функционала пользователю оказываются не нужны и просто тратят деньги бизнеса.
Если планируется создавать первую версию продукта, то в ней должно быть самое ценное. С помощью этого этапа вы сможете помочь в первую очередь себе, как основателю продукта. Понять что важно делать, а что можно отложить в следующую версию.
Воспользуйтесь форматом сценариев. Забудьте о кнопочках и экранах, представьте каждого вашего пользователя в момент, когда он пользуется вашим продуктом. Что это за ситуация? Какую задачу решит за него продукт? Какие критерии у пользователя могут быть?
Опишите все это по формуле:
Я “ПОРТРЕТ ЦА” попадаю в ситуацию “В КАКОМ КОНТЕКСТЕ Я НАХОЖУСЬ И КАКУЮ ПРОБЛЕМУ ИСПЫТЫВАЮ”, поэтому открываю “ПРИЛОЖЕНИЕ/САЙТ/МОБИЛЬНУЮ ВЕРСИЮ САЙТА” решаю задачу “ОПИСАНИЕ КОНКРЕТНОЙ ЗАДАЧИ, ОБЯЗАТЕЛЬНО С ЦИФРАМИ”
Я девушка 20-лет попадаю в ситуацию “устроила вечеринку и хочу накормить гостей быстро”, поэтому открываю “приложение доставки” решаю задачу “накормить друзей как можно более разнообразной едой с доставкой в пределах 40 минут”
Для того, чтобы бриф был наиболее эффективен, напишите минимум 3 таких истории о ваших клиентах.
Согласитесь, изобрести что-то принципиально новое, если вы не Илон Маск, трудно. Поэтому проблему, которую решает ваш продукт, уже можно решить как-то иначе — конкурентами или альтернативными способами. И информация об этом — крайне ценный источник информации для разработчиков.
Поэтому для начала опишите ваших прямых конкурентов, расскажите о каждом: дайте ссылку на продукт, объясните, что вам в нем нравится или не нравится, что хотелось бы позаимствовать.
То же самое проделайте с косвенными конкурентами (это могут быть группы в соцсетях или альтернативные решения проблемы). Опишите все то же самое, плюс расскажите о пользовательском пути, который проходит клиент, когда решает проблему через этого конкурента.
Этих 7 пунктов достаточно, чтобы подрядчик понял объемы и стоимость разработки любого мобильного приложения или MVP продукта.
А специально для тех, кто как раз хочет не тратить время на долгие переговоры, мы делимся шаблоном брифа у нас на сайте. Оставляйте почту, и мы пришлем на нее бриф с вопросами — останется только заполнить и отправить в студии.
Бриф на разработку приложения: 13 вопросов, которые помогут подготовиться ко встрече с разработчиками
Начиная поиск команды разработчиков для своего приложения, в первую очередь, нужно грамотно обозначить задачу. Чаще всего неподготовленный Заказчик формулирует свой запрос так: «Хочу приложение стильное и лаконичное, наподобие вот этого [. ], структуру сайта обсудим, сделать красиво и побыстрее». Такой запрос не несет в себе конкретной информации и может привести к некорректному результату или попросту затянуть процесс работы.
Вероятно, вы обратитесь сразу в несколько компаний, чтобы найти лучшую для себя, и вам придется из раза в раз отвечать на примерно одни и те же вопросы. Бриф на разработку с ответами на типичные вопросы может здорово сэкономить ваше время. Правда, когда речь идет о создании уникальной программы, универсальные вопросы не всегда полностью описывают запрос — сформулируйте задачу в нескольких абзацах, опишите кто будет пользоваться, какие возможности нужны, если планируется интеграция со сторонними сервисами, укажите их.
Почему вам не подходят универсальные опросники
В интернете можно найти много универсальных опросников на разработку сайта. Там вы найдете вопросы о том, нужна ли вам страница «О компании», будете ли размещать портфолио, нужен ли раздел «Наша команда» и подобное. Потенциальные клиенты, заходя на сайт, ожидают найти информацию об опыте компании, ее товарах и услугах, изучить отзывы. И владельцы сайтов создают контент, соответствующий их запросам.
Пользователи интернет-магазина тоже ожидают, что сайт выглядит и работает определенным образом. Содержит стандартные для таких сайтов страницы, типа описания товаров, информацию об оплате и доставке, личный кабинет с корзиной, историю покупок и др. Большую часть функционала, который возможен для интернет-магазина, можно перечислить в брифе, а клиент просто поставит + или — рядом с пунктом.
В разработке индивидуального продукта не все так просто. Создаваемая программа может не иметь аналогов, и не существует никаких «ожидаемых» запросов. Или она имеет аналоги, но большое количество программ-близнецов не нужно пользователям, а значит должна быть «фишка» сервиса. Клиент может сразу знать в чем она заключается, а может еще не сформулировал и ожидает, что в этом ему поможет команда разработки.
Если речь идет об автоматизации бизнеса, то основная задача состоит не в уникальности программы, а в том, почему уже имеющиеся сервисы не подходят Заказчику. При автоматизации мы изучаем как работают текущие процессы компании и ориентируемся на ожидаемую цель, чтобы получить наилучшее решение.
Но все таки есть общие вопросы, ответы на которые помогут разработчикам лучше понять задачу и ее особенности. А также дать верную оценку трудозатрат. 
Бриф на разработку индивидуального решения
Мы составили бриф на разработку приложения, который поможет вам учесть самое важное при формулировании задачи для команды разработчиков. Ответьте на следующие вопросы, чтобы исполнитель мог заранее определить предполагаемые трудозатраты и рассчитать приблизительную стоимость проекта.
1. Цель разработки
Самая частая желаемая цель — увеличение прибыли. Но к ней можно прийти разными путями. Например, можно сократить издержки (сделать программу, которая помогает экономить время на подготовку отчетов), или сделать новую классную «фишку» в приложении, благодаря которой станет больше клиентов. Можно внедрить программу лояльности, тогда имеющиеся клиенты станут покупать больше и т.п. Именно это команде разработки хотелось бы знать, чтобы они работали для достижения именно той цели, которую вы обозначили.
Самая частая желаемая цель — увеличение прибыли. Но к ней можно прийти разными путями. Например, можно сократить издержки (сделать программу, которая помогает экономить время на подготовку отчетов), или сделать новую классную «фишку» в приложении, благодаря которой станет больше клиентов. Можно внедрить программу лояльности, тогда имеющиеся клиенты станут покупать больше и т.п. Именно это команде разработки хотелось бы знать, чтобы они работали для достижения именно той цели, которую вы обозначили.
Но бывают и другие цели, например, забота о сотрудниках компании. Задача сделать программу удобнее и понятнее. Или, если это стартап, во главе может стоять какая-то глобальная идея, например, сделать приложение для решения определенной проблемы конкретной группы лиц.
2. Какая идея стоит за разработкой этого приложения? Какую проблему вы хотите решить?
При работе над приложением для обмена визитками Заказчик обозначил основную идею: избавиться от бумажного носителя и обеспечить быстрый и удобный обмен контактами данными. Поэтому, в первую очередь, прорабатывали логику передачи визитки и стремились реализовать ее именно с помощью NFC, ведь так быстрее всего.
3. Пробовали другие варианты решения этой проблемы? Почему не сработали?
Неудачный опыт — тоже опыт. Знание причин, по которым вам не подошли те или иные решения, поможет команде обратить внимание на эти сложности и продумать, как обойти их при разработке программы. Также ответ на этот вопрос избавит вас от бесполезных в данном случае советов попробовать существующее готовое решение.
4. Имеются ли на рынке подобные сервисы? Если да, укажите несколько. Что вам нравится/не нравится в этих программах?
Вы знаете своих конкурентов, а команда разработки нет. Не всегда сервисы, с которыми вы боретесь за внимание аудитории, очевидны для тех, кто не провел с вами много часов за маркетинговыми исследованиями и опросами аудитории. Помогите разработчикам и сразу укажите список конкурентов, если он определен.
5. Что вы видите «фишкой» своего сервиса?
Вернемся к примеру про приложение для обмена визитками, здесь «фишкой» является передача данные по NFC. Это выгодно отличает его от подобных сервисов. Важно, чтобы разработчики верно определили приоритет и акцентировали внимание на том, что нужно.
6. Целевая аудитория сервиса. Для кого разрабатывается?
Важно четко определить своего пользователя, так как в процессе разработки нужно учитывать потребности именно его. Если вы затрудняетесь в определении своей целевой аудитории, можете воспользоваться рекламным кабинетом Google AdWords. Подберите несколько сервисов-конкурентов, впишите в строку URL Landing page их сайты и вы узнаете демографические данные пользователей и устройства, которыми они пользуются. С помощью кабинета на Facebook вбейте в строку интересов название конкурента и перед вами окажется ценная информация — пол, семейное положение, уровень образования и т.д. его аудитории. Так вы сможете отследить совпадения характеристик аудитории, и это поможет вам ближе узнать своего клиента и сформулировать свою целевую аудиторию наиболее четко.
7. Планируется ли монетизация сервиса? Если да, то каким образом? Выбран ли платежный агрегатор?
Это важно для планирования трудозатрат и для определения конечной стоимости. Разработчикам нужно сразу учесть интеграцию с платежным сервисом и подумать о логике планируемых денежных потоков. Возможно, понадобятся дополнительные возможности типа просмотра истории оплат для пользователя или статистика по заказам для администратора.
8. Имеется ли логотип, фирменные цвета? Если нет, нужна ли разработка логотипа?
9. Есть ли пожелания/предпочтения по дизайну сервиса?
Разработчику нужно понимать сложность работы, потому что разный стиль/дизайн может потребовать разных работ/трудоемкости. Специально нарисованные иллюстрации и сложная анимация оценивается дороже простого дизайна.
10. Как планируете внедрять в работу (будет ли обучение сотрудников, нужно ли руководство пользователя)?
Если нужна документация или вы хотите, чтобы команда разработки провела обучение пользователей по работе с программой, эти моменты нужно заложить в смету.
11. К какому времени вы хотите выпустить первую версию программы?
Эта информация нужна для планирования работ. Чтобы определить сколько и каких специалистов нужно задействовать. Высокая срочность может сказаться на оценке работы.
12. По каким критериям вы определите, что разработка программы прошла успешно?
Команда разработчиков сразу должна определить критерии, по которым будет тестировать результат. Ведь формально разработка может быть сделано, но она бесполезна, если не выполняется поставленная перед ней бизнес-цель. Сформулируйте измеримые и достижимые критерии. Условие «должно быть удобно пользователю» невозможно объективно оценить. Сформулируйте его так «Время на оформление заказа пользователем не должно превышать 1 минуты».
13. Комментарий для команды разработчиков:
Дополнительная информация, которую вы считаете важной.
Резюме
Надеемся, что эти вопросы помогут вам лучше сформулировать свою идею, а разработчикам её воплотить!
Бриф на разработку мобильного приложения
Владислав Тимофеев, руководитель проектов
Можно долго и нудно рассуждать, что такое бриф, и для чего он нужен… Пожалуй, этим и займемся.
Создание брифа преследует одну главную задачу: узнать у клиента, чего он хочет, потратив только его (клиента) время. Тут стоит оговориться, что, каким бы крутым и увлекательным (по нашему мнению) ни был бриф, клиенту его заполнять лень в чуть менее, чем в ста процентах случаев. То есть, нет ничего лучше личной встречи и интервьюирования. Однако, не стоит недооценивать преимуществ автоматизированного брифинга — во-первых, предварительный сбор технических параметров проекта требует продуманных ответов, а эти ответы не всегда есть у тех людей, с которыми вы намерены обсуждать проект при встрече; во-вторых, если клиенту нужна быстрая оценка его проекта — необходимо быстро собрать сведения и согласовать приблизительный бюджет.
Во время создания нашего брифа мы пришли к мысли о том, что такой документ, в отличие даже от договора, было бы здорово сочинять всем профессиональным сообществом. Поэтому мы специально начали разрабатывать его в Гугл-формах и, забегая вперед, отмечу, что приглашаем к его редактированию всех заинтересованных. Впоследствии, пользоваться этим документом смогут все желающие.
Итак, ставим перед собой цель: создать бриф, заполнение которого облегчит предварительную оценку проекта. Основные задачи: выяснить максимум технических параметров, по пути собрав данные о чаяниях клиента, если он найдет время на их описание. Мы условно разделили бриф на семь частей, чтобы было, на что сослаться при обсуждении.
Контактная информация
Чисто психологический маневр — заставить клиента заполнить эти данные в начале. Обусловлено это тем, что по мере заполнения брифа потенциальный клиент может потерять интерес к этому делу и бросить, оставив нас без лида.
Общая информация
Как правило, платформы, типы устройств, способ монетизации клиенту известны заранее, заодно, необходимо сразу уточнить — имеется ли серверная часть? Приложениям чуть сложнее калькулятора необходимо откуда-то брать информацию и далеко не все, желающие заказать разработку люди в курсе, что разработка серверной части может составлять до 90% работы над проектом. Отсюда и круглые глаза маркетологов при виде сумм оценки. Вдаваться же в подробности при описании этого пункта также не следует, так как делать это лучше с техническими специалистами со стороны клиента.
Функционал
Конечно-же, описание функционала приложения — это то, ради чего клиент вообще приступил к заполнению брифа, но не тут-то было! Сначала мы выясним у него скучные данные, которые обычно всплывают в середине работ под грифом «Как не сделано? Очевидно-же, что это должно быть!».
Как ни странно, функционал вроде авторизации пользователей через соцсети — далеко не самая безобидная мелочь в разработке мобильных приложений. Разумеется, в процессе прототипирования, рано или поздно, вы подойдете к такому экрану и все разрешится, но если какие-то функции влияют на стоимость, их лучше сразу озвучить, чтобы потом не делать сюрпризов с дополнительными оценками и соглашениями к договору.Тут стоит снова обратить внимание на то, что ключевые моменты лучше выяснять заранее — до того, как клиент перейдет к сути приложения. Во-первых, получится «выудить» больше информации, во-вторых, клиент будет точнее описывать функционал и лирических отступлений будет меньше.
Сроки и деньги.
Если сроки еще можно отдать на фантазирование, то деньги — лучше ограничить диапазонами на выбор. Эти же диапазоны автоматически дают представление потенциальному клиенту о бюджетах, с которыми вы работаете.
Аудитория и задачи
Можно долго выяснять количественные показатели успешности проекта на этапе заполнения брифа, но надо быть готовым к тому, что они в любом случае будут абстрактны. Тем не менее, прямые цели и задачи у клиента могут быть уже сформулированы. Поэтому, ограничимся ими.
На сладкое
Наверное, самое приятное для клиента — описывать дизайн будущего продукта. Это люди делают с удовольствием. Правда, когда доходит до дела на письме, оказывается, что можно уложиться в три заветных слова: «красиво, современно, элегантно». Именно так клиенты чаще всего и поступают. Но эти расспросы уже лучше оставить на личную встречу.
Бриф разработчика мобильных приложений: 15 главных вопросов, которые необходимо задать клиенту
Рынок мобильного маркетинга постоянно растет, приходят новые разработчики, создаются новые интересные проекты. Мы стараемся идти в ногу со временем. Именно поэтому наше сообщество теперь называется Digital Professionals Hub и вы сможете читать материалы не только об особенностях web-разработки, но и об актуальных вопросах, которых может коснуться разработчик мобильных приложений.
Итак, начнем с главного! Прежде, чем приступить к разработке, необходимо подробно выяснить все требования заказчика.
Для того чтобы разработать успешное приложение, нужно все делать правильно с самого начала. Основное количество конфликтов между заказчиком и разработчиком связано с отсутствием документов, определяющих детали того, что именно нужно проработать. Не всем вопросы являются обязательными для заполнения, но очень важно сразу донести до клиента значимость проработки задания с первых шагов.
Первая часть брифа: вопросы, которые помогут определить, какое именно приложение необходимо вашему клиенту 
Для начала разберемся, чем занимается компания заказчика, и какую цель он преследует, заказывая у вас приложение. Каких результатов клиент собирается добиться с помощью приложения: помочь увеличить приток клиентов напрямую, собрать целевую аудиторию, увеличить объем продаж, осуществить мобильную часть интегрированной рекламной кампании, ускорить или оптимизировать процессы логистики (что то другое?).
Итак, вопросы, которые помогут определить с кем вы имеете дело, и какое именно приложение необходимо вашему клиенту.
1. Чем занимается ваша компания?
2. Как вы планируете использовать приложение в своем бизнесе?
3. Какой тип приложения вам нужен? (здесь стоит указать для клиентов краткое описание типов приложений)
4. Каких результатов вы хотите добиться с помощью данного приложения?
Вторая часть брифа: определение функционала и технических особенностей приложения.
Перейдем к самому приложению. Чтобы облегчить клиенту жизнь и не заставлять его объяснять на пальцах, какой именно функционал требуется от приложения, попросите его показать несколько примеров подобных приложений. Пусть он отметит, что ему нравится в этих приложениях, и какие он в них видит минусы. Так заказчик полнее определит список основных функциональных блоков.
Не менее важный вопрос, для каких платформ должно работать приложение: вот тут клиенту, скорее всего, понадобиться ваша помощь – вряд ли он разбирается в тонкостях совместимостей. Расскажите ему об особенностях и преимуществах различных платформ и технологий, клиент будет благодарен вам за помощь. Например, iOS лидирует в Северной Америке и Европе, а вот в России, Африке и Азии самой популярной платформой является Nokia Symbian.
Определяем функционал и технические характеристики:
Третья часть брифа: этап пост-разработки, техническая поддержка и поддержка обновлений
Очень важно обговорить кто и каким образом будет заниматься поддержкой и обновлением приложения. Заказчик может доверить поддержку вам, а может пожелать независимости. Есть ли в компании IT-специалисты, которые смогут этим заниматься? Если такого специалиста нет, скорее всего, потребуется система управления приложением с доступным для обычного пользователя интерфейсом.
Итак, завершающая группа вопросов:
11. Как должны обновляться данные в приложении?
12. Существует ли необходимость разработки сайта-приложения?
13. Кто будет заниматься технической поддержкой приложения? Необходимо ли техническое обслуживание после гарантийного обслуживания данного приложения?
14. Существует ли необходимость создания системы управления приложением?
15. Кому будут принадлежать авторские права на приложение и в какой форме (исключительные или неисключительные права)? Этот вопрос не стоит оставлять «по-умолчанию»
И последнее — это контактная информация клиента.
Выясните, кто со стороны заказчика будет курировать данный проект. Полезно понимать, является ли этот человек IT-специалистом или нет: это поможет вам выборе языка общения с контактным лицом. Уточните все способы связи: электронная почта, Skype, номер рабочего и мобильного телефонов.
Составление такого брифа позволит вам лучше сделать коммерческое предложение, а клиенту — увидеть в вас профессионала своего дела.