Разработчики не экстрасенсы: как мы перестали приносить туман вместо ТЗ

Кейс про вагоны, Claude и то, зачем аналитику иногда полезно «потрогать» будущую систему до разработки. Это не история о том, как ИИ заменил разработчиков. Скорее наоборот: это история о том, как аналитикам перестать приносить разработчикам красивый документ, внутри которого всё ещё туман.

Хотим видеть, где наши вагоны, и оставлять к ним комментарии.

Требование звучало почти безобидно. На первый взгляд — обычная задача для отчёта. Есть поток дислокации, есть номера вагонов, станции, остаток пути, номер поезда. Показываем всё в таблице, добавляем фильтры, рядом поле для комментария — готово.

Мы так и начали: собрали витрину в Apache Superset на живых данных.

Выглядело нормально. Даже красиво.

Через несколько обсуждений стало ясно: бизнесу нужен не отчёт. Бизнесу нужна система. Отчёт показывает данные. Система помогает работать. Это разные вещи. Оператору нужно не просто увидеть вагон, а понять, что с ним происходит. Оставить комментарий не «на номер вагона вообще», а на конкретную ситуацию. Подготовить приёмку. Связать вагон с накладной. Разобраться, почему вагон в одном составе, потом в другом. Передать итоговые данные дальше в учётную систему.

И вот тут простая фраза «видеть вагоны» начала разворачиваться в предметную область.

• Вагон — не всегда просто вагон

Один и тот же физический вагон может приезжать несколько раз за год. Значит, нужен не только вагон, но и рейс вагона.

• Поезд — не фундамент модели

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

• Дислокация — это поток

Данные приходят событиями: операция, станция, время, остаток пути, номер поезда. Это не статичная таблица.

• ЭТРАН приносит не только пользу

Накладные дают данные о грузе и контейнерах, но вместе с ними приходят грязные номера, плейсхолдеры и неоднозначные связи. Так из одной фразы выросла система с рейсами, статусами, комментариями, ЭТРАН-накладными, синхронизацией и подготовкой данных для 1С.

«А что должно быть, если?..» — момент, когда ТЗ начинает трещать

В IT есть знакомая сцена. Аналитик приносит ТЗ. Вроде всё написано: поля, кнопки, фильтры, статусы, комментарии.

Разработчик открывает документ и начинает задавать вопросы:

• комментарий относится к вагону или к рейсу?

• что делать, если этот вагон уже был в системе месяц назад?

• поезд может измениться по пути?

• что считать прибытием?

• если накладная пришла с мусорным номером вагона — мы её теряем или

• отправляем на ручной разбор?

• кто источник истины: дислокация, ЭТРАН, оператор или 1С?

Типичная сцена

Аналитику кажется, что разработчик душнит. Разработчику кажется, что ему снова принесли текст, который выглядит как ТЗ, но не отвечает на инженерные вопросы. Бизнесу кажется, что команда тормозит на очевидной задаче. Хотя чаще всего проблема не в людях.

Проблема в том, что все слишком поздно проверили, одинаковую ли систему они представляют.

Бизнес думает результатом: «хочу видеть вагоны».

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

Между бизнесовой фразой и задачей для разработки есть пустая зона. Если аналитик не пройдёт её раньше, её всё равно придётся проходить — только уже дороже.

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

Как мы работали с Claude на самом деле

Самый плохой способ использовать ИИ в такой задаче — написать:

Сделай систему слежения за вагонами.

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

Мы работали иначе.

1. Сначала описывали контекст: откуда приходят вагоны, какие данные отдаёт РЖД, кто сидит за экраном и где заканчивается внешний мониторинг.

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

3. Дальше проверяли сценарии на живых данных: перецепка, повторный приезд, грязный номер, пустая дата, изменение остатка пути, завершение рейса.

4. После этого собирали черновую модель: таблицы, связи, статусы, API, экран оператора и правила синхронизации.

Claude помогал быстро материализовать гипотезы: предложить модель, набросать таблицы, сформулировать API, собрать черновой экран, показать слабые места.

Но самые ценные моменты были не там, где он писал код.

Самые ценные моменты были там, где становилось видно: наша собственная формулировка задачи неполная.

В этот момент ИИ перестаёт быть «генератором кода» и становится зеркалом для требований. Не всегда умным. Не всегда точным. Но достаточно быстрым, чтобы заставить аналитика раньше столкнуться с реальностью системы.

Что вскрыл прототип

1. Вагон и рейс — разные сущности

Бизнес говорит «вагон». Но система должна понимать: речь о физическом объекте или о конкретной поездке?

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

wagon → wagon_trip → dislocation_event

Физический вагон отвечает на вопрос: «что это за объект?» Рейс отвечает на вопрос: «какая это конкретная поездка?» Событие отвечает на вопрос: «что произошло с ним во времени?»

2. Поезд удобен на экране, но опасен в модели

Оператору удобно видеть вагоны по поездам. Это естественная группировка. Но поезд в живых данных нестабилен: вагоны могут менять составы по пути. Если сделать поезд главным контейнером процесса, при перецепке начнут ломаться история, статусы и связи.

3. Дислокация — это поток, а не «последняя строка»

Самая большая сложность оказалась в синхронизации. На уровне отчёта всё выглядело просто: взять последнее событие по вагону. Но для рабочей системы этого недостаточно. Синхронизация превратилась в 8-шаговый конвейер:

1. Отбор релевантных вагонов из потока

2. Создание или обновление активных рейсов

3. Привязка новых операций РЖД к рейсам

4. Обновление текущего состояния рейса для интерфейса

5. Сопоставление рейсов с накладными ЭТРАН

6. Закрытие рейсов по терминальным событиям

7. Реактивация ошибочно закрытых рейсов

8. Нормализация активных рейсов и связей

На прототипе мы увидели, что синхронизация — это отдельная предметная задача, а не вспомогательный скрипт.

4. Одна бизнес-фраза может быть новым поведением системы

Хороший пример — порог 150 км. Бизнес сказал: если поезд дальше 150 км, просто мониторим. Если ближе — начинаем готовить приёмку. Звучит как простое условие. На деле это новый статус, другой режим интерфейса, ограничения на создание заявок, автоматические действия и вопросы к повторному изменению расстояния.

5. ЭТРАН принёс не только данные, но и грязь

Когда появились ЭТРАН-накладные, задача снова выглядела простой: связать накладную с вагоном и подтянуть груз, контейнеры, отправителя, получателя. Но реальные данные быстро охлаждают оптимизм.

А теперь давайте честно

Где Claude ошибался

Важно упомянуть: Claude не был волшебной кнопкой. Он ошибался. Предлагал ORM там, где нам был нужен предсказуемый SQL. Добавлял красивые абстракции туда, где нужна была простая бизнес-логика. Недооценивал побочные эффекты синхронизации. Иногда уверенно предлагал решение, которое хорошо выглядит в вакууме, но плохо живёт на реальных данных. Поэтому рядом всегда были Git, ручная проверка, знание домена и готовность откатить неудачное направление.

Что это дало аналитикам

Главный вывод не в том, что «аналитики теперь могут кодить». Главный вывод в том, что аналитик получает возможность раньше думать как системный проектировщик. Не просто записывать:

А разбирать:

• Что такое вагон в этой системе?

• Чем он отличается от рейса?

• Какие события создают и завершают рейс?

• Где источник истины?

• Какие данные можно пересчитать, а какие нельзя терять?

• Как система переживает грязные данные?

• Какие ошибки требуют ручного разбора?

• Какие вопросы ещё не решены бизнесом?

Это и есть зона, где рождается нормальное ТЗ. Не в красивом описании экрана, а в столкновении требований с моделью системы.

Что это дало разработчикам

Разработчики не должны угадывать систему по намёкам. После прототипа в разработку можно отдавать не туман, а более взрослую постановку:

• Вагон и рейс — разные сущности

• Поезд — группировка, но не стабильный ключ

• Дислокация — поток событий

• Комментарии нужно защищать от пересборки данных

• ЭТРАН требует правил сопоставления и валидации

• Синхронизация имеет побочные эффекты

• Часть вопросов остаётся открытой и требует решения бизнеса

Это не снимает с разработки сложность. Production — это архитектура, тесты, безопасность, миграции, мониторинг, производительность, эксплуатация и поддержка. Прототип не должен быть аргументом «мы же быстро собрали, теперь и вы быстро сделайте». Его нормальная роль другая: убрать часть тумана до того, как он станет дорогим.

Как изменилось ТЗ после такой проверки

После прототипа ТЗ перестаёт быть пересказом первой встречи. В него попадает то, что обычно всплывает слишком поздно:

• Глоссарий предметной области

• Сущности и связи

• Жизненный цикл рейса

• Статусы и переходы

• Правила создания, обновления, архивации и реактивации

• Сценарии оператора

• Исключения и ошибки

• Правила работы с грязными данными

• Интеграционные контракты

• Ограничения на пересчёт

• Требования к сохранению пользовательского ввода

• Критерии приёмки

• Список открытых вопросов

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

Вывод

ИИ-инструменты часто обсуждают через скорость: быстрее написать код, быстрее собрать прототип, быстрее закрыть задачу. В нашем случае главное ускорение произошло не в коде. Оно произошло в понимании.

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

Для аналитика ИИ может быть полезен не как способ заменить разработчика, а как способ раньше пройти путь от слов к системе.

Не вместо команды. Не для давления на сроки. А чтобы прийти к разработчикам не с туманом, а с нормальным инженерным материалом.

Хорошее ТЗ появляется не там, где один человек красиво написал документ. Хорошее ТЗ появляется там, где команда успела проверить понимание до того, как ошибка стала дорогой.

Эта статья выросла из внутренней работы над прототипом модуля «Дислокация» для ЛКДС. Над ней работали: Ведущий специалист Ильнур Садиков, Младший специалист Энгель Адылев и Старший специалист Айдан Казиханов.

Для нас этот кейс стал хорошим напоминанием: аналитика — это не только написать требования. Иногда это значит раньше всех пройти путь от простой бизнес-фразы до системы, в которой уже видны сущности, связи, исключения и будущие ошибки.

Источник: habr.com