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

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

Мне стало интересно собрать такие идеи в одном месте и посмотреть, не складываются ли они во что-нибудь общее (я ж аналитик). Сразу оговорюсь, что далеко не все концепции из списка супер-свежие, но именно в последние пару лет либо получили новое развитие, либо начали появляться в вполне серьезных исследованиях.

Если интересно, давайте пробежимся по верхам.

1. Возможно, вам вообще не нужен проект: переход от проектов к продуктам (Project to Product)

Книга Мика Керстена

Начнем с неприличного вопроса: а зачем нам (организации) нужен проект?

Допустим, компания развивает личный кабинет клиента. Сначала появляется «Проект внедрения личного кабинета», через год — «Проект модернизации», потом — «Проект мобильной версии», затем — «Интеграция с CRM», а еще через какое-то время, конечно, «Личный кабинет 2.0» — типа он повзрослел и возмужал… С точки зрения компании за это время прошло пять проектов, а с точки зрения клиента все эти годы существовал, собственно, один и тот же личный кабинет, который иногда (реже) становился лучше, иногда (чаще) хуже.

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

Сама идея не новая, ее довольно последовательно развивал Мик Керстен в книге «От проекта к продукту», но сейчас она обсуждается уже не просто как способ организовать разработку, а как полноценная модель финансирования и управления постоянными командами.

Конечно, не переживайте, никто не предлагает отменить проекты вообще. Если мы строим склад, он в какой-то момент должен быть построен, иначе разговор о продуктовой модели становится несколько странным. Но если мы восьмой год подряд запускаем «проект развития корпоративного портала», возможно, дело не том, что у нас просто есть портал, который надо постоянно развивать.

Вот и получается, что одна из задач зрелого проектного управления — это вовремя понять, что новый проект вообще не нужен, нужно просто “докручивать” уже имеющися продукт и уже не проектным подходом.

2. Хорошая организация должна чаще закрывать проекты: парадокс отмены (Cancellation Paradox)

Исследование

С начатыми проектами есть один косяк: они очень хотят жить, причем иногда заметно сильнее, чем этого заслуживают.

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

Приходит здравый смысл и говорит, что проект надо закрывать, но тут возникает классическое «мы уже столько вложили, вы чего, э…». То есть уже потраченные деньги начинают работать аргументом в пользу того, чтобы потратить еще столько же, хотя экономически между первым и вторым нет никакой логической связи.

В исследовании Tempo за 2026 год (ссылка выше) есть такой прикол: организации, которые чаще пересматривают приоритеты, заметно чаще закрывают проекты и при этом получают большую долю проектов, которые действительно создают измеримую ценность. Авторы называют это «парадоксом отмены». Причем закрытие не обязательно означает, что проект был плохим с самого начала или кто-то все сделал неправильно; проект мог быть абсолютно разумным год назад, просто бессовестный мир за это время имел наглость измениться, а организация почему-то решила, что после запуска сдавать назад уже неприлично.

Отсюда и идея считать не только долю проектов, успешно доведенных до конца, но и, например, сколько денег компания не потратила, потому что вовремя остановилась. Кстати, заметьте этот тренд в нынешнем медиабизнесе — сколько игр и фильмов отменяются на полпути, а иногда и незадолго до релиза. Это не психопаты у руля, а вот те, кто осознал эту идею.

3. Чтобы лучше прогнозировать сроки, иногда полезно перестать их оценивать: управление без оценок (NoEstimates)

Статья про подход

Если дождаться созвона с гендиром и с улыбкой заявить: «Мы решили больше не оценивать сроки», — то после этого разговор, скорее всего, быстро закончится, а у вас как РП появится свободное время для поиска новой работы (наверное).

Концепция “управления без оценок” предлагает различать две вещи, которые мы очень часто смешиваем: оценку и прогноз. Допустим, у команды есть 50 относительно небольших задач. Можно собрать людей и начать выяснять, сколько займет каждая: эта — четыре часа, эта — восемь, эта — двенадцать, хотя похожая в прошлый раз была шесть, но тут интеграция сложнее, а там разраб уже знает код. Через несколько часов у нас появляется таблица с числами, которая выглядит очень научно и вызывает приятное ощущение контроля.

Но есть и другой вариант — посмотреть, что реально происходило последние полгода. Если команда стабильно закрывает, скажем, от 18 до 25 похожих задач в неделю, у нас уже есть фактическое распределение производительности, а значит, можно прогнозировать срок завершения всей очереди без попытки угадать длительность каждого отдельного элемента.

Тогда вместо фразы “закончим 19 ноября” можно сказать «с вероятностью 85% закончим до 28 октября». Первое звучит точнее только потому, что там одна конкретная дата, но сама эта точность может быть чисто… декоративной. Мы же знаем, что если взятую с потолка хрень написать с двумя знаками после запятой, она внезапно начинает выглядеть гораздо убедительнее.

Соответственно, смысл подхода довольно примитивный,  но интересный: если у вас есть поток похожей работы (и не супер-ответственной вроде строительства атомной станции), иногда полезнее прогнозировать поведение всей системы, чем заставлять людей подробно угадывать будущее по каждой отдельной задаче (и тратить доп. время).

4. Не спрашивайте, сколько времени займет работа. Спросите, сколько времени она заслуживает: фиксированное время и изменяемый объем (Fixed Time, Variable Scope) из Shape Up

Публикация Basecamp (увы, недоступна в нашем регионе)

Эта конепция меняет местами привычный разговор между бизнесом и командой. Обычно все начинается, естественно, с требований. Заказчик приносит список, потом вспоминает еще десять вещей, через день кто-то добавляет мобильную версию / блокчейн / ИИ-фичу, через неделю появляется обязательная выгрузка в эксель, а еще через две недели становится известно, что все это желательно закончить примерно вчера. После этого разработчиков спрашивают, сколько времени займет реализация, разработчики называют неприятную (с кучей буферов) цифру, все расстраиваются и начинается обсуждение того, почему команда снова «завышает оценки».

В Shape Up предлагают сначала ответить на другой вопрос: сколько времени эта проблема вообще заслуживает? Не сколько займет идеальное решение, а сколько времени мы готовы на него потратить. Например, при ответе “четыре недели” команда уже проектирует такой вариант решения, который действительно помещается в эти четыре недели.

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

5. Чтобы закончить быстрее, иногда нужно позже начать: нулевая стадия проекта (Stage Zero), или «замедлиться, чтобы ускориться» (Slow Down to Speed Up)

Публикация

Фраза «мы быстро запустили проект» звучит ок, а «мы три месяца выясняли, что не надо было его запускать» — уже не ок, хотя второй вариант сэкономил бы N месяцев работы и неплохой бюджетик.

House of PMO в прогнозе на 2026 год называет одним из трендов «нулевую стадию проекта», то есть сознательную работу до официального старта. При этом важно не перепутать эту идею с привычной бюрократией, когда можно три месяца писать концепцию, потом четыре месяца согласовывать концепцию концепции, а затем создать рабочую группу по выбору даты следующего совещания.

Смысл ровно обратный. До старта проекта идея же очень дешевая: есть несколько людей, расчеты, презентация и возможность спокойно сказать «мы ошиблись, не стоит вскрывать эту тему». Но после запуска появляются бюджет, KPI, команда, договоры, сроки, руководитель проекта и человек из руководства, который уже публично назвал инициативу стратегической, после чего признать ошибку становится психологически и политически значительно дороже.

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

6. Чем больше контроля, тем иногда меньше управляемость: минимально достаточное управление (Minimum Viable Governance)

Работа MIT

У корпоративных процедур есть прекрасный естественный механизм размножения. Что-то пошло не так — добавили согласование. Через год случилась другая проблема — добавили еще одно. Потом появился чек-лист, потом человек, который проверяет чек-лист, затем таблица, подтверждающая факт проверки чек-листа, и в какой-то момент простое изменение начинает проходить согласование дольше, чем строился Колизей. При этом никто специально не ставил задачу построить бюрократический ад в отдельно взятом Газмяспроекте. Наоборот, каждое отдельное правило когда-то выглядело вполне разумно и решало конкретную проблему, — ну просто никто потом не пришел и на голубом глазу не спросил, нужна ли эта защита до сих пор.

MIT CISR в 2026 году предложил термин «минимально достаточное управление». Изначально речь шла о генеративном ИИ, но сама логика отлично переносится на проекты: есть нижняя граница контроля, ниже которой начинается бардак и неприемлемый риск, но есть и верхняя, после которой дополнительный контроль уже не столько защищает, сколько создает новую проблему — организация перестает успевать что-либо делать. Отсюда следует довольно полезный вопрос для любого регламента: «Что конкретно случится, если это согласование убрать прямо вот сейчас?» И возможно, проектный офис должен иногда не создавать очередной процесс, а брать старые процессы и аккуратно выносить их на помойку. Это, в общем-то, тоже управление, просто выглядит не так торжественно и ритуально и хуже подходит для презентации на 40 слайдов.

7. Главным тормозом проекта могут быть не исполнители, а руководство: задержка принятия решений (Decision Latency)

Отчет WaTech

А эта идея вообще довольно болезненная, потому что многие привыкли измерять скорость исполнения гораздо охотнее, чем скорость руководства.

Допустим, разработчик выполняет задачу пять дней. Руководитель считает, что это медленно, наезжает и начинает говорить про производительность, эффективность и оптимизацию, в итоге срок удается сократить до четырех дней, и все чувствуют, что поработали не зря. После этого разработчик задает вопрос руководству и шесть дней ждет ответа. Но почему-то эти шесть дней производительностью уже не считаются.

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

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

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

8. Проект должен не выдерживать неприятности, а получать от них пользу: концепция антихрупкости сложных проектов (Antifragility Hierarchy)

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

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

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

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

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

9. План нужно строить не из настоящего в будущее, а из будущего в настоящее: теория действия проекта (Action Theory of the Project)

Наверное, самая академическая идея из списка, но при этом одна из самых практичных.

В 2024 году Грэм Уинч опубликовал работу «Теория действия проекта», где среди прочего развивается идея мышления из завершенного будущего. Мы обычно начинаем планирование с сегодняшнего дня: вот что у нас есть сейчас, вот что надо сделать дальше, потом еще один шаг, затем еще один, и так постепенно… PROFIT.

А можно двигаться в обратную сторону и сначала представить, что желаемое будущее уже наступило. Например: «Через год менеджер видит всю историю работы с клиентом в одном месте, не ведет таблички в экселе и готовит предложение за десять минут». После этого мы начинаем идти назад и выяснять, что должно было произойти, чтобы такое состояние вообще стало возможным.

Это совершенно другой дискурс, нежели «нам надо внедрить CRM», потому что во второй формулировке решение уже незаметно выбрано. Нам нужна CRM, осталось ее выбрать, купить, внедрить и потом несколько лет выяснять, почему менеджеры все равно продолжают писать контакты и планы в ежедневниках.

А вот в первой формулировке CRM — всего лишь один из возможных вариантов. Потому что может оказаться, что существующая система уже умеет половину нужного, а проблема находится в процессе, данных или вообще в людях. Иногда после этого проект становится заметно дешевле, а иногда исчезает вообще, что тоже, если подумать, вполне достойный результат (см концепцию 1).

10. Опытному руководителю проекта иногда нужно учиться забывать: проектное разучивание (Project-Based Unlearning)

Исследование

И последняя в этом списке идея.

Мы привыкли считать опыт однозначным преимуществом: чем дольше человек работает, тем больше он знает, а значит, тем лучше должен работать. Логика железная, но есть нюанс. Вместе со знаниями человек приобретает еще и уверенность в том, как «обычно правильно».

В 2024 году Бассам Хуссейн и Берта Нгережа опубликовали исследование разучивания в проектной среде, то есть не того, как организация получает новые знания, а того, как она сознательно избавляется от старых. Есть временное разучивание, когда подход в целом полезен, но в конкретном проекте его лучше не применять, и есть постоянное, когда человек признает, что какая-то практика или убеждение больше не работает вообще.

Концепция жесткая, потому что за 10-15-20 лет работы человек успевает усвоить, что без подробного плана будет бардак, требования надо утверждать, изменения следует контролировать, ответственность должна быть закреплена, заказчика к разработчикам лучше напрямую не пускать, а вот этот подход мы уже пробовали в 2017 году и ничего из него не вышло.

Причем и человек этот совсем не дурак, и каждое убеждение написано кровью, оплачено реальными деньгами, нервами и ночными релизами. Проблема только в том, что реальный опыт довольно легко превращается в рефлекс. В результате возникает красивый парадокс. Новичок опасен тем, что многого не знает, а эксперт — тем, что слишком многое уже знает наверняка. Поэтому профессиональное развитие может выглядеть как принцип «я знаю сто методов и научился замечать, какие двадцать в этой ситуации лучше забыть».

Вместо выводов

Можно, конечно, сказать, что мы нашли десять разнородных красивых и не очень концепций, однако если поставить эти идеи рядом, то видно некоторое семейное сходство. Возможно, отношение к проектному управлению меняется. Классический РП во многом занимается превращением неопределенности в определенность. Неизвестно, сколько займет работа — оценим. Неизвестно, что может случиться — заведем реестр рисков. Непонятно, кто решает — закрепим ответственность. Что-то меняется — введем управление изменениями. В этом, конечно же, нет ничего плохого. Это нормально и это везде и требуется. Тем не менее часть неопределенности никуда не девается, сколько бы табличек мы не бахнули. Мы не знаем, что через полгода сделает конкурент, понадобится ли пользователю функция, которую он сегодня очень убедительно требует, уволится ли ключевой специалист и какое событие окажется самым важным именно потому, что никто не догадался включить его в реестр рисков.

Отсюда появляется другая логика: 

• не пытаться заранее сделать правильными все решения, а сделать ошибки дешевыми; 

• не пытаться любой ценой закончить все начатое, а научиться вовремя останавливаться; 

• не пытаться предусмотреть каждую неприятность, а строить команды, которые способны нормально соображать после того, как неприятность уже произошла; 

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

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