Чек-лист для идеального брифа на разработку MVP
02.10.2021
Собираетесь создать мобильное приложение или MVP и думаете, что бриф для разработчика — всего лишь формальность? Будьте готовы потерять деньги и время. ТЗ составляется уже после подписания договора и включает в себя все технические тонкости и особенности проекта.
Бриф же помогает исполнителю ознакомиться с задачей, оценить сроки. Позволяет понять, сколько стоит создать такое мобильное приложение или сайт, и прикинуть возможные инструменты для разработки.
Пренебрегая брифом, многие тратят в два раза больше времени, денег и нервов только на начальном этапе работы. Специально для предпринимателей, которые хотят разработать мобильное приложение или выпустить MVP быстро и качественно, я написал чек-лист идеального брифа. А на у нас на сайте можно скачать готовый шаблон, который сразу можно заполнять и присылать в студии. Особенно он подойдет, если вы выбираете NoCode разработку.
Итак, как выглядит идеальный бриф на разработку продукта:
Пункт 1: Сроки старта и окончания работ
Самый очевидный и самый обязательный момент в брифе. Важно дать студии понять, на какие сроки вы рассчитываете, чтобы они могли сразу сориентироваться по собственным возможностям и загруженности. Напишите, когда вы хотите приступать к работе и в какие сроки приложение должно быть реализовано.
Это также поможет избежать дискоммуникации, если подрядчик затянет со сроками — вы сразу обозначили допустимые временные рамки, а значит соглашаясь на них, подрядчик подтверждает, что выполнит работу в срок, если не оговорено иного.
Пункт 2: Рассказ о продукте в паре предложений
Нет, это не значит, что ребятам из студий разработки просто лень читать. Краткость нужна здесь в первую очередь для того, чтобы вы выделили главные УТП вашего продукта, не растекаясь мыслью по древу. Когда количество текста ограничено, невольно постараешься рассказать о самых важных вещах. Вот они то и нужны вашим разработчикам.
Например: ReadApp. Приложение для чтения и прослушивания книг, у которого синхронизируются печатная и аудиоверсии. То есть закончив слушать книгу, вы можете продолжить ее читать с того же места.
Пункт 3: Цели проекта
В этом пункте необходимо пояснить, зачем вы вообще собрались разрабатывать продукт. От этого зависит результат, который вы получите на выходе, а также ясность коммуникации с исполнителем.
Объясните, зачем вы обращаетесь к студии, чего ждете на выходе.
Например, вы хотите создать мобильное приложение или MVP продукта, проверить, насколько он нужен на рынке. Для этого отлично подойдет NoCode разработка, и в этом случае не придется тратить время и деньги на написание кода, углубляться в детали. Можете прописать конкретные гипотезы, чтобы исполнители могли сразу сориентироваться, какие инструменты для этого понадобятся.
Если же у вас есть существующий бизнес и вы хотите автоматизировать в нем процессы, пропишите, какие метрики вы хотите улучшить и на сколько. Так, узнав стоимость разработки, вы сможете просчитать окупаемость этих инвестиций. А специалисты, которые будут работать над проектом, будут понимать, что и зачем они делают.
Вот что должно получится:
У меня есть служба доставки еды. Я хочу разработать мобильное приложение чтобы:
1. Увеличить LTV и перенаправлять людей с сайта в приложение.
2. Выйти в новые каналы и использовать новые воронки
3. Создать стабильный канал коммуникации с клиентами
С этой информацией студия сможет предложить лучшие пути решения.
Пункт 4: Дизайн
Далее нужно указать, есть ли у вас дизайн (макет, бренд бук или пожелания в визуальном плане) или его нужно разработать. Если дизайна нет, но есть задумки — поделитесь пожеланиями. Дополнительным плюсом будут референсы — поищите сайты/приложения, дизайн которых вам нравится. Приложите ссылки и расскажите, что именно вам импонирует.
Пункт 5: технологии
Далее напишите, какие технологии вы хотите использовать.
Например, вы можете описать необходимые вам для интеграции программы/сервисы, или просто указать, что хотели бы использовать NoCode разработку или обычный код.
Если же предпочтений и идей нет — просто оставьте поле пустым. В конце концов, вы обращаетесь к специалистам, чтобы не думать о сложном.
Пункт 6: истории об использовании продукта через сценарии
В этом пункте нужно будет вспомнить портреты всех сегментов вашей аудитории, их боли и как следует их описать. Это нужно, чтобы оптимизировать будущий продукт и работать над действительно нужными функциями.
По нашему опыту, половина планируемого функционала пользователю оказываются не нужны и просто тратят деньги бизнеса.
Если планируется создавать первую версию продукта, то в ней должно быть самое ценное. С помощью этого этапа вы сможете помочь в первую очередь себе, как основателю продукта. Понять что важно делать, а что можно отложить в следующую версию.
Воспользуйтесь форматом сценариев. Забудьте о кнопочках и экранах, представьте каждого вашего пользователя в момент, когда он пользуется вашим продуктом. Что это за ситуация? Какую задачу решит за него продукт? Какие критерии у пользователя могут быть?
Опишите все это по формуле:
Формула истории:
Я “ПОРТРЕТ ЦА” попадаю в ситуацию “В КАКОМ КОНТЕКСТЕ Я НАХОЖУСЬ И КАКУЮ ПРОБЛЕМУ ИСПЫТЫВАЮ”, поэтому открываю “ПРИЛОЖЕНИЕ/САЙТ/МОБИЛЬНУЮ ВЕРСИЮ САЙТА” решаю задачу “ОПИСАНИЕ КОНКРЕТНОЙ ЗАДАЧИ, ОБЯЗАТЕЛЬНО С ЦИФРАМИ”
Пример описания:
Я девушка 20-лет попадаю в ситуацию “устроила вечеринку и хочу накормить гостей быстро”, поэтому открываю “приложение доставки” решаю задачу “накормить друзей как можно более разнообразной едой с доставкой в пределах 40 минут”
Для того, чтобы бриф был наиболее эффективен, напишите минимум 3 таких истории о ваших клиентах.
Пункт 7: Конкуренты
Согласитесь, изобрести что-то принципиально новое, если вы не Илон Маск, трудно. Поэтому проблему, которую решает ваш продукт, уже можно решить как-то иначе — конкурентами или альтернативными способами. И информация об этом — крайне ценный источник информации для разработчиков.
Поэтому для начала опишите ваших прямых конкурентов, расскажите о каждом: дайте ссылку на продукт, объясните, что вам в нем нравится или не нравится, что хотелось бы позаимствовать.
То же самое проделайте с косвенными конкурентами (это могут быть группы в соцсетях или альтернативные решения проблемы). Опишите все то же самое, плюс расскажите о пользовательском пути, который проходит клиент, когда решает проблему через этого конкурента.
Этих 7 пунктов достаточно, чтобы подрядчик понял объемы и стоимость разработки любого мобильного приложения или MVP продукта.
А специально для тех, кто как раз хочет не тратить время на долгие переговоры, мы делимся шаблоном брифа у нас на сайте. Оставляйте почту, и мы пришлем на нее бриф с вопросами — останется только заполнить и отправить в студии.
А если вопросы о разработке вашего мобильного приложения еще остались - самое время записаться к нам на бесплатную консультацию. За полчаса разберемся в инструментах, оценим стоимость и сроки.
Ринат Хатипов
