Курс на гибкость и адаптируемость. Ни один метод в чистом виде не вывозит современный проект ни в стройке, ни в девелопменте, ни в производстве. Жёсткие методы не выдерживают внешних изменений. Мягкие тонут в своей неопределённости.
В этом и польза гибридов. Их задача — не дать проекту умереть под тяжестью неопределённости и одновременно не скатиться в хаос «гибких подходов».
Расписывать все возможные гибридные методы — занятие бесполезное и, честно говоря, скучное. Их десятки, и половина рождается прямо на проектах, а не в книжках. Мы и не собирались давать “каталог решений”. Вместо этого — предлагаем: не искать готовый рецепт, а собирать свою управленческую систему. И вот несколько примеров.
LPS (Last Planner System)+ Scrum
Представьте стройку, где 100 людей, 15 компаний и конечно же все идет не так как планировали. Здесь нужен не просто график, а инструмент синхронизации реальности с планами. Поможет гибрид Last Planner System и Scrum.
Last Planner System — это когда люди на местах сами говорят, что реально могут сделать. Это не контроль, а прозрачность. Scrum — это когда выполнение задач разбивается на короткие циклы с постоянной обратной связью. Вместе они дают очень простую, но мощную формулу: мы не гадаем, мы проверяем гипотезы вживую.
История проекта
На пилотном проекте внедряли календарно-сетевое планирование. График на месяц составляли вдвоём — руководитель и куратор. Площадка не участвовала, её просто ставили перед фактом. В результате за месяц выполнялось не больше 2% от плана. И так три месяца подряд.
Когда пересобрали процесс и допустили площадку к планированию, стало ясно, в чём дело. Мы открыли ящик Пандоры — начали всплывать проблемы, о существовании которых руководство даже не подозревало. Площадка физически не могла выполнять задачи, потому что часть решений “застревала” на уровне офиса. До этого момента мы просто не видели этих узких мест.
Минусы LPS + Scrum
Не стоит питать иллюзий: проблемы не исчезают от самого факта внедрения LPS и Scrum.
Иногда всё работает наоборот — площадка начинает придумывать выполнимые только на бумаге обещания, чтобы не портить настроение руководству. Визуально — всё отлично. По факту — ноль движения.
Это и есть уязвимость метода: он требует честности, дисциплины и прозрачности, а не видимости активности. Если все делают вид, что работают — система просто не взлетит.
Придётся решать глубокий культурный конфликт: “производственники старой школы” и “гибкие методологии” смотрят на проект с разных планет.
Будет сопротивление. Будет саботаж. Придётся не просто управлять — придётся быть медиатором, иногда даже психотерапевтом.
И да — легко скатиться в имитацию. Вроде всё правильно: митинги идут, стендапы проходят, ретроспективы звучат… Но сути никто не понимает.
Это превращается в карго-культ: внешний облик Agile есть, а внутренняя работа — декоративная. Похож на Scrum, но не работает.
Плюсы LPS + Scrum
Но если всё же запустить систему правильно — она даёт прозрачность 80-уровня.
Любой участник — от инвестора до мастера — может подойти к доске (на стене или в цифре), и за пару минут понять:
- где мы в графике,
- где конкретно затык,
- кто за него отвечает.
И не нужно для этого специального ПО и супердосок. Можно начать с простого: стикеры на стене бытовки, WhatsApp-чат для летучек, доска задач в Excel.
Главное — не инструмент, а дисциплина общения.
А дальше включается главный эффект: проблемы не успевают копиться до состояния “тушим пожар”. Они вскрываются на ежедневной основе — пока ещё маленькие, решаемые за один звонок или вынос мусора.
Когда рабочий или прораб на летучке говорит: “Мне мешает куча мусора у третьей колонны”, а на следующий день её убирают — он чувствует свою причастность. И мотивация начинает расти.
LPS + Scrum меняют саму культуру: давать обещания только тогда, когда все ограничения сняты.
С чего начать?
Чтобы запустить этот метод соберите участников, определите основные этапы и их зависимости, двигайтесь от конечной цели к началу. Теперь составьте план на 6 недель вперед. И для каждой задачи на этих 6 недель задайте вопрос: «Что нам мешает ее сделать?». Запишите все ограничения - нет проекта, нет денег, нет людей. Назначьте ответственного и срок снятия каждого ограничения.
Теперь мостик от LPS к Scrum. Возьмите задачи на ближайшую неделю, с которых уже сняты все ограничения. Команда обязуется сделать их. Ну а от Scrum - ежедневные и еженедельные совещания. А совсем от Scrum если ежедневные совещания будут по 15 минут и не превратятся в балаган. Только по делу. Глобальные вопросы оставьте для тематических совещаний.
Это методика где вопросы — инструмент планирования, а не признак слабости или глупости.
Waterfall + Agile
Не смогли отказать себе в удовольствии рассказать про это комбинацию. Они настолько разные, что увидеть их в одной связке занятно. Давно дело было. Когда Agile считался не применим в стройке.
Сравнивать Waterfall и Agile — это как спорить, что лучше: танк или истребитель. Ответ: лучше иметь и то, и другое. Гибрид Waterfall + Agile — это не компромисс.
Гибрид Waterfall + Agile — это когда вы используете Waterfall для больших, предсказуемых и негибких этапов проекта (проектирование, получение разрешений, строительство - навряд ли окно появится раньше чем стена). А Agile — для тех частей, где нужна гибкость, быстрая обратная связь и творческий подход
Например, проектные вехи фиксированы. Но внутри каждой фазы — идёт Agile-управление: новые варианты решений, оптимизация, тестирование. Это как ехать по навигатору, но уметь перестраиваться, когда дорога перекрыта. Ты не теряешь цель, но выбираешь лучший путь.
Ежемесячное обновление графика. Что-то выполнили. Другие работы уползли вправо. И ползут и ползут. Последовательность и контрольные вехи остаются неподвижные. А вот поиск точек оптимизации, чтобы сократить отставание и потом регулярный мониторинг динамики - это и есть отголоски Agile.
Минусы Waterfall + Agile
Смешивая дорогой односолодовый виски с колой - вы не получите премиальный коктейль. Вы просто испортите хороший виски, а кола от этого лучше не станет. Так и этот метод при формальном подходе и без правил игры испортит все что только можно.
Waterfall ценит документацию и следование плану. Agile ценит работающий продукт и готовность к изменениям. Когда в одной команде сталкиваются эти ценности, начинается паралич. На что опереться при принятии решения? На утвержденный полгода назад проект (который прошел экспертизу) или на свежую обратную связь от заказчика?
На одном из проектов такая «ориентация на клиента» привела к серьёзному кассовому разрыву: пожелания заказчика учли, но не сразу внесли в проектную документацию. А деньги были государственные — без бумажки, как известно, ты сам знаешь кто.
А это самая популярная ошибка. Руководство объявляет: «Мы работаем по гибридной модели!». На деле это означает, что многомесячный план, составленный по Waterfall, просто нарезают на двухнедельные «спринты». Команда не может ничего менять, она просто отчитывается о выполнении кусочка старого плана каждые две недели. Это профанация, которая не дает никакой гибкости, но добавляет бессмысленных телодвижений и совещаний.
И всё бы ничего, но команда быстро привыкает, что планировать в таком режиме смысла нет: через две недели придёт заказчик и всё сломает. А улучшения предлагать тоже бесполезно: каждое предложение упирается в бесконечные согласования и комментарии «это не по проекту».
Результат — тихий саботаж. Люди просто перестают верить, что их действия на что-то влияют. План — формальность, Agile — красивое слово, а инициатива — что-то подозрительное и наказуемое.
Плюсы Waterfall + Agile
Мы вдоволь потоптались на костях гибридного метода, обсудив, как он порождает проекты-шизофреники и управленческий ад. Если все так плохо, возникает резонный вопрос: «Зачем люди вообще пытаются заниматься этим садомазохизмом?».
А затем, что при правильном, осознанном подходе — не слепом копировании, а вдумчивом конструировании — у этой парочки есть и плюсы.
Жёсткая часть Waterfall — это ваш контракт с инвестором, банком и, если уж по-честному, с логикой самого проекта. Она фиксирует всё, что менять поздно, опасно или безумно дорого: бюджет, ключевые сроки, несущие конструкции, пройденные экспертизы.
Жёсткая структура создаёт то, чего ждут финансовые директора и управляющие: предсказуемость. Когда точки понятны, можно строить денежные потоки, согласовывать кредиты, считать рентабельность.
Но как только вы выходите за пределы базовой конструкции — начинается жизнь. Рынок двигается, клиент решил внести изменения в проект, новые вводные прилетают с площадки и от партнёров. Здесь уже нужна не фиксация, а гибкость. Agile не отменяет фундамент, но позволяет двигаться свободно там, где это возможно и осмысленно.
Интересный факт
Человек, которому приписывают создание Waterfall, — Уинстон Ройс, — в своей статье 1970 года на самом деле описал не тот жесткий «водопад», который мы знаем. Он писал, что версия для заказчика должна быть, по сути, второй версией продукта, созданной после анализа и тестирования первой.
Cам того не ведая, он заложил идею итеративности и обратной связи. А мы больше 50 лет пытались использовать его идеи в самой примитивной и негибкой трактовке. Пора возвращаться к истокам.
C чего начать?
Думайте о проекте как о матрешке. Большая матрешка — это Waterfall. Маленькие внутри — это Agile.
Соберите всех: инвесторов, топ-менеджеров, ключевых инженеров. Определите главную цель, бюджет, ключевые этапы (milestones) и конечный срок. Зафиксируйте это в виде генерального плана-графика.
Разбейте большие этапы на подпроекты. Например, этап «Внутренняя отделка корпуса А». Для каждого такого подпроекта сформируйте кросс-функциональную команду. Эта команда работает по Agile.
Короткие циклы по 2-4 недели (спринты). В конце каждого спринта должен быть готов конкретный, осязаемый результат. Команда должна обладать определенной свободой, как достичь цели спринта, и может адаптировать план внутри него. Боитесь? Установите границы свободы. Главное не свалиться в микроменджмент.
Заключение
Большинство проектных команд уже интуитивно создают гибриды, просто не называют это так. Потому что жизнь сама заставляет. Потому что по-другому — не тянет.
Вопрос не в том, есть ли у вас эти элементы. Вопрос — насколько они настроены друг с другом. Работают ли они как система? Видит ли один метод слабость другого и закрывает её?
У вас уже есть многое. Но, возможно, именно комбинация даст результат, которого ещё не было.
Автор: Вера Питинова