BORNLI / о разработке по делу
Приложение для аренды спецтехники.
Разработаем приложение для вашей арендной компании: запрос на технику, проверка доступности, согласование изменений и подтверждение брони. Покажем этот путь на модельном сценарии и определим границы интеграции.
Арендная компания / границы разработки
Сначала найдём разрыв
между запросом и бронью.
Мобильное приложение для аренды спецтехники имеет смысл, когда клиенту или сотруднику нужен свой путь: запросить машину, проверить доступность, согласовать условия и получить подтверждение. До разработки стоит пройти этот путь в вашей действующей системе.
Когда проверить готовое решение
Если задача — вести парк, расписание и учёт аренды, начните с возможностей существующей программы. Отдельное приложение не обязательно решит то, что можно настроить внутри неё.
Когда обсуждать свой интерфейс
Например, клиент передаёт запрос в переписке, диспетчер уточняет наличие в другой системе, а результат согласования приходится переносить вручную. Разберём, какой участок действительно требует разработки.
Готовые отраслевые продукты существуют: в описании «1С:Управление автотранспортом. Такси и аренда 3» производитель прямо указывает аренду спецтехники и планирование загрузки транспорта и водителей. Это описание конкретного продукта. Оно не подтверждает, что он подходит вашей компании или что любую конфигурацию можно подключить без доработок.
Модельный сценарий / задержка возврата
Машина ещё на объекте.
Следующий заказ уже ждёт.
Представим арендную компанию: экскаватор Э-01 нужен новому клиенту 10 ноября с 09:00 до 17:00. Предыдущая аренда заканчивается в 08:00. В модели на перемещение и проверку выделен ещё час — это условие примера, а не норматив.
Возврат + час подготовки. Запрос на 09:00 укладывается в модельный план.
Возврат перенесён. Э-01 нельзя подтвердить на прежнее время.
Диспетчер предлагает другую машину либо начало с 11:00. Клиент отдельно согласует характеристики замены и время: выбор альтернативы сотрудником ещё не означает согласие заказчика.
Что и когда нужно
- Техника
- Экскаватор
- Интервал
- 10 ноября · 09:00–17:00
- Уточнить
- Объект, требования к машине, нужен ли оператор
Статус: запрос получен
Есть пересечение
- Машина
- Э-01
- Возврат ожидается
- 10:00
- Готовность по модели
- Не раньше 11:00
Требуется решение диспетчера
Предложить вариант
- Вариант А
- Другая машина после проверки характеристик
- Вариант Б
- Э-01 · 11:00–17:00
- Ответ
- Ожидаем выбор клиента
Бронь ещё не подтверждена
Зафиксировать итог
- В модели выбран
- Э-01 · 11:00–17:00
- Номер
- ДЕМО-021
- Перед сохранением
- Повторная проверка доступности и согласованных условий
Условная бронь подтверждена
Модельный сценарий BORNLI. Машина, дата, номер и обстоятельства придуманы. Это схема четырёх экранов, а не работающий сервис бронирования или клиентский проект. Кнопок отправки здесь нет; реальные брони не создаются.
Интеграция / правила доступности
Свободный день в календаре
ещё нужно подтвердить.
До оценки разработки определите, где хранится окончательное состояние каждой машины. Приложение должно различать запрос клиента, временный резерв, подтверждённую бронь, выдачу и возврат.
- Конкретная машина. По какому идентификатору связываются календарь, ремонт и бронь? Категории «экскаватор» недостаточно для проверки пересечений.
- Полный занятый интервал. Учтите не только работу на объекте, но и согласованное время перемещения и подготовки. Правила задаёт ваша команда.
- Оператор и доставка. Если машина выдаётся с оператором, проверяйте его занятость отдельно. Если для доставки нужен другой транспорт, включите его в проверку. Свободная техника сама по себе ещё не означает, что заказ можно выполнить.
- Право подтверждения. Кто меняет даты и снимает машину с выдачи? Решите, какие действия доступны клиенту, диспетчеру и ответственному за парк.
- Свежесть данных. Покажите время последнего обновления. Если учётная система не отвечает, предусмотрите статус «нужно уточнить», а не видимость подтверждённой доступности.
- Версия условий. Сохраните, какую машину, интервал и условия принял клиент. Изменение диспетчером должно требовать нового согласования там, где это предусмотрено вашим процессом.
Наличие продукта 1С само по себе не определяет способ обмена. Для оценки нужны название конфигурации, версия, доработки и описание доступного интерфейса обмена. Обещать готовый API любой базы до этой проверки нельзя.
Если основная задача — назначить водителя и контролировать выполнение поездки, это отдельный процесс: приложение для транспортной компании. Здесь разбираем доступность машины и её бронь.
Приёмка / пять проверок
Проверяем бронь
в сложных ситуациях.
Предлагаем включить эти ситуации в приёмку. Интерфейс показывает состояние, а защита от двойной брони и обработка повторов должны проверяться на работающем сервере.
Два диспетчера, одна машина
Действие: одновременно подтвердить Э-01 на пересекающиеся интервалы из двух учётных записей.
Ожидаемый результат: сохраняется одна бронь; второй диспетчер видит конфликт и может выбрать альтернативу.
Проверять серверную запись и правило пересечения, а не только заблокированную кнопку.
Ответ после отправки потерян
Действие: оборвать получение ответа, затем повторить операцию с тем же идентификатором.
Ожидаемый результат: возвращается та же бронь или её достоверный статус; повтор не создаёт вторую запись.
Нужны серверная обработка повторов и проверка состояния. Смена надписи на экране этого не доказывает.
Предыдущий возврат задержался
Действие: изменить время возврата так, чтобы оно пересеклось со следующей бронью.
Ожидаемый результат: диспетчер получает предупреждение, видит затронутый заказ и согласует замену или перенос с клиентом.
Проверять передачу изменения из учётной системы и сохранение нового согласования.
Машину отправили в ремонт
Действие: отметить ремонт между просмотром календаря и попыткой подтвердить бронь.
Ожидаемый результат: бронь не подтверждается по старым данным; клиент получает понятный следующий шаг.
Проверять актуальное состояние при подтверждении, права изменения и историю решения.
Машина свободна, оператор занят
Действие: в тестовом заказе указать обязательного оператора, занятого на другом объекте в нужный интервал. Машина при этом свободна.
Ожидаемый результат: заказ не получает окончательное подтверждение, пока диспетчер не назначит доступного оператора или не согласует другое время.
Отдельно повторить проверку для транспорта доставки, если он необходим. Проверять сохранённые назначения всех обязательных ресурсов, а не только календарь машины.
Первая версия / состав работ
Один законченный путь
от запроса до подтверждения.
Предлагаемый старт
Запрос клиента, выбор конкретной машины и интервала, проверка доступности, согласование изменения, подтверждение и история статусов. Роли и обмен определяем по вашей системе.
Оценить отдельно
Маркетплейс сторонних владельцев, телематику, онлайн-оплату, электронный документооборот и подготовку юридических документов. Они не следуют автоматически из четырёх экранов бронирования.
Для расчёта важны правила резерва, число ролей и систем, особенности текущей базы и требования к работе без связи. Ориентиры стоимости BORNLI помогают начать обсуждение, но не являются сметой приложения для вашей арендной компании. Состав, цену и сроки нужно подтвердить после разбора процесса.
Обсуждение / короткий бриф
Начнём с одной брони,
которая пошла не по плану.
Опишите обычный запрос и одно исключение: задержку возврата, замену машины или спорный резерв. Этого достаточно для первого разговора о границах разработки.
- Кто пользуется будущим приложением: клиент, диспетчер, оператор или несколько ролей?
- Где сейчас ведутся парк, календарь и ремонты? Назовите систему, версию и существенные доработки.
- Как фиксируются резерв и окончательное подтверждение? Кто вправе менять условия?
- На каком шаге сотрудник копирует данные или звонит, чтобы проверить наличие?
Используйте условные номера машин и обезличенные примеры. Пароли, рабочие доступы и данные клиентов для первого обращения не нужны. Опишите задачу в форме BORNLI — разберём процесс и обсудим, какой прототип имеет смысл подготовить.
От идеи к конкретике
Покажем, как может работать ваш продукт.
Обсудим задачу и материалы, затем подготовим бесплатный кликабельный прототип за 24 часа. До договора.
Обсудить прототип ↗