КЛЮЧЕВОЕ РЕШЕНИЕ

Ограничить MVP одним проверяемым сценарием

Собрать сквозной путь: регистрация баллона, создание GM-кода, считывание и проверка данных. Задавать AI контекст и критерии проверки каждого шага.

КАКИЕ РЕШЕНИЯ СРАБОТАЛИ

  1. Определить сквозной сценарий и границы MVP

    В первую версию вошли регистрация объекта, реестр, создание метки и проверка считывания. Такой объём позволял проверить рабочий цикл до разработки полной системы.

  2. Давать AI задачу вместе с проверкой

    Работу разбивала на конкретные шаги: контекст, ожидаемое поведение, реализация и проверка. Наличие работающего интерфейса не заменяло проверку данных на выходе.

  3. Проверять тем же механизмом, который нужен в целевом сценарии

    Приёмка проверяла не только возможность прочитать изображение, но и точность восстановленных данных. Отдельно зафиксированы границы теста: чистые PNG не заменяют испытания напечатанной метки на реальном объекте.

Что проходила каждая тестовая метка
  1. СозданиеУникальные тестовые данные
  2. РаспознаваниеПроверка чтения PNG
  3. СверкаСовпадение восстановленных данных

В программной приёмке от 9 сентября 2026 года успешно проверены 1000 из 1000 чистых PNG. Полевые условия — отдельный этап.

Задача: проверить систему в работе

В текущем проекте ГИС СУБ я работаю над системой регистрации газовых баллонов и их идентификации по меткам Grid Matrix. На старте важно было получить работающий путь: зарегистрировать объект, сформировать код, прочитать его и сопоставить данные с реестром.

Я использовала AI в разработке MVP. Отправной точкой были предметная задача, модель данных и понятный результат для проверки.

Что вошло в MVP

  • Регистрация баллонов и работа с реестром.
  • Генерация кодов Grid Matrix (GM) в PNG.
  • Чтение кода из файла и с камеры, проверка данных.
  • Локальная сборка для Mac и офлайн-пакет для Windows.

Как я выстраиваю работу с AI

Я задаю логику продукта и критерии готовности. AI подключаю к реализации, разбору ошибок и проверкам. Задачи разбиваю на части, для каждой фиксирую ожидаемый результат.

Требования, принятые решения и состояние проекта сохраняю в репозитории контекста. Это помогает продолжать работу между сессиями и инструментами, не восстанавливая историю по памяти.

При работе с кодами проверяю всю цепочку: генерацию, формат изображения, чтение и совпадение полей. Успешный запуск интерфейса сам по себе не подтверждает, что цепочка работает.

Результат, который можно проверить

За три недели появился работающий MVP. В программной приёмке выбранное ядро распознало 1000 из 1000 уникальных чистых PNG с проверкой данных.

Это результат проверки цифровых изображений. Печать, нанесение меток на баллоны и чтение в реальных условиях требуют отдельной проверки. Так я разделяю готовность MVP и готовность к эксплуатации.

Что этот кейс даёт бизнесу

Работающий MVP позволяет раньше проверить сценарии и обнаружить ограничения. Вместо обсуждения только сметы и сроков можно разбирать конкретную реализацию: что работает, что нужно изменить и какие испытания провести дальше.

В этом для меня ценность AI: быстрее переходить от требований к проверяемому результату, сохраняя ответственность за постановку задачи и качество решений.

Мой принцип

Сначала — задача, данные и критерии проверки. Затем — работа с AI короткими итерациями. На выходе — результат и доказательства того, что именно проверено. Практиками делюсь в «ИТ-коктейле».

40 млн ₽ и 9 месяцев — исходная оценка разработки. 3 недели — срок создания MVP. Эти данные не являются расчётом фактической экономии: объём MVP и полного внедрения различается.

ВЫВОД

Быстрый MVP проверяет подход

Три недели до MVP нельзя напрямую сравнивать с оценкой полной промышленной системы в 40 млн ₽ и девять месяцев. Проверка 1000 чистых PNG подтверждает работу на тестовом наборе; печать и полевые условия требуют отдельных испытаний.