Не скрамом единым: 10 нетривиальных концепций управления проектом Серия постов - 4 /5 . Лайк, коммент, репост, если такой контент норм 😕. 7. Главным тормозом проекта могут быть не исполнители, а руководство:[задержка принятия решений (Decision Latency)](https://watech.wa.gov/sites/default/files/2025-06/WaTech Best Practices Summary_June 2025_v5.0_FINAL.pdf) А эта идея вообще довольно болезненная, потому что мы привыкли измерять скорость исполнения гораздо охотнее, чем скорость руководства. Допустим, разработчик выполняет задачу пять дней. Руководитель считает, что это медленно, наезжает и начинает говорить про производительность, эффективность и оптимизацию, в итоге срок удается сократить до четырех дней, и все чувствуют, что поработали не зря. После этого разработчик задает вопрос руководству и шесть дней ждет ответа. Но почему-то эти шесть дней производительностью уже не считаются.

В отчете WaTech за 2025 год рассматривается показатель "задержка принятия решений" -  сколько времени проходит между моментом, когда решение понадобилось, и моментом, когда его наконец приняли. Идея мне кажется даже полезнее конкретных цифр, потому что заставляет посмотреть на проект с другой стороны.

Представим задачу, где день ушел на разработку, четыре дня - на ожидание ответа, еще два дня - на доработку и еще пять - на согласование. В отчете получится, что задача выполнялась 12 дней, после чего кто-нибудь предложит повысить производительность разработчика процентов на двадцать. Ну да, было три дня реальной работы, станет два с половиной. Теперь задача займет не 12 дней, а 11 с половиной. Победа очевидно “впечатляющая”.

Так что возможно, что в проектах полезно измерять не только загрузку исполнителей, но и среднее время жизни вопроса, который требует управленческого решения.

8. Проект должен не выдерживать неприятности, а получать от них пользу:концепция антихрупкости сложных проектов (Antifragility Hierarchy) Антихрупкость, как все знают, придумал Нассим Талеб, но в конце 2024 года появилась работа Грега Ашера, Шанталь Кантарелли, Кейт Дэвис, Джеффри Пинто и Нила Тернера именно об антихрупкости сложных проектов (и, кстати, еще раньше - Саша Бындю).

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

Звучит мазохистски 🙌, но идея понятная. Например, внезапно уходит единственный разраб или подрядчик, на котором держится критическая часть системы. Сначала это катастрофа, но команда вынуждена избавиться от технологической зависимости, которую пять лет считала неизбежной, и через полгода система объективно здоровее, чем до кризиса.

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