Пост менеджерского планирования, об которое многие спотыкаются 
Представим: на команду «спускают» крупную задачу и сразу называют дату, к которой она должна быть закрыта.
Обычно мы рисуем роадмэп и начинаем подгонять все сроки под эту дату: разбиваем работу на части, оцениваем каждый кусочек, учитываем зависимости и раскладываем по календарю (удобнее всего по неделям). Дальше оптимизируем и просто работаем по плану.
И в целом это нормально. Но мы же менеджеры. Нам платят как бы за оптимизацию, а не тупо визуализацию
А как показать что мы там что-то оптимизировали, если это никому не видно
Поэтому делаем все максимально прозрачно
Рисуем, сохраняем и презентуем сразу два плана в такой последовательности
1) Здоровый план (исходный) 
Забиваем на спущенный на нас срок, рисуем как есть.
Учитываем оцениваем и указываем вообще всё, как если бы команда работала в нормальном темпе:
● адекватные сроки старта работ
● выходные и отпуска
● техдолги
● несокращенные процессы тестирование, ревью, согласования
● буферы по времени на риски и непредвиденное
В общем рисуем наиболее реальную адекватную картинку по срокам и скоупу. Это помогает увидеть весь объем целиком, подводные камни и реальную цену качества. А позже еще и служит защитой результата, если что-то из сокращенного плана пойдёт не так.
Ну и на базе исходного рисуем отдельно второй план — подбиваемый под срок спущенный на нас
2) Критический план 
Здесь включаются «менеджерские рычаги»: максимально сжимаем график за счет мер, которые важно заранее явно зафиксировать.
● выходы в выходные (за доплату или отгулы)
● допускаем минорные дефекты (с обязательным периодом исправлений позже)
● игнорируем другие задачи по другим проектом (с обещанием взять их после)
● сокращаем документацию (с последующей доработкой)
● упрощаем этапов тестирования и согласований (с ростом риска инцидентов)
● учитываем привлечение внешних ресурсов
● начинаем параллелить работы, когда при стандартном процессе они бы шли последовательно
И презентуем, НО правильно 
Обязательно
● показываем оба плана
● указываем «цену» каждого сокращенного времени
А именно:
риски (деньги, качество, устойчивость команды) и долги (что выносим «за скобки»)
Важно
«Здоровый» план не всегда «правильный». Если у бизнеса есть срок, чаще всего он не взят с потолка: к моменту «здорового» релиза задача может потерять актуальность, и долгую разработку никто не будет ждать.
Но ускорение всегда имеет цену. Сжать сроки без последствий невозможно: что-то уйдет в техдолг, где-то пострадает качество, где-то вырастут риски.
Просто добавить людей тоже работает далеко не всегда. Либо задачи плохо масштабируются либо есть последовательная зависимость.
Почему вообще мы это разбираем?
Критический план без здорового может быть воспринят как норма. И без подсвечивания мер, долги либо вообще никогда не закроются, и продукт остается сырым, либо придётся бегать закрывать их в фоне уже следующей «горящей» задачи.
Поэтому, когда вы презентуете два плана, говорите прямо:
● можем сократить на X, если выводим людей в выходные — НО нужно больше денег
● можем забить на минорные дефекты — НО потом нужно отдельное время на исправления
● можем оформить техдолг по документации — НО нужно заранее забронировать время на ее написание
и так далее по списку
Чем прозрачнее вы это подсветите руководителям и заказчику, тем проще потом работать и защищать результат 
