Решение, определившее трёхнедельное внедрение в прокате
На столе лежали три правдоподобных варианта, и два из них занимали месяцы. Разницу сделало решение о том, какой записи разрешено быть правой.
С чем нас оставили замеры
Неделя подсчётов дала одну находку, изменившую проект: машины, физически стоящие на площадке, числились недоступными достаточно часто, чтобы объяснить и двойные брони, и часть отказов.
Это утверждение про данные, а не про людей. Выйди счётчик около нуля, честным выводом было бы, что сотрудники перегружены, а лечение это люди или маршрутизация. Он не вышел около нуля, значит ответ лежал в том, как записывалась доступность.
Дальше было три варианта. Два из них занимали месяцы.
Три варианта
| Вариант | Срок | Почему отвергнут или выбран |
|---|---|---|
| Заменить учётную систему | Месяцы | Чинит одно поле миграцией всего, посреди сезона |
| Поставить модель поверх таблиц | Недели | Отвечает по неверным данным быстрее и непрослеживаемо |
| Одна главная запись, реальные состояния | 3 недели | Чинит именно то, что было сломано |
Первый вариант предлагают чаще всего, когда виновата модель данных, и обычно это ответ неверного масштаба. Замена мигрирует историю, переобучает всех и держит две наполовину доверенные системы параллельно, и всё это ради одного поля. В сезонном бизнесе делать это в те месяцы, когда операционка и так напряжена, не деталь.
Второй вариант было бы легче всего продать. Модель, читающая существующие таблицы и отвечающая на вопросы о доступности, хорошо смотрится на демонстрации и ломается ровно так, как замеры уже предсказали: данные говорят, что машина недоступна, пока она стоит на площадке, а модель повторяет это с большей уверенностью и меньшей прослеживаемостью, чем таблица.
Почему модель эту работу не получила
Под этим конкретным выбором лежит общее правило, и его стоит отделить от частностей.
Проверка доступности обязана возвращать один и тот же ответ на один и тот же вопрос каждый раз и обязана объясняться потом, когда клиент спросит, почему ему отказали. Вероятностный ответ на детерминированный вопрос это дефект, и улучшение модели этого не меняет.
Поэтому в готовой системе модель получила ровно одну работу: чтение заявок, приходящих свободным текстом в одиннадцать вечера, где машина названа словами клиента, а даты записаны в форме, которой не ждёт ни одно поле. Для правила это по-настоящему трудно, для модели по-настоящему легко. Полное разделение изложено в посте куда уходят четыре часа.
Что изменило выбранное решение
Две вещи, и вторая весила больше.
Доступность перестала быть одним полем «да или нет» и стала семью явными состояниями, поэтому машина, вернувшаяся и ждущая осмотра, машина в пути и машина, забронированная без подтверждения, перестали показываться свободными.
Затем одна запись стала главной по тому, что забронировано, а проверка переехала на момент подтверждения вместо момента заявки. Эта вторая правка и прекратила двойные брони, потому что конфликты жили в окне между «посмотрел в общую таблицу» и «пообещал машину».
Ни одна из правок не экзотика. Ни одна не потребовала новых технологий. Обе потребовали решения, которое кто-то должен был принять и которого никто не принимал.
Цена, которой нет ни в одном предложении
Сделать одну запись главной значит, что кто-то должен перестать вести свою копию.
В любой такой операционке есть один-два человека с личной таблицей, и они не вредничают. Они завели её потому, что когда-то официальная система ошиблась, а их таблица оказалась права, и с тех пор она тихо держала бизнес.
Попросить их довериться системе, которая их подводила, и есть настоящая работа, и просьба ложится совершенно по-разному в зависимости от того, выслушали ли сначала их возражение. Именно эта часть ближе всего подошла к срыву проекта. Её нет ни в одном коммерческом предложении, включая наши ранние, и поэтому решение об источнике правды мы теперь проговариваем в начале, а не обнаруживаем на второй неделе.
Что это дало
Путь от брони до отгрузки ушёл с 4 часов до 3 минут. Двойные брони исчезли. Ёмкость пикового сезона выросла в 2,5 раза той же командой, а внедрение уложилось в 3 недели. Полный набор на странице кейса.
Три недели это следствие решения, а не скорости. Два отвергнутых варианта не были медленными версиями того же проекта, это были другие проекты, и один из них закончился бы примерно к концу сезона.
Переносимая часть
До согласия на что-либо найдите факт, о котором две ваши системы расходятся, и решите, какая из них главнее.
Это решение стоит ноль, занимает полдня и определяет размер каждого следующего проекта. Замер, который его вскрывает, описан в посте неделя до, и по той же причине противоречивые данные это единственный сорт бардака, вокруг которого не стоит автоматизировать, пока у вопроса нет ответа.
01Почему не поменять учётную систему, раз проблема была в модели данных?+
Потому что модель данных была неверна в одном конкретном месте, а не повсюду, а замена системы ради одного поля это проект на месяцы, несущий риски, никак не связанные с исходной проблемой. Замена означает миграцию истории, переобучение всех и период параллельной работы двух систем, каждой из которых доверяют наполовину. Она же сажает всю операционку на новый инструмент ровно в те месяцы, когда операционка и так на пределе, а в сезонном бизнесе выбор момента это не деталь. Более узкое лечение состояло в том, чтобы оставить существующей системе то, что она держала верно, и сделать одну запись главной по единственному, в чём она ошибалась, то есть по броням на единицы техники. Это недели вместо месяцев, и это оставляет возможность заменить систему позже, а не тратит её сейчас.
02Чем плоха была языковая модель поверх существующих таблиц?+
Она отвечала бы на вопрос о доступности быстрее и ровно так же неверно, а это исход хуже, чем отвечать медленно. Замеры уже установили, что исходные данные показывают машины недоступными, пока те стоят на площадке, и модель, читающая эти данные, воспроизводит ошибку с большей уверенностью и меньшей прослеживаемостью. Есть и более тонкая проблема, которую стоит назвать, потому что она повторяется в большинстве проектов, где модель предлагают как короткий путь: проверка доступности обязана возвращать один и тот же ответ на один и тот же вопрос каждый раз и обязана поддаваться объяснению потом, когда клиент спросит, почему ему отказали. Вероятностный ответ на детерминированный вопрос это дефект независимо от качества модели. Место в готовой системе модель заработала, но у входной двери, на неструктурированных заявках, а это работа, которую правило действительно не выполнит.
03Что конкретно изменило выбранное решение?+
Две вещи, и вторая была важнее. Во-первых, доступность перестала быть единственным полем «да или нет» и стала явным набором состояний, поэтому машина, вернувшаяся и ждущая осмотра, машина в пути и машина, забронированная без подтверждения, перестали показываться свободными. Во-вторых, одна запись стала главной по тому, что забронировано, а проверка доступности переехала на момент подтверждения вместо момента заявки. Именно вторая правка убрала двойные брони, потому что конфликты жили в окне между тем, как человек посмотрел в общую таблицу, и тем, как он пообещал машину. Ни одна из правок не является экзотикой, ни одна не потребовала новых технологий. Обе потребовали решения, которое кто-то должен был принять и которого никто не принимал, и в этом обычная форма таких проектов.
04Чего это решение стоило?+
Кому-то пришлось перестать вести собственную копию, и это политическая цена, а не техническая. На практике в любой такой операционке есть один-два человека с личной таблицей, и обычно потому, что когда-то официальная система ошиблась, а их таблица оказалась права. Эти люди не вредничают: они держат тот самый обходной путь, на котором бизнес и работал. Сделать одну запись главной значит попросить их довериться системе, которая их уже подводила, и такая просьба ложится совершенно по-разному в зависимости от того, выслушали ли сначала их возражение. Это та часть проекта, которая ближе всего подошла к тому, чтобы его сорвать, она не встречается ни в одном коммерческом предложении, включая наши ранние, и поэтому решение об источнике правды мы теперь проговариваем в самом начале, а не обнаруживаем на второй неделе.
