Профессия: No-Code / Low-Code разработчик

Небольшой компании нужен сайт, на котором посетитель выбирает услугу и оставляет заявку. Сотруднику нужен экран, где можно увидеть новые обращения и изменить их статус. Руководителю нужно понимать, какие заявки ещё не обработаны. Для такой системы не обязательно начинать с изучения языка программирования. Сайт можно собрать из готовых блоков, приложение — из экранов и правил, а передачу данных — из связанных модулей. Именно такими задачами занимается No-Code / Low-Code разработчик.

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

У системы будет три части. На Tilda вы сделаете сайт с описанием услуг и формой. В Bubble создадите кабинет сотрудника, где заявки можно искать, просматривать и обрабатывать. В Make настроите получение событий, проверку полей, защиту от повторов и уведомления. Затем подготовите мобильный вариант кабинета и разберётесь, когда нужен отдельный нативный проект. Эти части можно изучать по очереди; пытаться освоить три редактора в первый день не требуется.

Работа разработчика простыми словами

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

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

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

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

Какие задачи подходят для первого заработка

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

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

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

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

Как устроены инструменты книги

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

Bubble подходит для приложений, в которых есть данные и действия пользователей. Вы задаёте типы записей, создаёте интерфейс и связываете события с изменениями базы. Например, нажатие на кнопку переводит обращение из статуса New в InProgress. Мобильный веб-интерфейс открывается в браузере телефона. Нативная мобильная сборка — отдельный способ доставки приложения, который требует своих проверок.

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

Инструменты не нужно соединять любой ценой. Если для задачи достаточно формы Tilda и штатной интеграции с CRM, дополнительный сценарий Make только увеличит число зависимостей. В учебном проекте мы соединяем сервисы, чтобы освоить передачу событий. В коммерческом проекте выбирайте наименьшее количество компонентов, которое обеспечивает согласованный результат.

Доход без обещаний

Зарплата в вакансии, стоимость проекта и деньги, которые останутся у исполнителя, — разные величины. Из выручки оплачиваются подписки, подрядчики, налоги и время на поиск клиентов. Поэтому нельзя оценить профессию по одной красивой сумме из объявления. В книге используются учебные расчёты, а не обещания определённого заработка.

Например, вы оценили небольшой сайт в 32 000 рублей. На согласование, сборку, проверку и передачу ушло 28 часов. Ещё восемь часов заняли переговоры и подготовка предложения. При расходах 4 000 рублей остаётся 28 000 рублей до налогов. Деление на 36 часов даёт примерно 778 рублей за час. Это условный расчёт; он полезен тем, что учитывает работу, которую обычно забывают включить в цену.

Для исследования рынка соберите собственную небольшую выборку. Найдите не менее десяти свежих вакансий по словам Tilda, Bubble, no-code, low-code, интеграции и автоматизация. Выпишите обязанности, обязательные инструменты, опыт, формат занятости и указанное вознаграждение. Отдельно отметьте суммы до вычета налогов и на руки. Не объединяйте оплату по проекту с месячной зарплатой.

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

Как учиться с этой книгой

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

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

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

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

Практика выбора первой услуги

Запишите три задачи, которые вы готовы освоить: например, сайт локального сервиса, кабинет менеджера и уведомления о новых обращениях. Для каждой укажите конкретного пользователя, проблему и способ проверки. Формулировка «помочь бизнесу» слишком широка. Подойдёт «сотрудник видит все необработанные заявки в одном списке и открывает нужную за два действия».

Затем выберите одну задачу для первого предложения. Опишите её пятью предложениями: кому нужна, что вы соберёте, какие материалы потребуются, что не входит в работу и как будет происходить приёмка. Пока не назначайте цену. Сначала нужно понять объём, иначе сумма станет случайной.

Для нашей мастерской начальное предложение звучит так: «Соберу сайт с тремя услугами и учебной формой обращения. Размещу описание порядка ремонта, ответы на вопросы и кнопку перехода к форме. Проверю страницу на компьютере и телефоне. Для запуска потребуются утверждённые тексты, фотографии и сведения об организации. Готовность подтвердим проверкой всех ссылок и доставкой тестовой заявки».

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

Работа начинается с разговора о процессе. Если мастерская говорит «нам нужен сайт и приложение», ещё неизвестно, какая задача стоит перед компанией. Возможно, достаточно исправить форму на существующей странице. Возможно, сайт уже привлекает посетителей, а проблема заключается в том, что обращения никто не назначает сотрудникам. Разработчик сначала выясняет, где возникают потери, затем предлагает решение.

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

Разговор о текущем процессе

Попросите заказчика описать последнее типичное обращение по шагам. Где человек нашёл мастерскую? Что написал? Кто получил сообщение? Где сохранили контакт? Как назначили ответственного? Что произошло, когда сотрудник заболел? Такие вопросы помогают увидеть действительные действия вместо общего описания «работаем через мессенджеры».

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

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

Результат разговора запишите коротким описанием. Например: «Заявки поступают через сайт. Администратор проверяет их и назначает исполнителя. Исполнитель видит только назначенные ему обращения. После контакта он меняет статус. Руководитель смотрит общий список и просроченные задачи». Здесь уже есть участники, действия и ограничения доступа.

Первая версия системы

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

В нашей версии посетитель выбирает одну из трёх услуг, указывает тестовый способ связи и отправляет обращение. Администратор видит список, открывает запись и назначает сотрудника. Сотрудник меняет статус New на InProgress, затем на Done или Cancelled. Make отправляет уведомление о новой записи и регистрирует результат обработки события.

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

У каждой функции должен быть пользователь и причина. «Красивый личный кабинет» не помогает оценить работу. «Сотрудник открывает назначенную заявку и видит услугу, описание и текущий статус» уже можно проверить. Если функция не поддерживает основной путь и не устраняет значимый риск, её разумно отложить.

Требования и критерии приёмки

Требование описывает, что система должна делать. Критерий приёмки объясняет, как вы докажете, что она это делает. Удобно записывать их рядом. Для формы требование — обязательный выбор услуги. Критерий — при отправке без выбора запись не создаётся, а пользователь видит понятное сообщение возле поля.

Для списка сотрудника требование — показать только назначенные обращения. Критерий — под первой учётной записью видна заявка A, под второй — заявка B; попытка открыть чужую запись по прямой ссылке не раскрывает её содержимое. Проверка только внешнего вида списка недостаточна: нужно проверить доступ к самой записи.

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

Пишите критерии так, чтобы их мог повторить человек, не участвовавший в разработке. Укажите исходные данные, действие и ожидаемый результат. «Форма работает корректно» ничего не объясняет. «Отправить service_code=washer с event_id=E-101; в журнале должна появиться одна запись со статусом received» — проверяемое утверждение.

Пользовательские роли

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

В учебной системе гость видит публичные услуги и форму. Исполнитель читает назначенные ему обращения и меняет разрешённые статусы. Администратор читает все обращения, назначает исполнителей и исправляет ошибочные сведения. Ни один пользователь через обычный профиль не может самостоятельно сделать себя администратором.

Разделите чтение, создание, изменение и удаление. Если человек может читать запись, из этого не следует право менять её. Если администратор может исправить описание, из этого не следует право незаметно удалить историю. Удаление особенно опасно: оно может уничтожить доказательства ошибки. В первой версии лучше использовать признак archived и скрывать запись из обычного списка.

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

Состояния обращения

Статус должен описывать состояние процесса, а не настроение сотрудника. Мы используем четыре значения: New — получено; InProgress — принято в работу; Done — завершено; Cancelled — отменено. Названия можно показать пользователю по-русски, сохранив постоянные технические коды.

Разрешённые переходы задаются отдельно. New можно перевести в InProgress или Cancelled. InProgress — в Done или Cancelled. Возврат из Done в работу требует решения администратора и записи причины. Если разрешить любой переход любой кнопкой, отчёт о выполненных обращениях быстро перестанет быть надёжным.

Статус обработки события в Make относится к другой сущности. Received означает, что событие принято; processed — что его действие завершено; failed — что нужна повторная обработка или разбор. Не смешивайте эти значения со статусом ремонта. Обращение может находиться в New, хотя уведомление о нём уже processed.

У каждого статуса должен быть ответственный за дальнейшее действие. Для New это администратор, для InProgress — назначенный исполнитель. Если у записи нет исполнителя, не позволяйте переводить её в InProgress без отдельного правила. Такой небольшой запрет предотвращает появление задач, которые формально в работе, но фактически никому не принадлежат.

Что нужно получить от заказчика

До начала сборки запросите тексты услуг, фотографии с правом использования, контактные сведения организации, доступ к домену, сведения о существующей CRM и ответственного за согласование. Уточните, кто владеет аккаунтами сервисов и кто оплачивает подписки. Сайт на личном аккаунте разработчика становится проблемой, если сотрудничество прекращается.

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

Отдельно составьте перечень данных. Для учебной формы достаточно кода услуги и вымышленного контакта. Для реального сервиса заказчик определяет цель обработки, необходимый состав сведений и правовое основание. Не добавляйте дату рождения, адрес и паспортные данные «на всякий случай». Каждое поле усложняет защиту, поддержку и объяснение пользователю.

Задание на одну страницу

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

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

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

Работа с новой просьбой

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

Опишите просьбу, её причину и влияние. Затем предложите выбор: заменить часть согласованного объёма, перенести функцию в следующую версию или увеличить бюджет и срок. Это нормальное управление проектом. Конфликт возникает, когда изменение молча принимают, а позже называют дополнительные деньги.

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

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

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

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

Клиент и сервер

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

Данные, уже отправленные в браузер, нельзя надёжно защитить скрытием элемента. Пользователь может изучить полученный ответ техническими средствами. Поэтому ограничение доступа должно действовать до передачи сведений. В Bubble для чтения используются privacy rules, а изменение через workflows требует собственных проверок условий и полномочий.

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

Адрес, домен и

HTTPS

URL — адрес конкретного ресурса. Домен — понятное человеку имя сайта. Путь после домена указывает на страницу или другой ресурс. Параметры после вопросительного знака передают дополнительные значения. Например, в учебном адресе https://example.com/request?id=R-101 значение id обозначает нужную запись. Само наличие такого значения не предоставляет право читать её.

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

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

Типы значений

Текст подходит для описания и кода услуги. Число — для количества и арифметики. Дата — для момента создания или запланированного действия. Логическое значение принимает два состояния, например yes/no. Ссылка на запись связывает сущности: у обращения есть назначенный пользователь.