• Перезапись. UPDATE стирает прошлое значение. История живёт в отдельной таблице изменений, упорядоченной по времени.
• Время врёт. Два узла, часы, правки задним числом: «предыдущий статус» восстанавливается оконной функцией и иногда неверно.
• Каждый вопрос — новая таблица. «Текущий статус», «возвраты», «время в статусе»: CTE, временная таблица, представление. Потом ещё одна поверх.
• Причина не хранится. Почему задача оказалась в «Разработке» второй раз? В SQL это вывод из порядка строк, не факт.
• Откуда цифра. Дашборд показывает 23 дня. Из каких строк? Через три CTE никто не ответит.

-- «задачи, вернувшиеся из тестирования в разработку»
WITH s AS (SELECT task, status, at,
  LAG(status) OVER (PARTITION BY task ORDER BY at) AS prev
  FROM status_events)
SELECT DISTINCT task FROM s WHERE prev='Тестирование' AND status='Разработка';

промежуточная таблица s нужна только потому, что «предыдущий статус» не хранится

Текущий статус на срезе

CFD до среза

SQL

WITH s AS (
  SELECT task, status, at,
         LAG(status) OVER (PARTITION BY task
                           ORDER BY at) AS prev
  FROM status_events)
SELECT DISTINCT task FROM s
WHERE prev = 'Тестирование'
  AND status = 'Разработка';

порядок — по времени; промежуточная таблица; новый вопрос — новая таблица

Datalog в Vanilitik

[:find ?task
 :where [?e :$type "status"] [?e :$value "Разработка"]
        [?e :$base ?task] [?e :$cause ?c]
        [?p :$id ?c] [?p :$type "status"]
        [?p :$value "Тестирование"]]

порядок — по причине; ни таблицы, ни окна, ни сортировки

1. Команда. Десять карточек; клик — файлы читаются, pack выводится из потока, импорт проверяется и фиксируется. Секунда.
2. Двойник. Сводка графа и выведенный поток статусов: работа, ожидание, конец.
3. Узкое место. Пять кнопок подсвечивают нужную карточку отчёта и объясняют, что искать.
4. Почему. Импакт событий журнала, динамика, изломы.
5. Вопрос. Готовые запросы «для решений» и AI-аналитик: вопрос своими словами → запрос → диаграмма → объяснение.
6. Итог. Заметки собираются в три строки, копируются одной кнопкой.

Словарик терминов на каждом шаге. Все вкладки доступны по кнопке. Ключ модели на сервере, вводить ничего не нужно.

1. Открыть vanilitik5, выбрать команду своей группы. Дождаться «Шаг 2».
2. Прочитать сводку: сколько событий, задач, подзадач, списаний, записей журнала.
3. Прочитать поток, выведенный из данных: сколько статусов, какие — очереди, какой терминальный.
4. «Посмотреть поток подробнее» → вкладка «Схема»: таблица тип × статус, у каких типов свой workflow.
5. «Граф событий»: кликнуть любое статусное событие и пройти цепочку причин до корня.

1. KPI: lead и cycle p50/p85. Переключить створ cycle «откуда / докуда»: до разработки, в ней, после?
2. «Работа vs очереди» по периодам: доля ожидания до и после излома.
3. CFD: найти неделю, где полоса очереди начала расширяться. Сузить окно дат, измерить линейкой Δ задач / Δ дней.
4. «Старение WIP»: кто и в каком статусе стоит дольше всех. Если застрявших нет — команда здорова сейчас, смотрите назад.
5. «Среднее время в статусе»: столбик очереди выше остальных — узкое место.

1. «Анализ событий и трендов»: окно 14 / 28 дней. Для каждого события журнала — импакт «до → после» по lead, WIP, пропускной.
2. Найти излом, рядом с которым в журнале есть событие, и объяснить им узкое место из задания 2.
3. Найти излом, у которого объяснения в журнале нет.
4. Найти событие, которое есть, но метрик не изменило. Событие ≠ причина.
5. Написать одну строку, которой не хватает в журнале: дата, категория, текст.

1. Группа «Для решений»: выполнить «Где сейчас стоят открытые задачи», «Закрыты, минуя тестирование», «В работе без списаний».
2. Переписать один запрос под свою команду, «Сохранить отчёт».
3. AI-аналитик: вопрос своими словами про находку из задания 2 → запрос, диаграмма, объяснение. Например: «какие задачи ждали тестирования дольше 5 дней и кто их делал?»
4. «Граф событий»: кликнуть статусное событие из результата, пройти цепочку причин до корня.