Макет отправлен вовремя, клиент молчит, дата запуска остаётся прежней. В четверг приходит согласование, и команда пытается вместить верстку, настройку, тестирование и правки в оставшийся день. Формально задержан один ответ. Фактически изменился весь путь до запуска.
Управлять такой ситуацией удобнее через зависимости. Для каждого решения нужно знать не только обещанную дату ответа, но и последнюю дату, после которой исходный план перестаёт быть выполнимым.
В учебном проекте запуск назначен на утро пятницы. После утверждения предложения нужны день на текст и макет, день на сборку и день на проверку формы, аналитики и обработки обращения. Работы выполняются последовательно, по рабочим дням с понедельника по пятницу. Значит, подтверждённое предложение требуется до начала вторника, если команда работает в согласованном дневном режиме и не имеет других ограничений.
Запишите цепочку с четырьмя переходами: предложение → материалы → сборка → проверка → запуск. Возле каждого перехода укажите владельца решения, продолжительность следующего шага и допустимый резерв. Это уже полезнее одного общего дедлайна в календаре.
Длительность берите из реального состава работ. Не добавляйте скрытый запас в каждый шаг: иначе никто не поймёт, какой резерв действительно есть. Если часть задач можно выполнять параллельно, покажите это явно.
«Ждём согласования» сообщает статус, но не помогает принять решение. Для того же учебного проекта предметнее так: «Для запуска в пятницу утром предложение нужно утвердить до начала вторника. Затем нужны три полных рабочих дня: на текст и макет, сборку и проверку. Если согласование будет только к началу среды, доступны два варианта: запуск в понедельник утром либо сокращение объёма до согласованной версии, если оценка команды подтвердит срок».
Порог времени в примере условный. Важно, что сообщение показывает последствия до их наступления. Нельзя молча считать отсутствие ответа согласием, если такое правило не было согласовано и не подходит для конкретного решения.
Карта зависимостей может включать следующие поля:
Утверждение предложения. Последняя дата: Вторник, утро. Что ожидает: Текст и макет. Действие при пропуске: Перенос запуска или сокращение версии.
Проверка условий продажами. Последняя дата: До сборки. Что ожидает: Форма и сценарий ответа. Действие при пропуске: Приостановка зависимой части.
Разрешение на запуск. Последняя дата: После проверки. Что ожидает: Расходование бюджета. Действие при пропуске: Кампания остаётся выключенной.
Разделите задачи на независимые и зависящие от неизвестного решения. Можно подготовить тестовые сценарии или проверить действующий учёт. Нельзя выдавать работу по неподтверждённому предложению за окончательную и затем предъявлять её переделку как неожиданность.
Если команда всё же продолжает на допущении, запишите его и согласуйте предел возможных затрат. Например: используем действующий ассортимент, но не создаём финальные материалы для нового продукта до подтверждения наличия. Такой подход требует решения владельца бюджета, а не только оптимизма менеджера проекта.
Систематические очереди согласований — вопрос управления маркетингом. Когда у компании есть исполнители, но нет человека, который связывает решения и сроки, стоит оценить роль внешнего руководителя маркетинга.
Полученное согласование закрывает ожидание, но не возвращает уже потерянное время. Пересчитайте свободные ресурсы: специалист мог перейти на другую согласованную работу. Назовите новую дату, состав версии и необходимые проверки.
Разбор задержки лучше провести без поиска виноватого: вовремя ли был отправлен вопрос, был ли он однозначным, понятно ли называл решение и последствия? Если согласующему присылали тридцать замечаний вперемешку с просьбой «посмотреть», сам способ передачи мог создать очередь. Следующий план должен учитывать не только календарь, но и качество поставленного на согласование вопроса.