Как сделать ИИ-агента для управления проектами

Что получится в результате

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

Первая рабочая версия будет делать так:

1. настройки хранятся в `settings`;
2. проекты хранятся в `projects`;
3. участники и роли хранятся в `team_members`;
4. задачи хранятся в `work_items`;
5. комментарии по задачам хранятся в `work_item_comments`;
6. зависимости между задачами хранятся в `dependencies`;
7. вехи проекта хранятся в `milestones`;
8. заметки встреч хранятся в `meeting_notes`;
9. action items после встреч пишутся в `action_items`;
10. правила статусов хранятся в `status_rules`;
11. сигналы риска пишутся в `risk_signals`;
12. реестр рисков пишется в `risk_register`;
13. блокеры пишутся в `blocker_log`;
14. вопросы без ответа пишутся в `open_questions`;
15. черновики обновлений задач пишутся в `update_drafts`;
16. черновики статус-отчетов пишутся в `status_reports`;
17. спорные действия уходят в `approval_queue`;
18. одобренные действия попадают в `execution_queue`;
19. задачи менеджеру, команде и владельцам пишутся в `task_queue`;
20. еженедельная сводка пишется в `weekly_project_report`;
21. все решения пишутся в `audit_log`;
22. ошибки API и данных пишутся в `error_log`.

В первой версии агент не переносит сроки, не меняет приоритеты, не назначает исполнителей, не закрывает задачи и не отправляет клиентский отчет без approval. Он собирает факты, объясняет риски и готовит черновики.

Что понадобится

• n8n Cloud или self-hosted n8n.
• Google Sheets для MVP-таблиц.
• Система задач: Asana, Trello, ClickUp, Jira, Linear, YouTrack, Todoist, Notion или CSV.
• Read-only API-ключ к проектной системе на первом этапе.
• Список проектов, команд, ролей и владельцев.
• Правила статусов: что считается нормой, риском, блокером и просрочкой.
• Данные по встречам: Google Calendar, Zoom summary, Meet notes, Notion, Confluence или ручной протокол.
• Канал approval: Telegram, Slack, Teams, email или задача.
• Канал отчетов: Slack, Teams, email, Telegram или Google Docs.
• API-ключ LLM-провайдера.
• Ответственный project manager, который подтверждает изменения.

Шаг 1. Выберите один проектный сценарий

Не начинайте с агента, который управляет всем проектом.

Для MVP выберите один сценарий:

1. собрать ежедневный статус по проекту;
2. найти просроченные задачи;
3. найти задачи без владельца или срока;
4. найти блокеры и зависимости;
5. извлечь action items из meeting notes;
6. подготовить weekly status report;
7. создать задачи на follow-up после встречи.

Самый безопасный старт: `агент читает задачи проекта и готовит черновик статус-отчета с рисками и action items`.

Проверка: сценарий можно вручную проверить на одном проекте и 20 задачах.

Шаг 2. Запретите опасные действия

В первой версии запретите агенту:

• переносить дедлайны;
• менять приоритет;
• назначать исполнителя;
• закрывать задачу;
• удалять задачу;
• менять статус на done;
• отправлять клиентский отчет;
• обещать новую дату поставки;
• менять scope проекта;
• менять бюджет;
• создавать задачи без approval;
• массово обновлять backlog.

Разрешите агенту:

• читать задачи;
• читать комментарии;
• читать meeting notes;
• искать блокеры;
• готовить черновик отчета;
• готовить черновики action items;
• создавать задачи в `task_queue`;
• отправлять approval;
• вести audit log.

Проверка: API-токен первого запуска имеет read-only доступ или workflow не использует write-endpoints.

Шаг 3. Создайте Google Sheet проекта

Создайте таблицу:

Project management agent

Добавьте листы:

settings
projects
team_members
work_items
work_item_comments
dependencies
milestones
meeting_notes
action_items
status_rules
risk_signals
risk_register
blocker_log
open_questions
update_drafts
status_reports
approval_queue
execution_queue
task_queue
weekly_project_report
audit_log
error_log

Проверка: n8n может читать и писать во все листы.

Шаг 4. Заполните settings

В `settings` добавьте колонки:

key
value
description
updated_at

Заполните минимум:

approval_required | true | любые изменения задач только через approval
auto_execute | false | автоприменение выключено
client_report_approval_required | true | клиентский отчет только после проверки
overdue_grace_hours | 24 | допуск по просрочке
stale_task_days | 7 | задача давно не обновлялась
blocked_comment_keywords | blocked,waiting,зависит,нет доступа,ждем | слова блокера
risk_window_days | 14 | горизонт поиска рисков
weekly_report_day | friday | день статус-отчета

Проверка: `approval_required = true`, `auto_execute = false`.

Шаг 5. Заполните projects

В `projects` добавьте колонки:

project_id
source_system
external_project_id
name
client
project_manager
status
start_date
target_finish_date
priority
report_channel
updated_at

Статусы:

planned
active
on_hold
at_risk
done
cancelled

Пример:

PROJ-001 | asana | 120098 | CRM migration | Internal | pm@example.ru | active | 2026-05-01 | 2026-07-15 | high | slack-project-crm | 2026-05-23

Проверка: у проекта есть менеджер, статус и целевая дата.

Шаг 6. Заполните team_members

В `team_members` добавьте колонки:

member_id
name
email
role
team
capacity_hours_week
timezone
manager_email
status
updated_at

Пример:

MEM-001 | Анна Смирнова | anna@example.ru | backend developer | engineering | 32 | Europe/Moscow | lead@example.ru | active | 2026-05-23

Проверка: у исполнителя задачи есть `member_id` и роль.

Шаг 7. Заполните work_items

В `work_items` добавьте колонки:

work_item_id
source_system
external_id
project_id
title
description
item_type
status
priority
assignee_id
owner_id
due_date
estimate_hours
spent_hours
labels
updated_at

`item_type`:

task
bug
story
milestone
decision
risk

Статусы:

backlog
todo
in_progress
review
blocked
done
cancelled

Пример:

WI-1001 | asana | 9001 | PROJ-001 | Подключить OAuth | Настроить OAuth для CRM | task | in_progress | high | MEM-001 | MEM-001 | 2026-05-30 | 12 | 4 | backend,auth | 2026-05-23

Проверка: у каждой активной задачи есть проект, статус, владелец и срок или причина отсутствия срока.

Шаг 8. Заполните work_item_comments

В `work_item_comments` добавьте колонки:

comment_id
work_item_id
author_id
comment_text
is_internal
created_at

Пример:

COM-1001 | WI-1001 | MEM-001 | Ждем доступ к OAuth app от security | false | 2026-05-23 11:20

Проверка: агент читает свежие комментарии, а не только статус задачи.

Шаг 9. Заполните dependencies

В `dependencies` добавьте колонки:

dependency_id
project_id
blocked_item_id
blocking_item_id
dependency_type
status
risk_level
created_at
updated_at

`dependency_type`:

finish_to_start
external_vendor
access_needed
decision_needed
review_needed

Проверка: если blocking item просрочен, blocked item получает риск.

Шаг 10. Заполните milestones

В `milestones` добавьте колонки:

milestone_id
project_id
name
target_date
status
owner_id
success_criteria
updated_at

Статусы:

planned
on_track
at_risk
done
missed
cancelled

Проверка: у ближайшей вехи есть критерий готовности.

Шаг 11. Заполните meeting_notes

В `meeting_notes` добавьте колонки:

meeting_id
project_id
meeting_date
title
participants
notes_text
decisions
transcript_url
created_at

Пример:

MEET-1001 | PROJ-001 | 2026-05-23 | CRM weekly sync | anna@example.ru,pm@example.ru | Обсудили OAuth, нужен доступ от security | Решили запросить доступ сегодня | https://drive/meet-1001 | 2026-05-23

Проверка: заметки связаны с проектом и датой.

Шаг 12. Заполните status_rules

В `status_rules` добавьте колонки:

rule_id
project_id
rule_type
condition
risk_level
recommended_action
owner
status
updated_at

Примеры:

RULE-OVERDUE | PROJ-001 | overdue | due_date < today and status != done | high | уточнить новый срок | pm | active | 2026-05-23
RULE-NO-OWNER | PROJ-001 | no_owner | assignee_id is empty and status != done | medium | назначить владельца | pm | active | 2026-05-23
RULE-BLOCKED | PROJ-001 | blocker | status = blocked or comment contains blocked keywords | high | эскалировать блокер | pm | active | 2026-05-23

Проверка: правила покрывают просрочки, блокеры и задачи без владельца.

Шаг 13. Подключите источники данных в n8n

Создайте workflow:

Project Management Agent - daily status

Добавьте узлы:

1. `Schedule Trigger`;
2. `Read projects`;
3. `Read team_members`;
4. `Read work_items`;
5. `Read work_item_comments`;
6. `Read dependencies`;
7. `Read milestones`;
8. `Read meeting_notes`;
9. `Read status_rules`;
10. `Detect risks`;
11. `Extract action items`;
12. `Find blockers`;
13. `LLM project analysis`;
14. `Write reports and drafts`;
15. `Send approval`;
16. `Write audit_log`;
17. `Write error_log`.

Проверка: workflow вручную обрабатывает один проект и не пишет в боевую систему задач.

Шаг 14. Если есть Asana, Trello или ClickUp, подключите read-only API

Для Asana:

GET /api/1.0/projects/{project_gid}/tasks
GET /api/1.0/tasks/{task_gid}/stories
GET /api/1.0/projects/{project_gid}

Для Trello:

GET /1/boards/{id}/cards
GET /1/cards/{id}/actions
GET /1/boards/{id}/lists

Для ClickUp:

GET /api/v2/list/{list_id}/task
GET /api/v2/task/{task_id}/comment
GET /api/v2/space/{space_id}

Проверка: API возвращает задачи и комментарии, но update-запросы выключены.

Шаг 15. Найдите risk_signals

В `risk_signals` добавьте колонки:

signal_id
run_id
project_id
work_item_id
signal_type
signal_text
risk_level
evidence_json
status
created_at

`signal_type`:

overdue
no_owner
no_due_date
blocked
stale_task
dependency_late
milestone_at_risk
scope_change
unclear_acceptance

Проверка: задача без владельца и срока создает два сигнала.

Шаг 16. Создайте risk_register

В `risk_register` добавьте колонки:

risk_id
run_id
project_id
risk_type
risk_summary
probability
impact
risk_level
owner_id
mitigation_plan
status
created_at
updated_at

`probability`:

low
medium
high

`impact`:

low
medium
high
critical

Проверка: риск содержит владельца и план реакции, а не только название.

Шаг 17. Создайте blocker_log

В `blocker_log` добавьте колонки:

blocker_id
run_id
project_id
work_item_id
blocked_by
blocker_reason
owner_id
days_blocked
risk_level
next_action
status
created_at

Статусы:

open
in_progress
waiting_external
resolved
false_positive

Проверка: комментарий “ждем доступ от security” превращается в блокер с владельцем security или PM.

Шаг 18. Создайте open_questions

В `open_questions` добавьте колонки:

question_id
run_id
project_id
source
source_id
question_text
owner_id
needed_by
risk_level
status
created_at

`source`:

meeting_notes
work_item_comments
task_description
status_report

Проверка: вопрос без владельца получает задачу PM на уточнение.

Шаг 19. Извлеките action_items

В `action_items` добавьте колонки:

action_item_id
source
source_id
project_id
title
description
owner_id
due_date
priority
approval_required
status
created_at

Статусы:

draft
sent_to_approval
approved
created_in_pm_tool
rejected
manual_only

Пример:

ACT-1001 | meeting_notes | MEET-1001 | PROJ-001 | Запросить доступ к OAuth app | Написать security и получить доступ для настройки CRM OAuth | MEM-PM | 2026-05-24 | high | true | draft | 2026-05-23

Проверка: action item имеет владельца, срок и источник.

Шаг 20. Настройте prompt для LLM project analysis

В n8n добавьте узел `LLM project analysis`.

System prompt:

Ты project manager. Работай только с переданными данными.
Не меняй сроки, статусы, приоритеты, владельцев и scope проекта.
Не отправляй клиентский отчет без approval.
Если данных не хватает, верни status = needs_data.
Любое изменение проектной системы отправляй в approval.
Ответ возвращай только JSON.

User prompt:

Проанализируй проект.

project:
{{$json.project}}

work_items:
{{$json.work_items}}

comments:
{{$json.work_item_comments}}

dependencies:
{{$json.dependencies}}

milestones:
{{$json.milestones}}

meeting_notes:
{{$json.meeting_notes}}

risk_signals:
{{$json.risk_signals}}

Верни JSON:
{
  "project_id": "...",
  "status": "on_track | at_risk | blocked | needs_data",
  "risk_level": "low | medium | high | critical",
  "summary": "...",
  "evidence": ["..."],
  "blockers": [
    {
      "work_item_id": "...",
      "reason": "...",
      "owner": "...",
      "next_action": "..."
    }
  ],
  "recommended_actions": [
    {
      "action_type": "create_task | update_status | ask_owner | escalate_blocker | draft_report",
      "owner": "pm | team_lead | assignee | stakeholder",
      "text": "...",
      "requires_approval": true
    }
  ]
}

Проверка: ответ валидный JSON и содержит evidence по каждому риску.

Шаг 21. Создайте update_drafts

В `update_drafts` добавьте колонки:

update_id
project_id
work_item_id
action_type
old_value
new_value
reason
evidence_json
approval_required
status
created_at

`action_type`:

change_due_date
change_priority
assign_owner
change_status
add_comment
create_task

Проверка: перенос срока создает только draft, а не меняет задачу.

Шаг 22. Создайте status_reports

В `status_reports` добавьте колонки:

report_id
project_id
report_type
audience
status
summary
done_items
in_progress_items
risks_json
blockers_json
next_steps_json
approval_required
created_at

`audience`:

internal
client
leadership
team

Проверка: клиентский отчет не содержит внутренних комментариев, конфликтов и персональных деталей.

Шаг 23. Настройте approval_queue

В `approval_queue` добавьте колонки:

approval_id
source
source_id
project_id
action_type
action_text
payload_json
risk_level
requested_by
approver
status
requested_at
approved_at
decision_comment

Статусы:

pending
approved
rejected
needs_changes
expired

В approval отправляйте:

1. изменение срока;
2. изменение приоритета;
3. назначение владельца;
4. смену статуса;
5. создание задачи в проектной системе;
6. отправку клиентского отчета;
7. эскалацию stakeholder;
8. изменение scope.

Проверка: без `approved` нет записи в `execution_queue`.

Шаг 24. Сделайте Telegram approval

В n8n добавьте узел `Telegram`.

Сообщение:

PROJ-001: риск HIGH

Блокер: WI-1001 ждет доступ к OAuth app.
Предложение: создать action item для PM до 2026-05-24.
Источник: комментарий COM-1001.

Approve: /approve PM-770
Edit: /edit PM-770
Reject: /reject PM-770

После `/approve PM-770` workflow должен:

1. найти `approval_id`;
2. проверить статус `pending`;
3. записать `approved`;
4. заполнить `approved_at`;
5. передать действие в `execution_queue`;
6. записать событие в `audit_log`.

Проверка: `/reject` не создает задачу и не меняет проект.

Шаг 25. Настройте execution_queue

В `execution_queue` добавьте колонки:

execution_id
approval_id
project_id
work_item_id
action_type
target_system
payload_json
status
executed_at
result_json
error_message

Статусы:

queued
manual_only
executed
failed
skipped

Для MVP используйте `manual_only`: агент готовит действие, а PM применяет его в Asana, Trello, ClickUp, Jira или Linear.

Проверка: пока write-доступ не включен, все изменения остаются `manual_only`.

Шаг 26. Создайте task_queue

В `task_queue` добавьте колонки:

task_id
source
source_id
project_id
work_item_id
task_type
title
description
owner_id
priority
status
created_at
due_at
closed_at

`task_type`:

ask_owner
resolve_blocker
update_due_date
create_followup
stakeholder_escalation
client_report_review
risk_review
data_fix

Пример:

TASK-7001 | blocker_log | BLK-1001 | PROJ-001 | WI-1001 | resolve_blocker | Получить доступ к OAuth app | Без доступа задача OAuth стоит 2 дня | MEM-PM | high | open | 2026-05-23 | 2026-05-24 | -

Проверка: каждый блокер и риск получает владельца и срок.

Шаг 27. Соберите weekly_project_report

В `weekly_project_report` добавьте колонки:

report_week
project_id
project_status
completed_count
in_progress_count
blocked_count
overdue_count
risks_count
action_items_created
approvals_pending
summary
created_at

Пример summary:

Проект at risk: 3 задачи просрочены, 2 блокера по доступам, ближайшая веха через 9 дней. Главный риск - OAuth интеграция без доступа security.

Проверка: отчет можно отправить PM каждую пятницу.

Шаг 28. Настройте audit_log

В `audit_log` добавьте колонки:

event_id
run_id
event_type
project_id
work_item_id
actor
input_hash
output_hash
summary
created_at

Пишите события:

run_started
data_loaded
risk_signal_found
blocker_found
action_item_extracted
status_report_created
approval_requested
approval_approved
task_created
run_finished

Проверка: по `run_id` можно объяснить, почему агент создал риск или action item.

Шаг 29. Настройте error_log

В `error_log` добавьте колонки:

error_id
run_id
step
source_system
project_id
work_item_id
error_type
error_message
payload_sample
status
created_at
resolved_at

`error_type`:

api_error
missing_project
missing_owner
missing_due_date
unknown_status
invalid_json
approval_error
write_error

Проверка: задача без проекта попадает в `missing_project`, а не в общий отчет.

Шаг 30. Протестируйте на одном проекте

Создайте тестовые данные:

projects:
PROJ-TEST-001 | asana | 120098 | CRM migration | Internal | pm@example.ru | active | 2026-05-01 | 2026-07-15 | high | slack-project-crm | 2026-05-23

work_items:
WI-TEST-001 | asana | 9001 | PROJ-TEST-001 | Подключить OAuth | Настроить OAuth для CRM | task | in_progress | high | MEM-001 | MEM-001 | 2026-05-30 | 12 | 4 | backend,auth | 2026-05-23

work_item_comments:
COM-TEST-001 | WI-TEST-001 | MEM-001 | Ждем доступ к OAuth app от security | false | 2026-05-23 11:20

Ожидаемый результат:

1. в `risk_signals` появился сигнал `blocked`;
2. в `blocker_log` появился блокер по доступу;
3. в `action_items` появился follow-up для PM;
4. в `status_reports` появился черновик;
5. в `approval_queue` появилась заявка;
6. в `task_queue` появилась задача;
7. в `audit_log` есть шаги запуска;
8. в `error_log` нет ошибки.

Проверка: задача в проектной системе не изменилась без approval.

Шаг 31. Проверьте негативные сценарии

Сделайте 5 тестов:

1. удалите проект из `projects`;
2. удалите исполнителя из `team_members`;
3. создайте задачу без due date;
4. верните неизвестный статус задачи;
5. верните от LLM невалидный JSON.

Ожидаемый результат:

1. нет проекта - `missing_project`;
2. нет исполнителя - `missing_owner`;
3. нет срока - сигнал `no_due_date`;
4. неизвестный статус - `unknown_status`;
5. невалидный JSON - `invalid_json`;
6. execution не запускается без approval;
7. клиентский отчет не отправляется.

Проверка: агент не исправляет плохие данные догадками.

Минимальная проверка результата

Прототип работает, если выполняются условия:

1. `projects` содержит один активный проект;
2. `work_items` содержит минимум 20 задач;
3. `work_item_comments` содержит свежие комментарии;
4. `dependencies` показывает хотя бы одну связь;
5. `meeting_notes` содержит заметку встречи;
6. `risk_signals` ловит просрочки и блокеры;
7. `risk_register` содержит владельца риска;
8. `blocker_log` содержит следующий шаг;
9. `action_items` извлекает действие из встречи;
10. `status_reports` создает черновик отчета;
11. `approval_queue` блокирует изменения проекта;
12. без `approved` нет записи в `execution_queue`;
13. `task_queue` назначает владельца;
14. `weekly_project_report` показывает состояние проекта;
15. `audit_log` объясняет действия;
16. `error_log` показывает плохие данные.

Что нельзя автоматизировать в первой версии

• перенос дедлайнов;
• изменение приоритета;
• назначение исполнителя;
• закрытие задач;
• удаление задач;
• отправку клиентского отчета;
• обещание новых сроков;
• изменение scope;
• изменение бюджета;
• массовое обновление backlog;
• изменение статуса milestone;
• любые действия в проектной системе без approval.

Частые вопросы

Можно ли начать без Asana, Trello или ClickUp?

Да. Для MVP хватит Google Sheets с проектами, задачами, комментариями и meeting notes. Но если команда уже ведет задачи в проектной системе, лучше подключить ее read-only.

Может ли агент сам переносить сроки задач?

В первой версии нет. Он может предложить новый срок и объяснить причину, но дедлайн должен подтвердить PM, владелец задачи или stakeholder.

Как агент понимает, что задача заблокирована?

Он смотрит статус `blocked`, комментарии, просроченные зависимости, отсутствие ответа и слова вроде “ждем”, “нет доступа”, “зависит”. Каждый блокер должен иметь evidence.

Можно ли использовать агента для клиентских отчетов?

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

Какой минимальный результат считать успешным?

Успешный MVP: агент берет один проект, находит блокер, извлекает action item, создает черновик статус-отчета, отправляет approval, создает задачу PM и пишет audit log.