Мы сделали чек-лист для идеального брифа на разработку 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 продукта.
А специально для тех, кто как раз хочет не тратить время на долгие переговоры, мы делимся шаблоном брифа у нас на сайте. Оставляйте почту, и мы пришлем на нее бриф с вопросами — останется только заполнить и отправить в студии.
А если вопросы о разработке вашего мобильного приложения еще остались - самое время записаться к нам на бесплатную консультацию. За полчаса разберемся в инструментах, оценим стоимость и сроки.
Про юзерстори вы слышали, а про из применение нет.
Во-первых, юзерстори относится к функуионалу. И если у вас карточка товара, то в ней, извините, можно штук 25 юзерстори зашить, и если большинство кейсов не учесть, то потом будет мучительно больно переделывать.
А еще экранов может быть 80. И вот каждый из них решает свои боли и проблемы. Так что сделанные второпях 2-3 юзерстори можно вполне впихать в миссию и цели.
Кроме этого ещё, наверное, требуется подумать о метриках, как оценивать успех и неуспех покрытия той или иной стори, о том, как эти метрики собирать, как они влияют на профит проекта и все такое.
Но это уже про продуктовую разработку, не так ли?
Юзерстори – это инструмент. Его можно использовать по разному. В данном случае это не имеет отношения к функционалу. Возможно, проблема терминологии.
Часто заказчик предлагает в первое версии продукта обилие не самых нужных функций. Наша задача – заскорить их, чтобы зашить в первую версию только самое нужное, проверив гипотезу ценности самого продукта.
Несколько юзерстори позволяют выделить самое основное. А уже после, получив цифры и фидбэк, можно двигаться дальше.
Мыслью по дереву текут невежды
Чек-лист, бриф: как много в этих словах
Краткий вывод статьи, как не слить бабки на нормальных разработчиков, а слить их на nocode разработчиков а потом все равно слить на нормальных
Классный материал, спасибо. Да, базовые штуки, но даже их часто не соблюдают. Круто, что подробно написали частые ошибки, особенно про функционал.