Десятки итераций в день: почему скорость разработки — наше главное оружие
В классическом IT-цикле путь от обнаружения проблемы до исправления выглядит так: пользователь нашёл баг, написал тикет, тикет попал в бэклог, менеджер расставил приоритеты, разработчик взял в спринт, через две недели выкатили фикс, ещё через неделю он доехал до продакшена. Шесть недель от «не работает» до «починили». Для банковского приложения — нормально. Для системы, которая управляет сотнями единиц техники в реальном времени — смерть.
Карьер не ждёт спринта. Если балансировщик на конкретном забое выдаёт рекомендацию, которая формально правильна, но в реальных условиях не работает — каждая следующая смена теряет деньги, пока разработка «берёт задачу в работу». Мы проходили через это на ранних этапах и быстро поняли: единственный способ строить продукт для тяжёлой индустрии — сжать цикл обратной связи до часов, а не недель.
Вот как это устроено сейчас. Координатор ROC работает в смене и видит, что агент пересменки назначает точки, которые не учитывают фактическое расположение автобуса. Он фиксирует проблему — не в тикете, а в прямом канале с разработкой. Через час инженер видит данные, воспроизводит ситуацию и понимает, что алгоритм не учитывал задержку автобуса на южном маршруте.
Ещё через два часа — исправление в тестовой среде. К вечеру — на продакшене. Следующая смена работает уже с обновлённой логикой.
Десятки таких итераций в день — не фигура речи. Каждая мастер-смена генерирует поток обратной связи, который моментально уходит в разработку. На августовской мастер-смене мы увидели ситуации, когда AI-агент принимал формально правильное решение, но в контексте конкретного забоя оно не работало — операторы не выполняли рекомендацию, и были правы. Часть оповещений приходила слишком поздно — когда водитель уже решил проблему сам. Всё это не легло в квартальный план доработок. Это ушло в работу в тот же день, и к следующей мастер-смене система вела себя иначе.
Почему это возможно? Три вещи.
Первое — архитектура. OES — облачная платформа, обновления доставляются без выезда на площадку, без остановки системы, без пересогласований с IT-отделом предприятия. Новая версия агента — это не «перевнедрение», а переключение конфигурации.
Второе — близость к производству. Наши координаторы ROC — это не сотрудники техподдержки, которые читают тикеты. Это люди, которые работают в смене, видят экраны, слышат рацию и понимают контекст каждого решения системы. Когда они говорят «здесь не работает» — они объясняют почему на языке производства, а не на языке баг-репорта.
Третье — культура. У нас нет священных коров в коде. Если мастер-смена показала, что логика агента ошибочна — она переписывается, а не защищается. Алгоритм, который красиво выглядит в теории, но не работает в забое при минус тридцати — это не алгоритм, это гипотеза, которую реальность опровергла.
В горнодобыче за последние тридцать лет производительность почти не выросла — при том, что технологии менялись радикально.
Одна из причин: внедрение каждой новой системы занимало годы, и к моменту запуска она уже устаревала. Мы убеждены, что скорость итерации — это не техническая характеристика. Это стратегическое преимущество, которое определяет, кто выиграет в гонке за эффективность тяжёлой индустрии.
#HeavyAI #OES
В классическом IT-цикле путь от обнаружения проблемы до исправления выглядит так: пользователь нашёл баг, написал тикет, тикет попал в бэклог, менеджер расставил приоритеты, разработчик взял в спринт, через две недели выкатили фикс, ещё через неделю он доехал до продакшена. Шесть недель от «не работает» до «починили». Для банковского приложения — нормально. Для системы, которая управляет сотнями единиц техники в реальном времени — смерть.
Карьер не ждёт спринта. Если балансировщик на конкретном забое выдаёт рекомендацию, которая формально правильна, но в реальных условиях не работает — каждая следующая смена теряет деньги, пока разработка «берёт задачу в работу». Мы проходили через это на ранних этапах и быстро поняли: единственный способ строить продукт для тяжёлой индустрии — сжать цикл обратной связи до часов, а не недель.
Вот как это устроено сейчас. Координатор ROC работает в смене и видит, что агент пересменки назначает точки, которые не учитывают фактическое расположение автобуса. Он фиксирует проблему — не в тикете, а в прямом канале с разработкой. Через час инженер видит данные, воспроизводит ситуацию и понимает, что алгоритм не учитывал задержку автобуса на южном маршруте.
Ещё через два часа — исправление в тестовой среде. К вечеру — на продакшене. Следующая смена работает уже с обновлённой логикой.
Десятки таких итераций в день — не фигура речи. Каждая мастер-смена генерирует поток обратной связи, который моментально уходит в разработку. На августовской мастер-смене мы увидели ситуации, когда AI-агент принимал формально правильное решение, но в контексте конкретного забоя оно не работало — операторы не выполняли рекомендацию, и были правы. Часть оповещений приходила слишком поздно — когда водитель уже решил проблему сам. Всё это не легло в квартальный план доработок. Это ушло в работу в тот же день, и к следующей мастер-смене система вела себя иначе.
Почему это возможно? Три вещи.
Первое — архитектура. OES — облачная платформа, обновления доставляются без выезда на площадку, без остановки системы, без пересогласований с IT-отделом предприятия. Новая версия агента — это не «перевнедрение», а переключение конфигурации.
Второе — близость к производству. Наши координаторы ROC — это не сотрудники техподдержки, которые читают тикеты. Это люди, которые работают в смене, видят экраны, слышат рацию и понимают контекст каждого решения системы. Когда они говорят «здесь не работает» — они объясняют почему на языке производства, а не на языке баг-репорта.
Третье — культура. У нас нет священных коров в коде. Если мастер-смена показала, что логика агента ошибочна — она переписывается, а не защищается. Алгоритм, который красиво выглядит в теории, но не работает в забое при минус тридцати — это не алгоритм, это гипотеза, которую реальность опровергла.
В горнодобыче за последние тридцать лет производительность почти не выросла — при том, что технологии менялись радикально.
Одна из причин: внедрение каждой новой системы занимало годы, и к моменту запуска она уже устаревала. Мы убеждены, что скорость итерации — это не техническая характеристика. Это стратегическое преимущество, которое определяет, кто выиграет в гонке за эффективность тяжёлой индустрии.
#HeavyAI #OES