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

Собираетесь создать мобильное приложение или 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 продукта.

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

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

2121
6 комментариев

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

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

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

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

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

1

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

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

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

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

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

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

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