Часто, создавая новый продукт или бизнес, начинающие предприниматели сразу хотят создать мощный многофункциональный продукт с красивым дизайном и различными интеграциями. Однако стоимость разработки таких приложений может доходить до нескольких миллионов, а по временным затратам достигает нескольких месяцев или даже лет. Анна Радзиевская, основательница и директор по продукту Code Breakers, рассказывает, как No-code помогает запустить продукт без команды разработчиков.
На дорогостоящую разработку поднимаются инвестиции, тратятся накопления предпринимателей. Она затягивает фаундеров в постоянное полирование и улучшение продукта, им кажется, что продукт все еще не готов к выходу на рынок. А когда он все-таки выходит, через 1–3 месяца, то получается, что приложение классное, а регистраций мало, пользователи скачивают приложение, но не оформляют платную подписку, не покупают. Стоимость привлечения клиента оказывается высокой, бюджет сливается на трафик, а выручки совсем нет. Юнит-экономика не сходится, и, как следствие, приходит понимание, что у продукта нет product-market-fit. Но к этому времени деньги, ресурсы и время на доработку истощены. Такой расклад демотивирует стартаперов, и на этом они завершают свою предпринимательскую деятельность вместо того, чтобы при запуске попробовать использовать другой подход, помогающий избежать рисков.
Почему важно начинать разработку нового продукта с No-code без привлечения классической разработки
Когда мы смотрим на успешные продукты на рынке, такие, как Airbnb, Amazon или Yandex, нужно понимать, что такими, какие они есть сейчас, они стали не сразу, и этому предшествовал долгий и многоэтапный путь постепенного развития. Процесс эволюции продукта обычно имеет несколько этапов:
- Идея продукта/бизнеса.
- Прототип — быстрая, черновая реализация будущего продукта.
- MVP (минимальный жизнеспособный продукт) — самая простая версия товара, услуги или сервиса с минимальным набором функций (иногда даже одной), которая несет ценность для конечного потребителя.
- Продукт 1.0 — продукт, имеющий более продвинутую функциональность, определенную из потребностей клиентов и бизнеса после успешной реализации этапа MVP.
- Продукт 2.0 — комплексный продукт с расширенной функциональностью и набором фич, более совершенный, чем продукт 1.0.
- Полнофункциональный продукт (продукт версии n) — развитый и расширенный продукт, функционал которого развивается и дополняется по мере масштабирования бизнеса.
Этапы эволюции ИТ-продукта
Первые три этапа представляют собой фазу поиска product-market fit, где бизнес или продукт только ищет форму и бизнес-модель, рентабельную и нужную рынку. На этой фазе задача фаундеров или собственников бизнеса — максимально дешево и быстро протестировать все гипотезы и найти то, что работает.
С 4-го по 6-й этапы происходит фаза масштабирования бизнес-модели, которая показала свою стойкость на рынке и финансовый успех. Тут очень важно отметить, что масштабирование продукта должно происходить с ростом бизнеса, а бизнес характеризуют деньги, которые он зарабатывает. То есть усложнение продукта и значительная доработка функциональности должны напрямую коррелировать с ростом финансовых показателей, но никак не наоборот.
Для того, чтобы перейти из одной фазы в другую, необходимо пройти точку бифуркации, которая означает нахождение рабочей бизнес-модели (product-market fit) и старта этапа масштабирования.
Одно из упущений многих стартаперов и владельцев бизнеса в том, что они считают, что развитие их продукта будет идти по такой прямой линии из стадии в стадию. Но зачастую с первого раза никто не попадает в работающую и прибыльную бизнес модель. Как правило, приходится делать от двух до пяти пивотов (от англ. pivot — «смена бизнес-модели»), прежде чем найдется та самая работающая бизнес-модель, которую стоит масштабировать. Именно на стадии поиска product-market fit застревает большинство начинающих компаний. Это происходит, потому что стартаперы тратят все ресурсы на разработку MVP, делают это долго и дорого, так что при необходимости менять бизнес-модель продукт становится настолько негибким, что пивот для них становится невозможным.
Поэтому в разработке большинства бизнес-продуктов стоит применять менее затратные инструменты. No-code — один из них, он идеально подходит для создания и тестирования MVP.
Этапы разработки продуктов, используя No-code с нуля
Главная особенность No-code подхода в том, что создание MVP-продукта может проходить самостоятельно без привлечения команды, как в классической разработке. Весь цикл создания продукта от идеи продукта до его запуска может выполнить один специалист.
Рассмотрим все этапы:
Этапы разработки ИТ-продукта
Этап 1. Описание идеи продукта/проекта
Прежде чем начинать разработку, необходимо четко сформулировать ответы на вопросы о том, что, зачем и почему вы разрабатываете. Спросите себя:
- Что за бизнес/продукт вы видите?
- Какую проблему он решает?
- Кто его аудитория, как она сейчас решает проблему?
- Достаточный ли объем рынка, есть ли конкуренты, как они оперируют, почему вы делаете то же самое или отличное от них?
- Как будет происходить монетизация, какой бюджет вы готовы вложить разработку MVP-версии?
Этап 2. Составление бизнес требований
На данном этапе необходимо продумать и описать, как будет работать продукт, какие функциональные требования иметь.
- Как работает бизнес-модель, как выглядит вся цепочка процесса от прихода пользователя до завершения заказа?
- Кто вовлечен в использование продукта: клиенты, исполнители, рекрутеры, бухгалтерия, нужен ли им какой-либо инструментарий и функционал?
- В каких странах планируется запускать сервис и на каких языках?
- Какие платежные системы планируется использовать?
- Какие дополнительные внешние сервисы необходимо использовать, какие интеграции производить?
Этап 3. Выделение MVP (минимально жизнеспособный продукт)
В данном случае из бизнес-требований требуется выделить минимальный набор критически необходимого функционала, который позволит проверить гипотезу, то есть сформировать функционал MVP. Важно помнить, что основная задача — проверить жизнеспособность идеи, а не разработать полнофункциональный продукт. Необходимо сфокусироваться только на том, без чего сама бизнес-идея не работает, отделить главное от второстепенного.
Этап 4. Подбор стека инструментов
Понимая, какой функционал будет реализован в MVP, а какой останется для последующих версий продукта, можно приступить к подбору стека (набора) No-code-инструментов для его реализации. Это может быть микс из 2–6 разных No-code-платформ и сервисов. Но стоит учитывать: чем больше сервисов интегрируется, тем больше риск. Система/продукт становятся более хрупкими: если одно из звеньев не сработает, то упасть может вся система. Именно поэтому лучше ориентироваться на оптимальное количество инструментов в стеке и всегда отслеживать их работу.
Кроме того, важно определить возможность подключения к платежным сервисам того стека, который выбран, а также проверить возможность его интеграции с необходимыми внешними сервисами. Подумайте не только о том, что нужно для создания MVP, но еще и о том, как потом (при условии успешности бизнес-модели) можно масштабировать продукт, и не окажется ли набор инструментов для MVP преградой.
Этап 5. Составление продуктово-технического задания
Определившись с тем, какой именно функционал будет реализован в MVP и каким набором No-code-инструментов, можно переходить к составлению продуктово-технического задания. Оно включает в себя детальную проработку и описание логики клиентских путей, состава и связей каждой из страниц/экранов, описание ролей пользователей и доступы в соответствии с ними, настройки приватности, статусную модель заказов/оплат, отрисовку вайрфреймов в Figma и прототипирование функционала с целью проверки бизнес-логики.
Этап 6. Составление базы данных
Данный пункт применим при разработке полноценных приложений. Здесь важно выделить основные сущности и их атрибуты, продумать статусы и связки таблиц.
Этап 7. Отрисовка дизайна
Имея продуктовое ТЗ и вайрфреймы, а также зная, на каком No-code-стеке будет реализован каждый из элементов продукта, нужно отрисовать дизайн. Бывает, что в некоторых No-code-инструментах нет возможности кастомизировать дизайн полностью, можно только изменить какие-либо характеристики: цвет, тени, внешний вид, фон. Данные ограничения нужно учитывать. Но если выбранный No-code-инструмент позволяет сделать кастомный дизайн, можно воспользоваться шаблонами или привлечь дизайнера.
Этап 8. Разработка
В No-code-подходе разработка frontend и backend не имеет такого явного разграничения и выполняется параллельно. Лучше всего приложение разделить на части и последовательно создавать функциональность каждой из них. Например, личный кабинет клиента может содержать главную страницу, страницу входа, сам кабинет и профиль.
Начинать лучше всего с создания базы данных. Она будет связывать все страницы/вкладки и части вашего приложения, являться его основой. А далее смело приступать к frontend и backend:
Frontend-разработка:
- Создание структуры страниц.
- Разработка элементов интерфейса.
- Адаптация интерфейса под разные устройства.
Backend-разработка:
- Создание функционала и логики для каждого элемента/действия/страницы.
- Задание внутренних процессов/расчетов системы.
- Создание регистрации и авторизации пользователей, ролей и настройки приватности/доступов и другое.
Этап 9. Интеграции с сервисами
В No-code-инструментах интеграции с внешними сервисами обычно уже нативно встроены при помощи плагинов. Однако порой необходимо делать кастомную интеграцию через API. Поэтому на этапе подбора стека стоит проверить, есть ли открытое API у сервиса и может ли No-code-инструмент выполнить данную интеграцию.
Основные интеграции, которые нужно учесть для продукта: платежные системы, сервисы рассылок (email, SMS), внутренние сервисы (crm, slac), сервисы аналитики, сервисы конференций (Zoom). Если у инструментов и сервиса нет встроенной интеграции, в некоторых случаях может понадобиться помощь разработчика.
Этап 10. Тестирование
При тестировании очень важно проверить работоспособность приложения и корректность функциональности, которая была изначально заложена при составлении продуктово-технического задания. Тестирование может проходить в несколько этапов, с подготовкой плана, ведением журнала ошибок и проверкой работоспособности на различных устройствах. Тестирование — один из ключевых этапов, относиться к нему стоит с повышенным вниманием.
Этап 11. Запуск
После проведения тестирования и устранения всех замечаний необходимо подготовить продукт к запуску на пользователей. Для этого важно наполнить его контентом (картинки товаров и услуг), провести копирайтинг текстов, добавить пользовательское соглашение, соглашение на обработку персональных данных, проверить соответствие всем необходимым первоначальным требованиям и начинать тестирование на пользователей.
После запуска продукта очень важно следить за его работоспособностью и поддержкой, обращать внимание на обратную связь от пользователей, проводить с ними интервью. Только так можно понять, совпадают ли те смыслы и идеи, которые вы закладывали при разработке, с тем, как понимает и использует пользователь ваш продукт.
Переход с No-code на классическую разработку
Переход на классическую разработку релевантен уже тогда, когда No-code становится горлышком бутылки, и вы сталкиваетесь с ограниченностью функционала, мешающей развитию бизнеса.
No-code довольно мощный инструмент, который позволяет усложнять функциональность с масштабированием бизнеса. Многие продукты/бизнесы так и остаются на нем.
Однако, если вы все-таки решились, для перехода лучше всего использовать частичную параллельную замещающую разработку. То есть параллельно с работой существующего продукта и процессов начинать разработку наиболее критической части продукта. Затем постепенно переводить данные пользователей на новый продукт, созданный с помощью классического подхода, и только после заменять сам продукт. Так итерационно можно полностью перевести все части бизнеса с No-code на код.
Начало перехода обычно начинается с клиентских внешних продуктов, которые требуют более высокого качества дизайна, нативных функций. Внутренние продукты могут подождать.
Читать далее:
Ученые из зоны вечной мерзлоты: как они разрабатывают умную одежду и вакцину против рака
«Ходячие мертвецы» существовали миллионы лет назад: ученые рассказали, как они появились