От сорванных сроков достаётся всем: сотрудники выгорают и теряют мотивацию, бизнес теряет деньги и доверие клиентов. Вместе с бизнес-консультантом Олесей Мамонтовой разбираемся, почему дедлайны срываются, как выстроить процессы, чтобы сдавать всё вовремя, и как быть, если дедлайн уже прошёл.
Почему срываются дедлайны
Срыв срока — это ситуация, когда задачу не сдали в оговорённый день и заранее не согласовали перенос. Из-за этого следующий по плану этап стартует с задержкой, расходы растут, время уходит, снижается доверие заказчиков.
Сроки могут быть двух видов:
Внутренние — их можно передвинуть, и это не сильно повлияет на команду, проект или заказчика. Например, если автор корпоративного блога на пару дней задержит статью.
Жёсткие внешние — их без крайней необходимости лучше не трогать. Например, если задержать запуск оплаты на сайте, компания будет терять выручку за каждый день простоя.
Ранние сигналы обычно можно заметить задолго до финальной даты. Если среднее время на задачу растёт, а в работе находится слишком много всего, прогресс будет двигаться медленно. Стоит уменьшить количество одновременных задач и визуализировать прогресс — тогда работа ускорится.
На сроки влияет и то, как команда общается каждый день. Если вопросы не задают вовремя, проблемы всплывают в конце и превращаются в аврал. Здесь помогут короткие ежедневные синхронизации, чтобы быстро назвать сделанное, обозначить план, снять зависшие вопросы и не копить переделки на последний момент.
Срыв — это когда приходят в последний момент, ничего не готово и нечем объяснить причину ни руководству, ни клиенту. Тут работает простая аналогия с поездом или самолётом:
если предупредить вовремя, билеты можно поменять;
если опоздать — поезд ушёл, контракт сорвался.
Дальше рассмотрим, какие у срывов бывают причины, как их распознать и устранить.
Управленческие причины
Например, когда руководитель ставит сроки без обсуждения объёма, по ходу добавляет требования и не обновляет план. Или когда каждую неделю меняются приоритеты, из-за чего предыдущие задачи зависают.
Как обнаружить.
Растут переработки, но к промежуточной дате так и не показывают ни демо, ни макет.
В плане релиза не меняется дата, хотя в трекере становится больше задач.
Люди по-разному называют итог и не сходятся по дате.
Как устранить.
Зафиксировать, что входит и не входит в релиз, и сразу согласовать критерии готовности.
Выбрать дату сдачи этого объёма, а при любом новом требовании менять план: либо двигать дату, либо убирать часть задач.
При жёстких сроках закладывать буферы на риски и ввести ограничения на параллельные задачи.
Бывает, что в начале запланировали одно, а в процессе клиенту понравилось и он хочет больше. Или в проекте у клиента что-то меняется, и появляются другие задачи. Формально это решается ростом команды, но не всегда выгодно нанимать больше людей под один проект. Я беру новых специалистов только когда понимаю, что смогу загрузить их на несколько проектов. В остальных случаях согласовываем более поздний срок.
Как избежать. Завести один шаблон задачи и один формат статуса, применять его везде. В карточке всегда прописывать цель, понятный результат к конкретной дате, критерии готовности, как проверяем, что сделали, что точно не делаем сейчас. Например: «Лендинг к 25 сентября, 18:00 МСК — свёрстан первый экран и шапка, форма отправляет заявки в CRM, список оставшихся блоков приложен».
Статус писать по короткой схеме: сделал за вчера и сегодня, что конкретно мешает продолжать, кого ждём и до какого времени, когда покажем работу. Карточки вести в общем месте, а не в личных чатах. Владелец карточки — один человек. Даты промежуточных проверок фиксировать в плане сразу при создании задачи.
Процессные причины
Процессы ломаются, когда промежуточный результат не показывают, задачи кочуют между людьми, согласования застревают у одного участника, а в работе находится слишком много задач одновременно.
Как обнаружить.
На доске копятся карточки задач в одном статусе — образуется узкое место.
Эти карточки часто переходят из рук в руки без фиксированных правил передачи, и каждый переход увеличивает паузу.
Возвраты на доработку случаются в самом конце, потому что расхождения обнаруживают поздно.
Мы с командой каждую неделю показываем сделанное. Параллельно ведём еженедельные отчёты по задачам и по времени. Даже если по результатам вопросов нет, по отчётам видно, где работа буксует.
Если на задачу закладывали пять рабочих дней, а человек сидит над ней уже вторую неделю, это главный сигнал. В таких случаях учащаем встречи, просим показать промежуточный результат и разбиваем объём на более мелкие шаги, чтобы прогресс был виден отчётливо.
Как устранить.
Делить задачи на небольшие куски и показывать их до наступления дедлайна.
Собирать всех ответственных на созвон и согласовывать всё за один заход, чтобы не гонять документ кругами.
Убирать лишние передачи между ролями: заранее договариваться, кто что отдаёт и в каком виде, чтобы следующий мог сразу работать.
Уменьшать количество одновременно открытых карточек, чтобы ускорить выполнение задач.
Когда сотрудник даёт странную обратную связь или не въезжает в задачу, мы переводим переписку в разговор и организуем созвон. Ставим задачу голосом под запись, просим показать, как он её понял.
Бывает, человек уверяет, что вопросов нет, а потом приносит работу, и это полная лажа. У нас так когда-то потеряли полтора месяца на техническое задание, по которому в принципе нельзя было сделать функционал. С тех пор мы промежуточно смотрим результат, чтобы такие вещи ловить заранее.
Как избежать. Ввести лимит одновременной работы: для команды из пяти человек до шести задач одновременно. На человека — одна крупная или две небольшие задачи, крупная — если занимает свыше восьми часов. Достигли лимита — новые задачи не брать, пока не доделается начатое.
Передавая задачу, заполнить поля: что сделано, что осталось, ссылки на материалы, вопросы и риски, время следующего показа. В карточке всегда есть актуальное описание, ссылки, чек-лист приёмки и дата следующей проверки. Согласования закрывать за один заход: собрать тех, кто принимает решение, зафиксировать итог в общем канале и сразу обновить карточку.
Коммуникативные причины
Коммуникация сбоит, когда переписка идёт в разных каналах, а решения не фиксируются в одном месте. Диалог разбросан по чатам, почте и личкам, и о половине решений команда просто не знает. Ещё одна частая проблема — нет договорённостей по времени ответа и по тому, что решают письменно, а что обсуждают голосом.
Мы переводим диалог из переписки в разговор, когда есть риск недопонимания. Подключаюсь к экрану клиента, он показывает реальные бизнес-процессы, мы вместе проговариваем, что именно нужно в жизни, и только после этого берём задачу в работу. Так сокращаются круги согласований и снижается вероятность, что мы неделями будем делать не то.
Как обнаружить.
Появляются длинные паузы между сообщениями.
Тема расползается на несколько веток.
В конце прилетает пакет неожиданных правок, потому что стороны по-разному поняли задачу.
Команда повторяет одни и те же вопросы, потому что решение нигде не записано.
Сроки нужно ставить не по лучшему сценарию, а по скорости условного среднего исполнителя с запасом на форс-мажоры. Я однажды оценила задачу по своей скорости, а делал её человек без моего опыта, и времени ушло втрое больше.
Как устранить.
Сложные и неоднозначные вопросы переводить в короткий разговор и закрывать за один заход с теми, кто принимает решение.
После созвона сразу фиксировать итог там, где его увидит вся команда, чтобы не терять контекст и не спорить о трактовках.
Для ежедневной синхронизации брать простой формат статуса с указанием сделанного, препятствий и ближайшего шага.
Как избежать. Формально принимать рабочие соглашения и обновлять их по мере изменений. В документе кратко задавать правила каналов связи, единые окна ответа и места, где хранят решения и планы.
Для вопросов, которые не требуют немедленной реакции, использовать асинхронную коммуникацию и выделять время на ответы, чтобы не отвлекаться и не растягивать работу. Например, в рабочее время отвечать в чате в пределах одного–двух часов, на почту — в течение суток. Вне рабочих часов ответа не ждать, если заранее не пометили срочность. Переходить к созвону, когда после пары сообщений остаются разночтения, вопрос блокирует работу дольше одного дня или сразу нужно решение от конкретного владельца. Итог созвона фиксировать в общем канале.
Индивидуальные причины
К индивидуальным причинам относятся перегрузка и выгорание, перфекционизм и нехватка навыков. От работы сверх нормы падает уровень энергии и внимательность, дедлайны начинают плыть. Из-за перфекционизма человек бесконечно полирует работу, вместо того, чтобы сдать просто приемлемый вариант. Нехватка навыков приводит к затяжным правкам: человек берётся за задачу, но буксует на базовых приёмах и делает работу дольше остальных.
Как обнаружить.
У одного и того же исполнителя срывы повторяются из месяца в месяц.
Задачи стабильно закрываются поздно вечером или ночью.
Сложные блоки откладываются до последнего.
Вместо готовой версии человек шлифует детали и не показывает результат.
В течение дня часто переключается между задачами.
Как устранить.
Просить показать минимальную рабочую версию, чтобы сразу исправить ошибки по существу, и только потом дорабатывать.
Параллельно снять с человека часть задач, чтобы убрать перегруз. Или выделить напарника в помощь.
Если причина в навыке, сделать простой план доращивания компетенций под конкретную роль и задачу: что освоить, какой пример показать и к какой дате.
Как избежать. Ввести правило предупреждать заранее. Если человек понимает, что не успевает или не хватает навыка, сообщать сразу, не дожидаясь дедлайна. Договориться о простом триггере: как только из расчётных часов израсходовали половину, а готово заметно меньше половины, это повод обратиться за помощью.
Важно проговорить, что ранний сигнал — это рабочая норма, и за это не последует наказания. Можно зафиксировать в правилах, что сотрудников не штрафуют и не лишают премии, если они предупреждают заранее, что не справляются.
Мы у себя запретили слово «быстро». Если правда получится быстро, пусть это будет сюрпризом. Но чаще сначала за два дня делаешь, а потом две недели восстанавливаешься. Так не надо. Лучше держать ровный темп — тише едешь, дальше будешь.
Внешние причины
Внешние причины — это сбои связи и электричества, задержки исходников и оплат, жёсткие внешние даты. Например, у подрядчика отключили свет на полдня — макет не выходит к вечеру. В налоговом календаре стоят даты, которые не сдвинуть — квартальная отчётность и платежи идут по фиксированным срокам, просрочка грозит штрафами и пятном на репутации.
Бывают чистые форс-мажоры. В Королёве у нашей сотрудницы отключали свет — в этот день она не могла сдать работу. В Курске рубили связь из-за беспилотников — из-за этого сорвался созвон. Это внешние обстоятельства, на которые нельзя повлиять, и они двигают сроки.
Иногда тормозит сроки не команда, а деньги и календарь. Клиент затягивает с оплатой, а потом платит и просит нагнать. Если это совпадает с нерабочими днями и длинными межбанковскими проводками, запуск в тот же день не случится.
С жёсткими датами упрощаем объём, чтобы сдать вовремя, а доработки переносим после. Так делали по проектной отчётности: клиент принёс документы 25-го числа, закрыть отчёт обязательно нужно 30-го, иначе команда не получит зарплату за месяц. За пять дней сделать весь проект невозможно, поэтому мы определили минимально необходимое, что успеем за оставшиеся дни, чтобы закрыть отчёт, а остальное перенесли на следующий месяц.
Как обнаружить. Внешние причины обычно не получается выявить заранее. Например, про болезнь или ЧП человек сообщает в день события, когда всё уже произошло.
Чтобы внешние риски меньше били по срокам, ставим понятные правила до старта. На сложные и долгие проекты без аванса не выходим — это наша страховка от срывов из-за чужих платёжных задержек. Если видим сложный по времени проект, тяжёлые коммуникации и при этом постоплату, от такого проекта отказываемся.
Как устранить.
Если отключили офисное электричество — перейти на резерв: работать из дома, подключиться через мобильный интернет, использовать источники бесперебойного питания и ноутбуки.
Руководителю — назвать новую точку проверки готовности к концу дня.
Если задержали исходники, делать то, что не зависит от материалов, а недостающие части заменять заглушками до первого показа.
Как избежать. Здесь поможет план на случай непредвиденных ситуаций. Описать, кто и при каких условиях объявляет о форс-мажоре, кого и где уведомляют, как часто дают обновления, когда и кто принимает решение сократить объём. Поместить его в общее место с офлайн-доступом и короткой версией на первой странице, а раз в квартал делать 30-минутный прогон по сценарию и обновлять план по итогам реальных сбоев.
Что делать, если срок уже сорван
Сначала следует выйти на связь и назвать проблему прямо: срок сорвался, вот почему, вот что делаем сейчас, следующее обновление будет во столько-то — чтобы клиент или коллеги не оставались в вакууме.
Дальше показать, что уже готово: черновой макет, ссылка на демо, первый экран лендинга, кусок отчёта — любой рабочий фрагмент, на котором можно предметно обсудить, что осталось. В этот же день договориться о ближайшем осязаемом результате и времени следующего апдейта. Формат примерно такой: «Сегодня до 17:00 присылаем первый экран в вёрстке и перечень оставшихся блоков. В 18:30 подтвердим готовность следующего шага».
Параллельно упростить объём до минимально полезной версии, а остальное перенести на следующий заход. После согласования ядра зафиксировать новый план: что в него входит, кто делает, к какой дате и в каком ритме идут апдейты.
В ближайшие сутки после срыва главное — не теряться. Сразу выйти на связь, объяснить ситуацию, договариваться и искать варианты. Взять короткую паузу, чтобы трезво оценить, где мы находимся по задаче, что уже готово и что реально показать сегодня. Обсудить это с командой, не стесняться подключать нейросети для идей, анализа и формулировок — в наших проектах это реально помогало.
Итогом разговора должен стать ближайший осязаемый шаг и время следующего обновления, а не молчание и попытка спрятаться.
