Большинство проектов не падают внезапно. Они подают сигналы заранее — иногда очень тихо, иногда прямо в лицо.
За последние годы я заметил три признака, которые почти гарантируют: если ничего не сделать, через пару недель будет срыв сроков, стресс, переделки и неудобные разговоры с руководством.
Вот эти три сигнала — и мои действия, которые стабильно спасают ситуацию.
Сигнал 1. Растёт количество “возвратов” задач
Если задачи возвращаются из QA обратно в разработку чаще, чем идут в «Done», проект уже выходит из-под контроля.
Почему это опасно:
- команда занимается не новым функционалом, а переделками;
- скорость падает, а доверие со стороны бизнеса — тоже;
- дедлайны становятся непредсказуемыми.
Что я делаю:
- Разбираю причину возвратов по категориям:
требования, дизайн, тесты, API, коммуникация, технические риски. - Обновляю DoR/DoD под реальные проблемы.
Если 40% возвратов — из-за отсутствующих AC, это первый пункт DoR. - Пересобираю процесс передачи задач:
разговор треугольником PM → Developer → QA вместо “перекидываний”. - Временно замедляю набор задач: лечим качество → возвращаем скорость.
Если возвраты превышают 15–20% — это прямое предсказание, что через 2 недели проект встанет.
Сигнал 2. Нет прозрачности статусов — люди говорят «ну, примерно делаем»
Когда разработчики перестают уверенно говорить, на какой стадии задача, это означает одно:
работа ведётся хаотично, а риски уже внутри.
Типичные фразы-предвестники:
- «Мы почти сделали»
- «Осталась мелочь»
- «Скоро выкатим»
Обычно за этим:
- половина AC ещё не тронута,
- есть скрытые блокеры,
- оценка была пессимистичной или вообще отсутствовала.
Что я делаю:
- Вывожу работу в абсолютную прозрачность:
Kanban-борд, ограничение WIP, ежедневный короткий sync. - Перехожу от “материи” к понятным статусам:
In Progress → Review → QA → Ready to Release. - Добавляю политику “limit work-in-progress”:
нельзя начинать новые задачи, пока старые не закрыты. - Делаю mini-audit задач: проверяю AC, зависимости, реалистичность.
Статусная непрозрачность — это не проблема планирования.
Это проблема управления вниманием команды.
Сигнал 3. Команда перестаёт синхронизироваться — каждый живёт в своей реальности
Когда фронтенд, бекенд, QA и аналитика не совпадают в понимании задачи, это взрывается ближе к релизу.
Признаки:
- Фронт сделал одно, бек ожидал другое.
- QA тестирует по старым требованиям.
- Аналитик считает, что вы уже сделали весь фичер, а разработчики даже не начинали часть сценариев.
- Приоритеты меняются в головах, а не на уровне борда.
Это самый дорогой тип риска.
Что я делаю:
- Собираю команду на “alignment session” на 15 минут:
что делаем, что уже готово, что блокирует, что менялось. - Сверяю понимание задач одним предложением:
каждый формулирует, что должно быть результатом. - Уточняю зоны ответственности: кто ведёт, кто проверяет, кто принимает.
- Переподтверждаю приоритеты у бизнеса: иногда срыв — это про “потом выяснилось, что важнее другое”.
Если команда не выровнена, то техническая часть не спасёт.
Несогласованность = скрытая работа → срыв.
Главный вывод
Проекты срываются не потому, что “не повезло” или “не хватило времени”.
Они срываются, потому что сигналы риска оказались незамеченными или проигнорированными.
Когда я вижу хотя бы один из этих сигналов, я действую сразу, потому что проект не терпит ожидания.
Если коротко:
- Много возвратов? Лечим качество → обновляем DoR/DoD → стабилизируем поток.
- Нет прозрачности статусов? Создаём единый источник правды → ограничиваем WIP.
- Команда рассинхронизирована? Возвращаем единое понимание → фиксируем приоритеты.
2 недели — это много.
Если ловить сигналы вовремя, проект можно вытащить практически в любом состоянии.
Если хочешь, могу сделать ещё одну статью в серии:
«3 решения, которые PM должен принимать до того, как появятся проблемы»
или
«Как я использую DoR/DoD, чтобы уменьшить количество возвратов в 3 раза».
Скажи, какую тему продолжить.