Управление состоянием проекта: событийный подход вместо Канбана

Событийное отслеживание проекта с автоматическим захватом контекста вместо статических Канбан-досок.

Канбан-доски — стандарт десятилетий. Trello, Jira, Notion — все предлагают одну и ту же метафору: карточки в колонках, перетаскивание вручную. На практике это означает, что вы тратите время на обновление статусов вместо самой работы. Через неделю карточки устаревают. Через месяц — вы не помните, почему приняли ключевое решение. Контекст теряется, проект дрейфует. Существует альтернатива: событийная модель, где состояние проекта обновляется автоматически на основе ваших действий.

Проблема: Канбан-доски умирают

Классическая Канбан-доска требует ручного вмешательства. Вы закончили задачу — нужно зайти в доску, перетащить карточку, обновить описание. Если забыли — доска врёт. Если ведёте несколько проектов — обновлять всё физически некогда. Результат:

• Устаревшие статусы. Карточка говорит «в работе», а задача завершена две недели назад.
• Потеря контекста. Вы помните, что приняли решение, но не помните — почему. В карточке об этом ни слова.
• Разрыв между кодом и доской. Вы сделали коммит, но доска об этом не знает. Git и Kanban живут в параллельных вселенных.
• Дублирование информации. Та же задача описана в доске, в чате, в README. Нигде полной картины.

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

Решение: событийная модель состояния проекта

Вместо ручного перетаскивания карточек — событийная система. Вы говорите ассистенту естественным языком:

• «Закончил авторизацию» → система логирует событие progress, обновляет статус проекта
• «Заблокирован на API» → создаётся блокер, статус проекта меняется на blocked
• «Решил переделать на gRPC» → логируется событие decision с полным контекстом
• «Начинаю дашборд» → фиксируется новая фаза проекта

Через неделю вы спрашиваете: «Почему мы перешли на gRPC?» — и получаете ответ с датой, контекстом и причинами. Потому что система зафиксировала событие в момент принятия решения, а не постфактум.

Архитектура: база событий вместо карточек

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

CREATE TABLE projects (
  id SERIAL PRIMARY KEY,
  name TEXT UNIQUE,
  status TEXT,           -- active, blocked, completed
  current_phase TEXT,
  last_update TIMESTAMPTZ DEFAULT NOW()
);

CREATE TABLE events (
  id SERIAL PRIMARY KEY,
  project_id INTEGER REFERENCES projects(id),
  event_type TEXT,       -- progress, blocker, decision, pivot
  description TEXT,
  context TEXT,
  timestamp TIMESTAMPTZ DEFAULT NOW()
);

CREATE TABLE blockers (
  id SERIAL PRIMARY KEY,
  project_id INTEGER REFERENCES projects(id),
  blocker_text TEXT,
  status TEXT DEFAULT 'open',   -- open, resolved
  created_at TIMESTAMPTZ DEFAULT NOW(),
  resolved_at TIMESTAMPTZ
);

Каждое событие — запись с типом, описанием и контекстом. Блокеры — отдельная таблица со статусом. Проекты — с текущей фазой. База может быть PostgreSQL для серьёзных проектов или SQLite для личных. Важно: вся история сохраняется. Ничего не удаляется.

Автоматический захват контекста

Главная ценность — не статусы, а контекст. Три месяца назад вы приняли решение об архитектуре. Сегодня новый разработчик (или вы сами) спрашивает: «А почему не REST?» В Канбан-доске ответа нет. В событийной системе — есть, потому что:

• Каждое решение фиксируется в момент принятия. Не постфактум, не «запишу потом» — сразу.
• Контекст привязан к событию. Не просто «решили перейти на gRPC», а «потому что REST не справлялся с streaming, нагрузка росла, команда согласилась 15 марта».
• Git-коммиты связываются с событиями. Система сканирует коммиты (через gh CLI), автоматически привязывает их к проектам по названиям веток или сообщениям.

Вопрос «Почему мы сделали X?» теперь отвечается за секунды, а не за полчаса археологии по чатам и документам.

Ежедневные саммари вместо стендапов

Событийная система умеет генерировать дайджесты. Cron-задача каждое утро:

1. Сканирует git-коммиты за последние 24 часа
2. Связывает их с проектами по веткам и сообщениям
3. Собирает события, блокеры, текущие фазы
4. Публикует стендап-саммари в канал: что вчера, что сегодня, что блокирует

Никаких ручных отчётов. Никаких «что вы делали вчера?» на митингах. Саммари генерируется из фактов, а не из воспоминаний.

Запросы естественным языком

Система отвечает на вопросы, а не просто хранит данные:

• «Какой статус проекта X?» → последние события, блокеры, текущая фаза
• «Почему мы отказались от Y?» → поиск по событиям типа decision и pivot
• «Что нас блокирует?» → все открытые блокеры по всем проектам
• «Что было на прошлой неделе?» → события + коммиты за период

Это не просто поиск — это агрегация контекста. Система собирает информацию из разных источников и даёт связный ответ.

Файловое состояние: почему это важно

Событийная модель хранит состояние в файлах и базе данных, а не в интерфейсе веб-приложения. Это даёт:

• Версионирование через git. Каждое изменение состояния — коммит. Полный аудит-трейл бесплатно.
• Персистентность. Упал сервер, закрылся браузер — данные на месте. Файл не зависит от сессии.
• Переносимость. Переехали на другой сервер — скопировали базу. Никакой миграции интерфейсов.
• Программируемость. Можно написать скрипт, который анализирует историю событий и выводит инсайты. Попробуйте сделать это с Jira API.

Практическая настройка

Для запуска системы нужно:

1. База данных. PostgreSQL или SQLite с таблицами projects, events, blockers.
2. Канал обновлений. Discord или Telegram-канал, куда ассистент публикует саммари.
3. Промпт для ассистента. Инструкция, которая определяет, как распознавать события из естественного языка и какие действия предпринимать.
4. Cron-задача. Ежедневный запуск сканирования git-коммитов и генерации саммари.

После настройки вы просто разговариваете с ассистентом о том, что делаете. Система сама парсит события, обновляет базу, связывает коммиты, генерирует отчёты. Вы — работаете, система — отслеживает.

Когда это лучше Канбана

• Соло-разработка. Некому обновлять доску — пусть система делает это за вас.
• Долгие проекты. Через три месяца контекст не потеряется — все решения зафиксированы.
• Множество проектов. Одна система отслеживает всё, агрегирует блокеры, генерирует саммари.
• Технические команды. Git-интеграция автоматически связывает код с прогрессом.

Когда Канбан всё ещё лучше

• Визуальное управление. Если вам нужна именно доска с колонками для визуального контроля — Канбан нагляднее.
• Большие команды с PM. Если есть человек, который следит за доской, ручное обновление не проблема.
• Стандартизированные процессы. Jira с настроенными workflow мощнее, но и сложнее в настройке.

Итого

Событийная модель состояния проекта — это Канбан, который обновляет себя сам. Вместо ручного перетаскивания карточек — автоматический захват событий. Вместо потерянного контекста — полная история решений. Вместо разрыва между кодом и доской — git-интеграция. Для одиночки или маленькой команды это реальная экономия времени и нервов. Попробуйте — и через неделю забудете, что когда-то перетаскивали карточки.