Перейти к основному содержимому

Критерии готовности управления

Зачем нужно​

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

Кто использует​

  • product owner;
  • management;
  • QA;
  • analytics;
  • operations.

Сценарии​

  • руководитель смотрит dashboard;
  • координатор создаёт задачу;
  • команда ведёт план;
  • аналитик проверяет источник метрики;
  • руководитель запускает действие из отклонения.

Данные​

Проверяются метрики, dashboards, задачи, планы, workflow и права.

Правила​

  • Метрики имеют источники.
  • Задачи имеют ответственных.
  • Планы отделены от фактов.
  • Управленческие действия не обходят домены-владельцы.

Интеграции​

Проверяются входящие данные из CRM, LMS, storefront, competitions и task-bank.

Безопасность​

Проверяются роли, доступ к финансовым/PII-метрикам и аудит действий.

Нестандартные случаи​

  • неполные данные;
  • просроченная задача;
  • план без ответственного;
  • пользователь потерял доступ;
  • источник метрики недоступен.

Готовность​

  • ключевые dashboards доступны;
  • метрики имеют понятный источник;
  • задачи создаются и проходят lifecycle;
  • планы связаны с фактическим исполнением;
  • роли ограничивают доступ к управленческим данным.

Детальные критерии​

Документация​

  • границы домена описаны в scope.md;
  • модель данных описывает metrics, dashboards, plans, tasks, alerts и data quality;
  • схема БД содержит constraints, индексы, audit и idempotency keys;
  • все статусы имеют допустимые переходы;
  • API endpoints сопоставлены с permissions;
  • DTO и validation описаны для ключевых команд;
  • матрица прав покрывает sensitive metrics, exports и drill-down;
  • тест-план покрывает unit, integration, e2e, security и data quality.

Метрики​

  • каждая active-метрика имеет owner, source domain, formula, grain, unit и sensitivity;
  • изменение formula создаёт новую version;
  • historical metric values остаются объяснимыми после изменения formula;
  • metric value хранит period, segment, calculated_at и quality_status;
  • stale, partial и failed данные явно видны в API и UI;
  • пересчёт метрики идемпотентен.

Dashboards​

  • published dashboard содержит хотя бы один widget;
  • каждый widget ссылается на существующую метрику или безопасный markdown/config block;
  • dashboard проверяет visibility_rule на сервере;
  • financial, personal и restricted widgets скрываются без permissions;
  • drill-down не раскрывает данные исходного домена без его прав;
  • export пишет audit log.

Планы​

  • план имеет owner, period, status и хотя бы один target перед approval;
  • plan target связан с metric и segment;
  • plan-fact считается из metric values, а не из ручного поля;
  • active plan нельзя менять без истории изменения;
  • closed plan фиксирует итоговый snapshot;
  • cancelled plan сохраняет задачи, комментарии и audit.

Задачи​

  • задача создаётся вручную, из plan и из alert;
  • task lifecycle следует state-machines.md;
  • смена статуса, исполнителя, дедлайна и приоритета пишет history;
  • duplicate alert не создаёт повторную задачу;
  • пользователь видит только задачи в своём actor context;
  • overdue задачи отображаются в dashboard и task manager.

Alerts​

  • alert rule имеет condition, severity и deduplication key template;
  • alert создаётся при нарушении threshold;
  • alert можно acknowledge, resolve или dismiss;
  • critical dismiss требует reason;
  • task из alert создаётся один раз;
  • resolved alert сохраняется для истории.

Качество данных​

  • каждый data source имеет source domain, type, contract и status;
  • ingestion run хранит status, время, количество строк и ошибку;
  • failed ingestion создаёт data quality issue;
  • partial ingestion не скрывается под complete status;
  • data quality issues видны ответственным ролям;
  • late events приводят к пересчёту affected periods.

Интеграции​

  • CRM отдаёт события для лидов, сделок, оплат, долгов и обращений;
  • LMS отдаёт события progress, completion, submissions и активности;
  • storefront отдаёт события заявок, кампаний и страниц;
  • competitions отдаёт регистрации, результаты и публикации;
  • task-bank отдаёт low-level check attempts и evidence;
  • identity отдаёт пользователей, роли и организационный контекст;
  • management не изменяет соседний домен без явного command API владельца.

Безопасность​

  • все write endpoints требуют authenticated actor;
  • permissions проверяются на сервере;
  • sensitive metrics имеют negative tests;
  • PII не копируется в metric values и events;
  • audit logs доступны только разрешённым ролям;
  • exports не содержат скрытые поля;
  • action execution не обходит домен-владелец.

UI​

  • executive, product, operations, finance и education dashboards доступны по ролям;
  • metrics registry показывает owner, formula version, source и last calculated at;
  • planning UI поддерживает plan lifecycle и plan-fact;
  • task manager поддерживает list, kanban, filters, comments и history;
  • alerts UI поддерживает acknowledge, resolve, dismiss и create task;
  • data quality UI показывает freshness, failed runs и open issues;
  • все экраны имеют states: loading, empty, no access, stale, partial data и error.

MVP acceptance​

MVP management-домена можно принимать, если работают:

  1. metric registry с версиями формул;
  2. ingestion одного источника CRM или LMS;
  3. metric values с quality status;
  4. один published dashboard с permissions;
  5. task manager с lifecycle и history;
  6. план с target и plan-fact;
  7. alert rule, alert и task из alert;
  8. data quality issue из failed ingestion;
  9. audit для write actions;
  10. тесты из test-plan.md для критичных путей.