Мы сделали чек-лист для идеального брифа на разработку MVP

Собираетесь создать мобильное приложение или MVP и думаете, что бриф для разработчика — всего лишь формальность? Будьте готовы потерять деньги и время.

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

Привет! Меня зовут Ринат, я основатель NoCode-студии Zero To One. Общаясь с клиентами, которые только выбирают себе подрядчика, я часто замечаю, что они пренебрегают брифом и считают важным только ТЗ.

Оно и понятно, ведь ТЗ составляется уже после подписания договора и включает в себя все технические тонкости и особенности проекта.

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

Пренебрегая брифом, многие тратят в два раза больше времени, денег и нервов только на начальном этапе работы.

Специально для предпринимателей, которые хотят разработать мобильное приложение или выпустить MVP быстро и качественно, я написал чек-лист идеального брифа. А на у нас на сайте можно скачать готовый шаблон, который сразу можно заполнять и присылать в студии. Особенно он подойдет, если вы выбираете NoCode разработку.

Итак, как выглядит идеальный бриф на разработку продукта:

Пункт 1: Сроки старта и окончания работ

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

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

Пункт 2: Рассказ о продукте в паре предложений

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

Например:

ReadApp

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

Пункт 3: Цели проекта

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

Объясните, зачем вы обращаетесь к студии, чего ждете на выходе.

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

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

Вот что должно получится:

У меня есть служба доставки еды. Я хочу разработать мобильное приложение чтобы:

1. Увеличить LTV и перенаправлять людей с сайта в приложение.

2. Выйти в новые каналы и использовать новые воронки

3. Создать стабильный канал коммуникации с клиентами

С этой информацией студия сможет предложить лучшие пути решения.

Пункт 4: Дизайн

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

Пункт 5: технологии

Далее напишите, какие технологии вы хотите использовать.

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

Если же предпочтений и идей нет — просто оставьте поле пустым. В конце концов, вы обращаетесь к специалистам, чтобы не думать о сложном :)

Пункт 6: истории об использовании продукта через сценарии

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

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

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

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

Опишите все это по формуле:

Формула истории:

Я “ПОРТРЕТ ЦА” попадаю в ситуацию “В КАКОМ КОНТЕКСТЕ Я НАХОЖУСЬ И КАКУЮ ПРОБЛЕМУ ИСПЫТЫВАЮ”, поэтому открываю “ПРИЛОЖЕНИЕ/САЙТ/МОБИЛЬНУЮ ВЕРСИЮ САЙТА” решаю задачу “ОПИСАНИЕ КОНКРЕТНОЙ ЗАДАЧИ, ОБЯЗАТЕЛЬНО С ЦИФРАМИ”

Пример описания:

Я девушка 20-лет попадаю в ситуацию “устроила вечеринку и хочу накормить гостей быстро”, поэтому открываю “приложение доставки” решаю задачу “накормить друзей как можно более разнообразной едой с доставкой в пределах 40 минут”

Для того, чтобы бриф был наиболее эффективен, напишите минимум 3 таких истории о ваших клиентах.

Пункт 7: Конкуренты

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

Поэтому для начала опишите ваших прямых конкурентов, расскажите о каждом: дайте ссылку на продукт, объясните, что вам в нем нравится или не нравится, что хотелось бы позаимствовать.

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

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

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

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

0
6 комментариев
Написать комментарий...
Артур Дунайцев

Про юзерстори вы слышали, а про из применение нет. 

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

А еще экранов может быть 80. И вот каждый из них решает свои боли и проблемы. Так что сделанные второпях 2-3 юзерстори можно вполне впихать в миссию и цели. 

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

Но это уже про продуктовую разработку, не так ли? 

Ответить
Развернуть ветку
Zero To One
Автор

Юзерстори – это инструмент. Его можно использовать по разному. В данном случае это не имеет отношения к функционалу. Возможно, проблема терминологии.

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

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

Ответить
Развернуть ветку
Валерий Цукатов

Мыслью по дереву текут невежды

Ответить
Развернуть ветку
Denis Kosov

Чек-лист, бриф: как много в этих словах

Ответить
Развернуть ветку
Nizamov Irek

Краткий вывод статьи, как не слить бабки на нормальных разработчиков, а слить их на nocode разработчиков а потом все равно слить на нормальных 

Ответить
Развернуть ветку
Arman

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

Ответить
Развернуть ветку
3 комментария
Раскрывать всегда