---
name: requirements-prototyping
description: Prototype-first approach to requirements gathering — build a quick prototype before writing specs to eliminate ambiguity («туман вместо ТЗ»).
category: software-development
---

# Prototype-Before-Spec (Прототип до ТЗ)

## Когда применять
- Задача начинается с расплывчатого «хотим видеть X» / «сделайте как в Y»
- Аналитик/заказчик принёс «красивый документ», но разработчик видит только туман
- Предметная область неочевидна и всплывают вопросы «а что если?»
- Есть живые данные, на которых можно быстро проверить гипотезы

## Паттерн

### Шаг 1. Поймать фразу-триггер
Любое требование, звучащее как «просто покажите X», «хотим видеть Y», «сделайте удобно» — красный флаг. За ним обычно системная задача, не отчёт.

### Шаг 2. Быстрый прототип (до формального ТЗ)
За 1-2 итерации собрать работающий прототип:
- На живых данных (если есть)
- В Superset / Streamlit / простом скрипте / Claude Artifact
- Не закладывая архитектуру — только чтобы «пощупать»

### Шаг 3. Развернуть вопросы на прототипе
Вместо абстрактного ТЗ — вопросы к прототипу:
- Комментарий к чему? (к сущности, к рейсу, к событию?)
- Что если сущность уже была в системе?
- Что если данные меняются в процессе?
- Кто источник истины?
- Что делать с грязными/мусорными данными?
- Что считать граничным состоянием?

### Шаг 4. Формализовать только после прототипа
Когда предметная область «прощупана» — писать ТЗ/ADR/спекацию. Она будет в разы точнее.

## Чеклист «А что, если?»
Перед тем как нести ТЗ разработчику — пройтись по вопросам:

- [ ] Комментарий/действие привязано к правильной сущности
- [ ] Обработаны дубликаты (та же сущность возвращается)
- [ ] Данные меняются во времени (поток vs снэпшот)
- [ ] Определён источник истины
- [ ] Обработаны грязные/невалидные данные
- [ ] Определены ожидаемые состояния и переходы между ними
- [ ] Разобраны сценарии: норма, ошибка, крайний случай

## Пример из статьи (вагоны)

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

После прототипа в Superset выяснилось:
- Вагон ≠ рейс вагона (физический вагон приезжает много раз)
- Поезд меняется в пути (отцепки/прицепки)
- Данные — поток событий, не таблица
- ЭТРАН приносит мусорные номера
- 4 потенциальных источника истины: дислокация, ЭТРАН, оператор, 1С

## Инструменты для быстрых прототипов
- **Apache Superset** — дашборды на живых данных
- **Claude Artifacts / Claude Code** — быстрые UI-прототипы
- **Streamlit** — интерактивные прототипы на Python
- **Простые SQL-витрины** — чтобы увидеть структуру данных
- **LLM-прототипирование** — описать сценарий ИИ и задать «а что если?»

## Питфоллы
- ❌ Прототип не должен становиться продакшеном — выбрасывайте его после формализации
- ❌ Не показывать прототип заказчику как «готовую систему» — он захочет её в продакшен
- ❌ Прототип ≠ ТЗ — он выявляет вопросы, а не отвечает на все
- ✅ Прототип — это способ коммуникации, а not доставки
