От идеи до продукта без навыков программирования (введение в no-code)

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

В этой статье разберемся:

Давайте начнем с нуля.
Существует довольно большое количество подходов к созданию продуктов. Большая часть из них работает по следующей схеме:

Если резюмировать эти этапы и представить их в виде стадий развития стартапа, то получится следующая таблица:

У стартапов на каждой стадии есть несколько параметров — инструменты, то есть сам продукт; количество сотрудников; количество дене; количество времени и выручка. Деньги и выручка разделены специально, потому что мы разделяем инвестиции и деньги, которые стартап зарабатывает.

Идем далее, как правило, над продуктом работают следующим образом:

Чаще всего команда состоит из следующих подразделений:

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

Я это уже сделал и вот что из этого вышло.

Найм команды — от 1 000 000 рублей в месяц:

Аутсорс разработки — до 3 000 000 рублей.
2000/час — средняя ставка качественной разработки;
1500 часов — три месяца работы 3 разработчиков на full time.

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

Таким образом 1 млн рублей превращается в несколько млн рублей для запуска простого продукта.

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

Большие затраты для продукта, который еще не преступил к проверке своих гипотез и инвестиции не привлек, не так ли?

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

Эта иллюзия возникает в следствие разного восприятия людьми информации и просто на просто разного опыта.

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

Возникает логичный вопрос, а возможно ли это? Если да, то как?

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

Как я уже сказал, инструментов ооочень много, на этом слайде нет и 20% от того, что представлено на рынке

Вы могли уже иметь какое-то представление о том, что такое no-code инструменты, как их использовать и так далее, но давайте определимся с терминологией, как правило, их два — no code и low code.

Бизнес издание Forbes считает, что основное отличие между этими двумя категориями заключается в следующем:

Выделю 3 основных критерия, по которым вы сделаете выбор в сторону самостоятельной разработки MVP вашего продукта:

На этапе идеи и разработки продукта скорость и дешевизна запуска должна стоять на первом месте!

То, о чем я пишу в данной статье не только мое мнение, можете на досуге почитать статью от Forbes "What You Need To Know About The Low-Code Market"
и от Forrester "Why You Need To Know About Low-Code, Even If You’re Not Responsible For Software Delivery".

Очень часто нам могут приводить следующие аргументы, в силу того, что метод no-code неэффективен:

И напрашивается вопрос, а целесообразно ли использовать no-code или все-таки обратиться в разработку?
Предлагаю вернуться к табличке со стадиями стартапов:

Я добавил в таблицу последнюю колонку «Low code» и написал субъективное мнение о том, как эта технология применяется на различных стадиях проекта.

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

Но даже на этих этапах проектов использование low-code инструментов не заканчивается, даже среди выпускников Y Combinator есть примеры, которые держали полностью свой продукт на платформе .Buble.
Я предполагаю, что там скорее речь идет про автоматизацию процессов и бэк офис на более поздних стадиях, но так или иначе, эти инструменты применимы практически на каждой стадии (не лезу в юридические тонкости и стадии продажи стартапа, когда все должно быть написано кодом и все права защищены).

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

На стадии после seed’a действительно будет необходимость переписать решения, расширить команду разработки и инвестировать в собственные технологии.

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

Что ж, идем далее

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

На самом деле, все очень просто. Прототип — это имитация взаимодействия с вашим будущим продуктом. MVP — уже рабочая версия вашего продукта, с которой пользователь может взаимодействовать самостоятельно, а не просто кликать между экранами.

С точки зрения использования вами инструментов очень важно понимать терминологию, вот три основных:

Wireframe — каркас;
Mockup — набросок, черновик;
Prototype — кликабельный прототип продукта.

Важно понять следующее, что прототип ради прототипа делать не нужно!
А ради чего тогда?

Первые два пункта — обязательны! Третий — опционален.

Где создавать прототипы?

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

Раньше был одним из самых популярных инструментов для работы с экранами

Плюсы:
Интуитивный интерфейс;
Легко обучиться;
Удобные группировки и «символы»;

Минусы:

Нельзя прототипировать;
Только рисование экранов;
Нельзя скачивать отдельные элементы.

Спасение для тех, кто не является дизайнером

Плюсы:
Можно загружать экраны из Sketch и Figma;
Прост и удобен в использовании;
Много шаблонов и готовых элементов;

Минусы:
Меньше возможностей, чем в Figma.

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

Плюсы:
Миллион плюсов

Минусы:
Миллион плюсов

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

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

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

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

Сразу дам пример, чтобы вы понимали, что вам можно будет сделать на тильде, а что нет:

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

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

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

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

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

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

Ботов можно делать не только для мессенджеров, но и для ваших веб-страниц и чатов на сайте (в виде всплывающих виджетов).

Как создавать чат-ботов буду показывать в следующих статьях в рамках данного блока «От идеи до продукта».

С чат-ботами и конструкторами разобрались, теперь переходим к более сложной и интересной части.

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

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

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

Итак,

Что такое автоматизация?

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

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

Вы просто выбираете сервисы, которыми пользуется ваша команда и назначаете в каком порядке и что они должны делать, например:

Вот такие схемы очень просто реализуются на данной платформе.

Получилось довольно объемно, закончим на этом первую часть, чуть позже продолжу.

Надеюсь, что было познавательно, если нет — клево!

Часть информации взята из эфира Никиты Наумова из Академии #Безкода

Остались вопросы?
Вы можете задать их мне, вот мои контакты:
Telegram: @kochnefff
Inst: @kochnefff