Как один человек заменил инструмент за 40 тысяч в год тем, что построил за день

Марта руководила операциями в логистической компании на 30 человек в Гвадалахаре. Её команда пользовалась корпоративной платформой для управления проектами, которая обходилась им примерно в 40 000 долларов в год — лицензии по числу мест, премиум-тариф ради функций отчётности плюс консультант, которого они наняли для настройки первоначальных процессов два года назад.

Вот что никто в команде не хотел говорить вслух: пользовались они примерно 15 % этого.

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

Момент, когда всё сложилось

В феврале подошло продление контракта. Марта уже больше года твердила себе, что перейдёт на что-то подешевле «в следующем квартале». Но в этот раз подруга, которая вела небольшой e-commerce-бренд, сказала ей кое-что, что засело: «Я перестала искать подходящий инструмент и просто описала ИИ, что мне нужно. Он это построил.»

Марта не была разработчиком. Когда-то она прошла курс по Python и бросила его после третьей недели. Но свои собственные рабочие процессы она понимала лучше кого бы то ни было. Она могла точно описать, что нужно её команде, потому что жила внутри этих процессов каждый день.

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

Что она на самом деле построила

В субботу утром Марта села с ИИ-конструктором приложений и начала описывать, что ей нужно, по одной части за раз.

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

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

Недельный отчёт. Цифры, которые Марта реально выгружала каждую пятницу: всего доставок, процент вовремя, проблемы, отмеченные водителями (вроде неверного адреса или того, что клиента не было дома), и сравнение с прошлой неделей. Она попросила конструктор сгенерировать сводную таблицу и простую столбчатую диаграмму. Он сделал.

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

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

За что на самом деле платились 40 000 долларов

Когда Марта сравнила своё приложение из четырёх экранов с корпоративной платформой, разрыв был очевиден — но не в ту сторону, что она ожидала.

У корпоративного инструмента были сотни функций, и для настройки требовался консультант. У приложения Марты было четыре экрана, которые напрямую соответствовали тому, как её команда уже работала. Никакого обучения. Никакого долга по настройке.

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

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

Что её удивило

Три вещи, которых Марта не ожидала:

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

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

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

Чем это не является

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

Но если вы команда на 30 человек, использующая 15 % инструмента, который стоит дороже одного из ваших сотрудников, что-то не сходится. Проблема не в инструменте — проблема в несоответствии.

И это несоответствие раньше было неизбежным. До того как можно было построить приложение без программирования, вашим выбором было: платить за большой инструмент, склеить что-то в таблицах или нанять разработчика, чтобы построить заказной софт (что несёт свои затраты и сроки). Теперь есть четвёртый вариант: описать, что вам нужно, и построить это самому.

Математика

Цифры Марты спустя месяц:

• Корпоративный инструмент: ~3 300 $/месяц (40 тыс. $/год)
• Подписка на ИИ-конструктор: меньше 100 $/месяц
• Время на построение: 8 часов (одна суббота)
• Время на итерацию: 20–30 минут на изменение
• Время на принятие командой: ноль — они освоились в первый же день

Ей не понадобились ни CTO, ни инженерная команда. Ей понадобилось описать, как её команда на самом деле работает, — и ИИ-конструктор приложений, который превратил это описание в работающий софт.

О чём стоит подумать

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

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

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

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