Productman

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

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

В этой статье разберемся:
• Что такое no-code и почему эта тема стала популярной;
• Какие no-code инструменты существуют и зачем они нужны;
• Как искать и выбирать под себя no-code инструменты.

1. Что еще за no-code?


Давайте начнем с нуля.
Существует довольно большое количество подходов к созданию продуктов. Большая часть из них работает по следующей схеме:
  1. Оценка рынка, анализ конкурентов;
  2. Unit-экономика проекта;
  3. Анализ ЦА, Custdev;
  4. Разработка офферов, создание прототипа;
  5. Создание MVP.
Если резюмировать эти этапы и представить их в виде стадий развития стартапа, то получится следующая таблица:



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



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

  • Команда разработки (состоит из фронтенда, бэкенда и фулстек разработчика);
  • Дизайнеры;
  • Аналитики;
  • Продакт-менеджер;

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

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

  • Senior full stack | Team lead — 200 000 руб;
  • Middle back end dev — 150 000 руб;
  • Middle front end dev — 150 000 руб;
  • QA engineer — 100 000 руб;
  • Middle product manager + analyst — 150 000 руб;
  • Senior UX|UI designer — 150 000 руб.

Аутсорс разработки — до 3 000 000 рублей.

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

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


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

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

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

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

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

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

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


В чем их отличия?


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

  • No code — платформы, которые могут использовать любые сотрудники компании или участники команды, даже не имеющие представления о том, что такое программирование;

  • Low code — для людей, имеющих технический опыт. Такие инструменты сделаны для автоматизации части рутинных задач разработчиков.

Почему я предлагаю использовать no-code метод?


Выделю 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 действительно будет необходимость переписать решения, расширить команду разработки и инвестировать в собственные технологии.

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

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

2. Какие есть инструменты и зачем они?


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

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


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


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

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

  1. Проверить гипотезы по JTBD и вашему решению проблемы клиента (следовательно сэкономить время и деньги на разработке будущего продукта);
  2. Найти кучу багов в CJM (заранее найти и убрать баги в интерфейсе), без проведения коридорных исследований идеально спроектировать интерфейс — невозможно;
  3. Продать идею (получить первых платящих клиентов до разработки).

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

2.1. Создание прототипа


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

Sketch

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


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

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

Marvel

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


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

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

Figma

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


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

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

2.2. Лендинг + личный кабинет


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

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

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

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


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

Личный кабинет + доступы


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

  • Ограниченный доступ. Часто бывает так, что продукты зарабатывают на доступе к контенту или данным — легко сделать на тильде.
  • Индивидуальное использование. Когда пользователю нужно видеть свои личные данные, прогресс и.т.п — невозможно сделать на тильде. Подойдет. Buble, Wordpress.

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

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

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


2.3. Чат-боты


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

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

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

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



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

2.4. Автоматизация процессов


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

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

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

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


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

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

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

Integromat


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


Вы просто выбираете сервисы, которыми пользуется ваша команда и назначаете в каком порядке и что они должны делать, например:
  1. Получили заявку от клиента
  2. Нужно сохранить ее в CRM систему
  3. Нужно уведомить отдел продаж
  4. Нужно отправить отбивку на почту клиенту, что с ним скоро свяжутся

Вот такие схемы очень просто реализуются на данной платформе.
Получилось довольно объемно, закончим на этом первую часть, чуть позже продолжу.
Надеюсь, что было познавательно, если нет — клево!

MVP
Made on
Tilda