Разработать проект и не потерять деньги. 12 советов, как довести идею до конца и снизить риски

Мы в Ubrainians часто видим стартаперов, которые уже проверили идею, поговорили с потенциальными пользователями или у них просто «чуйка», что продукт нужен рынку. Но теперь им нужно все продумать и найти команду, которая поможет этот продукт разработать.

Пять шагов

В целом, от идеи до готового продукта вы пройдете через несколько этапов:

1. Прототипирование (схематическое изображение продукта)
2. Разработка технического задания
3. Дизайн
4. Разработка продукта
5. Публикация

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

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

Но сначала нужно сложить полное представления о первой версии продукта.

Минимум функций и быстрый старт

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

Сделайте сначала самое необходимое и выйдите на рынок с минимально жизнеспособным продуктом (minimum viable product – MVP). При этом, уровень минимальной жизнеспособности для продуктов может отличаться. 

Если стартап устраняет «боль» – ему простят недочеты

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

Без продукта будет больнее, чем с ним. 

Когда Uber, AirBnb и другие первопроходцы только появились, они были очень упрощенными версиями себя сегодняшних.

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

В гонке побеждает лучший

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

В 2020 году так вышел на рынок Checkbox. Когда государство разрешило использовать программные регистраторы кассовых операций вместо железных ящиков, на рынке появилось несколько предложений.

Checkbox сразу же сделали сайт, предложили на сайте тарифы, начали сотрудничать с учетными системами, запустили PR-кампанию и активно занимались маркетингом.

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

Дайте больше, чем другие

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

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

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

«Рисуйте» схемы

Когда понятно какой продукт для стартапа будет минимально жизнеспособным, важно полностью его представить еще до разработки дизайна и программирования.

Для визуализации продукта хорошо подходят прототипы – схематические изображения экранов. 

Прототипы рисуют на основе пользовательских сценариев, например:

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

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

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

На основе прототипов можно начинать работу с дизайном.

Доверяйте профессионалам

Разработку дизайна лучше доверить дизайнеру с опытом.

Очень важно, чтобы дизайнер разбирался в UX (user experience) – пользовательском опыте, и умел его проектировать. Если есть возможность, то хорошо привлечь дизайнера для отрисовки и прототипов тоже. 

С таким дизайном сложно работать, это просто яркие нефункциональные картинки.

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

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

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

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

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

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

Сроки, цены и контроль

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

Сам процесс разработки обычно делится на этапы – спринты. Если был этап прототипирования, то заранее понятно сколько их будет и как они будут разделены.

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

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

И более того, если в процессе станет понятно, что что-то лучше убрать или изменить, это можно сделать. 

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

iOS, Android или веб

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

Например, при разработке приложения можно выбрать какое вы будете разрабатывать: нативное или кроссплатформенное. 

Нативные – это приложения, которые разрабатываются под каждую платформу отдельно: iOS, Android, веб. В процессе развития, когда нужно будет добавлять новые функции, их нужно программировать для каждого приложения также отдельно.

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

Например, Instagram выполняет ресурсоемкие операции: проведение прямых эфиров, наложение эффектов на фото и видео, редактирование изображений. Для эффективной работы ему нужно использовать преимущества и возможности каждой операционной системы и даже отдельных устройств на все сто.

Делать это при кроссплатформенной разработке гораздо сложнее, чем при нативной. Если производительность для продукта критична, то экономия даже половины стоимости не оправдает потери 10% производительности. 

Нативные приложение программируют на:

•  Android – Kotlin, Java 
• iOS – Swift

Кроссплатформенные приложения – это приложения, где один код используется для нескольких платформ.

Например, Flutter позволяет разрабатывать одно приложение для iOS, Android, веб и десктопа. Это очень удобно: продукт может использоваться на разных девайсах, и в процессе развития функции добавляются один раз сразу для всех платформ. Расход времени и денег сокращается в два-три раза, а уровень качества сохраняется.

Кроссплатформенные приложения программируют на:

• Flutter
• React Native

Определитесь с «невидимой» частью

Кроме видимой части – интерфейсов в приложении и верстки в веб-проектах, продукт имеет невидимую часть – серверное приложение, которое отвечает за логику работы: производит расчеты, управляет доступами, хранит данные.

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

Серверные приложения и API чаще всего программируют на:

• NET
• Node.js
• Java
• Python
• PHP

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

Все данные и доступы – ваши

Когда продукт готов, его публикуют в App Store/Google Paly (в случае с мобильными приложениями) или под вашим доменом (в случае с веб-проектами). Над поддержанием и развитием продукта вы можете дальше работать с людьми, которые его разработали, или собрать собственную команду.

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

Что нужно получить от разработчиков:

1. Исходный код всех частей продукта (серверного приложения, мобильных приложений или сайта). Обычно он находится в хранилище исходного кода на таких площадках, как GitHub или GitLab. Там вам должны предоставить уровень доступа «оwner». С этим доступом вы можете в любой момент удалить текущую команду и передать доступ кому нужно.
2. Исходники макетов. Сейчас это чаще всего ссылка на макеты в Figma. Макеты необходимы для будущих доработок, чтобы вы могли свободно использовать элементы и стили для проектирования новых функций.
3. Спецификацию к проекту. Это может быть небольшой документ, где будет описано на каких технологиях выполнен проект, где зарегистрирован домен, где располагается хостинг, там могут быть предоставлены доступы ко всем учетным записям. Этот документ вы сможете передать команде для дальнейшей работы с продуктом.

Обезопасьте себя

Всегда помните о безопасности. У вас в любой момент должна быть возможность заменить команду без последствий.

Хостинг, домен, учетные записи разработчика должны быть зарегистрированы на ваше имя или на имя вашей компании. Приложения в App Store и Google Play также должны быть опубликованы от вашего имени. У вас должен быть ко всему доступ.

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

Это все понадобится для следующих релизов продукта.

Команда – ваше все

Многие стартапы приходят к команде разработки с идеей и не разбираются в технической части и процессе. Хорошая команда возьмет на себя максимум и проведет через этот процесс «за ручку», не будет ожидать от вас экспертизы в вещах, в которых вы разбираться не должны.

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

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

Вот как пройти путь от идеи до готового продукта, чтобы все получилось.