Як одна людина замінила інструмент за 40 тис. $/рік чимось, що побудувала за день

Марта керувала операціями в логістичній компанії на 30 осіб у Гвадалахарі. Її команда користувалася корпоративною платформою для керування проєктами, що коштувала їм близько 40 000 доларів на рік — ліцензування за місце, преміум-рівень заради функцій звітності плюс консультант, якого вони найняли два роки тому, щоб налаштувати початкові процеси.

Ось чого ніхто в команді не хотів казати вголос: вони використовували, мабуть, 15 % цього.

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

Момент, коли все зійшлося

У лютому настало поновлення контракту. Марта понад рік казала собі, що мігрує на щось дешевше «наступного кварталу». Але цього разу подруга, що керувала невеликим e-commerce-брендом, сказала їй те, що засіло: «Я перестала шукати правильний інструмент і просто описала те, що мені потрібно, ШІ. Він це побудував».

Марта не була розробницею. Вона якось пройшла курс із Python і кинула його після третього тижня. Але вона розуміла власні процеси краще за будь-кого. Вона могла точно описати, що потрібно її команді, бо жила всередині цих процесів щодня.

Вона вирішила спробувати побудувати заміну сама, перш ніж підписувати поновлення.

Що вона насправді побудувала

Марта сіла суботнього ранку з конструктором на ШІ й почала описувати те, що їй потрібно, частина за частиною.

Екран фіксації маршрутів. Водіям треба було відмічатися на початку зміни, бачити призначені зупинки й позначати кожну як завершену. Жодних діаграм Ганта з перетягуванням — просто список із чекбоксами й позначкою часу. Вона описала це простою іспанською й спостерігала, як конструктор генерує робочий інтерфейс із базою даних за ним.

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

Щотижневий звіт. Цифри, які Марта справді витягувала щоп’ятниці: усього доставок, відсоток вчасних, проблеми, позначені водіями (як-от хибна адреса чи відсутність клієнта вдома), і порівняння з попереднім тижнем. Вона попросила конструктор згенерувати зведену таблицю й просту стовпчасту діаграму. Він зробив.

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

Усе разом зайняло близько восьми годин, розкиданих по суботі. Не тому, що якась окрема частина була складною, а тому, що Марта постійно доводила до ладу. Перша версія дашборда диспетчера показувала забагато даних. Вона її обрізала. Екран фіксації маршрутів потребував опції «пропустити зупинку», про яку вона спершу не подумала. Вона додала її, описавши зміну.

Що насправді купували за 40 000 доларів

Коли Марта порівняла свій застосунок із чотирьох екранів із корпоративною платформою, розрив був очевидним — але не в той бік, на який вона очікувала.

Корпоративний інструмент мав сотні функцій і вимагав консультанта для налаштування. Застосунок Марти мав чотири екрани, що напряму мапилися на те, як її команда вже працювала. Жодного навчання. Жодного боргу на налаштування.

Але справжньою ціною корпоративного інструмента ніколи не була підписка. Це було тертя, яке її команда щодня обходила. Диспетчери координувалися через WhatsApp, бо мобільний застосунок платформи вимагав чотирьох дотиків, щоб оновити статус доставки. Марта вела окрему Google Таблицю для щотижневого звіту, бо вбудований модуль звітності вимагав пройти три меню, щоб витягти ті самі п’ять чисел. Водії додали в закладки обхідну сторінку в довідці для екрана фіксації маршрутів, бо стандартний потік припускав фази проєкту, яких вони не використовували.

Застосунок Марти не мав обхідних шляхів, бо був побудований з обхідних шляхів. Кожен екран існував, бо хтось у команді робив це завдання неформально — у WhatsApp, у таблиці, на дошці — і Марта просто описала неформальну версію конструктору.

Частини, що її здивували

Три речі, яких Марта не очікувала:

Ітерація була швидкою. Коли водій запропонував додати поле нотаток до кожної зупинки, Марта описала зміну конструктору під час обідньої перерви й розгорнула її того ж пообіддя. З корпоративним інструментом такі зміни проходили через чергу тикетів підтримки й іноді тривали тижнями.

Її команда прийняла це одразу. Жодних навчальних сеансів. Жодного «будь ласка, перегляньте це відео онбордингу». Диспетчери відкрили його в понеділок уранці й зрозуміли, бо воно виглядало як дошка, якою вони неформально користувалися, тільки цифрова.

Вона продовжувала його вдосконалювати. Наступні два тижні вона додала п’ятий екран: місячний вигляд для свого керівника, що показує тренди доставок і оцінки вартості за маршрут. З корпоративним інструментом це був би запит на кастомний звіт. Зі своїм застосунком — 20-хвилинна розмова з конструктором.

Чим це не є

Це не історія про те, що корпоративний софт поганий. Якщо ви компанія на 500 осіб, що веде складні крос-функціональні проєкти з залежностями, обмеженнями ресурсів і вимогами відповідності, вам, мабуть, потрібен той швейцарський ножик.

Але якщо ви команда на 30 осіб, що використовує 15 % інструмента, який коштує більше за одного з ваших працівників, щось не збігається. Проблема не в інструменті — проблема в невідповідності.

І ця невідповідність раніше була неминучою. Перш ніж ви могли побудувати застосунок без програмування, вашими варіантами були: платити за великий інструмент, склеїти щось у таблицях чи найняти розробника, щоб побудувати кастомний софт (що приносить власні витрати й терміни). Тепер є четвертий варіант: описати, що вам потрібно, і побудувати це самому.

Математика

Цифри Марти за один місяць:

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

Їй не знадобився CTO чи інженерна команда. Їй потрібно було описати, як насправді працює її команда, — і конструктор на ШІ, що перетворив цей опис на робочий софт.

Над чим подумати

Якщо ви впізнаєте власну ситуацію в історії Марти, ось корисна вправа перед наступним поновленням софту: запишіть кожну функцію, якою ви справді користуєтеся у своєму нинішньому інструменті. Не функції, якими, на вашу думку, маєте користуватися чи плануєте колись. Ті, яких ваша команда торкається щотижня.

Якщо цей список уміщається на стікері, ви, можливо, переплачуєте за складність, яка вам не потрібна.

Вам не обов’язково будувати заміну за день. Ви могли б почати лише з одного екрана — того, що має найбільше значення, — і подивитися, як воно. Ціна спроби — кілька годин. Ціна не-спроби — ще рік оплати функцій, яких ви ніколи не торкнетеся.

Якщо хочете побачити, як виглядає побудова власного інструмента, спробуйте Proyecta і почніть із того, на що ваша команда скаржиться найбільше.