Ресурсное планирование проектов можно дописать агентами под доступность специалистов разных отделов

Отдел склада запланировал участие специалиста в инвентаризации, а отдел регламентов ждёт его на согласовании новой процедуры. В каждом плане есть свободные дни. Конфликт появляется, когда оба назначения собирают в календаре специалиста. Это условный пример, который дальше превратим в требования к системе.

Для ресурсного планирования проектов нужна общая запись о специалисте: его график, отсутствие, регулярные обязанности и назначения из всех отделов. Если у склада и регламентов разные копии календаря, перенос встречи в одной копии не освобождает и не занимает время в другой.

Не хотите разбираться сами? Внедряем ИИ в ваш бизнес: задачи без лимита, одна цена в месяц, отмена в любой момент.

Сначала договоритесь, кто обновляет доступность и кто подтверждает назначение. Пока отсутствие и текущая работа не попадают в календарь, свободная клетка означает лишь отсутствие записи. Заказ разработки начинается с источника этих данных и права принять решение.

У нашего условного специалиста неделя на 40 часов. Из неё 8 заняты регулярной работой, ещё 8 недоступны из-за отсутствия. Для проектов остаются 24 часа. Эти числа нужны только для примера; в вашей системе исходным будет график конкретного специалиста.

Склад запрашивает 16 часов, регламенты ещё 16. Каждая заявка меньше доступных 24 часов, но вместе нужны 32. Календарь должен показать дефицит 8 часов до подтверждения второй заявки и назвать назначения, из которых он сложился.

После решения руководителя склад получает 16 часов, регламенты 8, оставшиеся 8 переносятся. Можно выбрать другое распределение или согласовать замену специалиста. Дописываемая система хранит решение и пересчитывает доступность; агент не создаёт недостающие часы.

Редакционный расчёт, 08.10.2026. Полностью условные данные, не клиентский результат.

Доступность и перегрузка уже есть в готовых продуктах: Kaiten сопоставляет занятость с доступными часами. В справке Microsoft для прежних версий Project описаны межпроектная нагрузка и согласование назначений. У Project Online дата прекращения работы 30 сентября 2026, поэтому здесь справка служит историческим примером механизма. Источники проверены 8 октября 2026.

При работе с агентами оценка story points не заменяет проверку неизвестного, ожидания и возвратов задачи.

Поэтому сначала воспроизведите пример склада и регламентов в системе, которой пользуетесь. Добавьте отсутствие, запрос из другого отдела и изменение уже подтверждённого назначения. Если настройка покрывает правила и объясняет конфликт, покупка собственной разработки на этом основании не нужна.

Заказ появляется, когда остаётся конкретный разрыв: календарь не получает нужные данные, решение нельзя провести по вашему порядку согласования или расчёт не учитывает обязательную текущую работу. Опишите этот разрыв наблюдаемым действием. Формулировка «нам неудобно» не говорит исполнителю, что должно измениться.

Kaiten и Microsoft, страницы проверены 08.10.2026; справка Microsoft служит историческим примером. Правая колонка задаёт условия заказа, а не обнаруженные нами недостатки этих продуктов.

Начните с одинакового ответа на вопрос «специалист доступен?». Уточните, какой график действует, что уже забронировано и какие заявки пока лишь предложены. Заявка склада не должна незаметно становиться подтверждённой только потому, что её сохранил руководитель проекта.

Для назначения на конкретное время нужна проверка пересечения интервалов. Если склад и регламенты ждут специалиста в одно утро, свободные часы в конце недели не устраняют совпадение. Для работы без фиксированного времени отдельно задайте допустимую нагрузку за период. Эти проверки отвечают на разные вопросы. Часовой пояс и границы периода тоже фиксируют в правилах.

Зафиксируйте правила для агентов рядом с кодом: что считать занятым временем, кто подтверждает заявку, как выбирают замену и что происходит при изменении графика. Иначе агенту придётся выбирать между трактовками отделов. Решение о приоритете принимает уполномоченный руководитель, а программа применяет согласованное правило.

Предлагаемые требования для условного календаря, 08.10.2026. Политику резервирования и права утверждает компания до разработки.

В постановке задачи агенту опишите действие руководителя и результат, который он должен увидеть. Для нашего примера: после подтверждения склада заявка регламентов на весь объём не проходит без решения о дефиците. Исполнителю нужны также исключения: перенос, отмена, замена и изменение отсутствия.

Отдельный сценарий: два руководителя одновременно подтверждают заявки на одни и те же часы. Оба могли открыть календарь, пока он ещё показывал свободное время. Итоговая проверка должна сработать при сохранении; цвет клетки в ранее открытом окне этого не гарантирует.

Начните приёмку на выдуманных сотрудниках и проектах. Работа с персональными данными требует отдельного решения о данных и доступах до подключения кадровых источников. Для проверки арифметики не нужны настоящие имена, причины отсутствия или переписка сотрудников.

Редакционные сценарии для условного календаря, 08.10.2026. Это проект требований, не результаты испытаний готовой системы.

Мы строим vibecoding.ru машиной агентов: инженер задаёт правила, ведёт работу и принимает результат. Карта нашей машины показывает устройство этого процесса. Она не доказывает, что календарь улучшит планирование вашей компании. Клиентского замера до и после для этой задачи у нас нет.

Наши поломки показывают, почему описание правила должно доходить до исполнителя и почему параллельные операции нужно проверять вместе. В одном случае агент не увидел правило на своём входе. В другом старая сборка закончилась после новой и перезаписала общий результат. Это аналогии устройства разработки, не истории загрузки сотрудников.

Есть и проверка принятой работы: отдельная сессия сверяет результат с исходными правилами и фактами, а не с пересказом исполнителя. Материал о правилах есть в уроке «Файл правил целиком» курса агентной инженерии. Для календаря предметом такой проверки станут ваши сценарии назначения, включая одновременные действия.

Собственные записи машины vibecoding.ru, сверены 08.10.2026. Публичное устройство процесса показано на /open; клиентского эффекта ресурсного календаря эти истории не измеряют.

Ограничьте первый результат общим календарём доступности, назначениями и объяснением конфликтов. Сначала согласуйте источники данных и набор сценариев. Красивый календарь без реакции на вторую заявку не проходит приёмку; работающий расчёт без понятного объяснения конфликта тоже не помогает руководителю принять решение.

Такую доработку можно обсудить в формате разработки по подписке. На 8 октября 2026 тариф «Один проект» стоит 250 000 ₽ в месяц: один продукт, один поток, одна задача в работе. Инженер ведёт машину агентов, код остаётся в репозитории клиента, пауза доступна в любой месяц. Это цена месяца разработки, не смета всего календаря и не лимит проектов внутри него.

Для первого разговора выпишите текущие источники календаря, пример конфликтующего назначения и правило его разрешения. С ними можно обсудить свою задачу и определить, что проверят в первом результате. Срок и объём согласуют после разбора правил и интеграций; переносить на этот заказ сроки из чужих проектов нельзя.

Предлагаемый объём приёмки, 08.10.2026. Формат и цена услуги сверены с живой страницей /services в тот же день.

Вернёмся к складу и регламентам. После переноса части работ календарь показывает согласованный объём, но это ещё не результат всего внедрения. В первом цикле планирования проверьте, не пришлось ли руководителям вручную исправлять назначения, которые система считала допустимыми.

Сохраните каждый такой случай с причиной: устаревший график, пропущенная текущая работа, неверное право подтверждения или совпавшие действия. Из случая получается новый сценарий проверки и правка правила. Инженер принимает доработку по этому сценарию; в следующем цикле руководитель проверяет, повторяется ли ошибка.

Сравнивайте циклы на одинаковом составе проектов и с одинаковым определением конфликта. Если загрузка выросла или появился новый отдел, одно число «ошибок стало меньше» не объяснит изменение. Счётчик выявленных конфликтов тоже не доказывает эффект: их может стать больше просто потому, что теперь их видно.

Предлагаемый способ наблюдения после запуска, 08.10.2026. Измеренного улучшения у клиента здесь нет.