Сбой в системе: когда проектная деятельность – это головная боль.

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

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

Корень зла почти всегда скрывается в одном из базовых системных архетипов, описанных ещё Питером Сенге и его коллегами. Самый коварный и самый распространённый в управлении проектами архетип называется «Смещение бремени». Выглядит он дьявольски просто, и именно в этой простоте его разрушительная сила.

Представьте: проект начинает отставать от графика. Возникает напряжение. Руководитель, вместо того чтобы сесть и спокойно разобраться в первопричинах задержки, делает то, что приносит немедленное облегчение, — подключает дополнительных людей, вводит вечерние созвоны, давит авторитетом и в режиме ручного управления проталкивает задачу к финишу. Симптом снят, проект сдан, все выдыхают.

Но что происходит в системе? Фундаментальная проблема, которая вызвала отставание — будь то размытые требования на старте, отсутствие автоматизированного тестирования или хронический дефицит код-ревью — остаётся нетронутой. Более того, способность команды решать такие проблемы самостоятельно атрофируется, потому что каждый раз приходит «сильный лидер» и героически всех спасает.

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

Суть анализа дерева отказов (Fault Tree Analysis, FTA) проста: вы берёте одно конкретное, повторяющееся нежелательное событие (то, которое уже набило оскомину) и начинаете раскладывать его на составные части, задавая вопрос «Из-за чего конкретно это могло случиться?» не один раз, а до тех пор, пока не упрётесь в управляемый фактор.

Возьмём кейс, который будет близок каждому, кто связан с офлайн-бизнесом или франчайзингом: открытие новой точки. Собственник сети из десяти кофеен формата «кофе с собой» (назовём его Олег) с завидной регулярностью сталкивался с тем, что запуск каждой новой точки задерживался на две-три недели относительно плановой даты. Каждый раз он искренне верил, что учёл прошлые ошибки: нанял другого прораба, заказал оборудование заранее, лично контролировал согласование вывески. Но результат повторялся.

На уровне ощущений причина была размыта: «У нас просто невозможно открыться вовремя, вечно что-то идёт не так». Но когда Олег вместе с операционным директором применили логику FTA и сели разбирать последний кейс — открытие точки в новом жилом квартале, — картина перестала быть размытой.

Вершина их дерева — событие: «Точка не начала работу в запланированную дату». От неё идут основные ветви. Одна из ветвей называлась «Не готова входная группа». Это была самая частая причина прошлых задержек. Казалось бы, вот он, корень зла: строители-отделочники подвели. Но они применили дисциплину FTA и пошли глубже. Почему не готова входная группа? Потому что монтаж дверей и витража был выполнен с задержкой на пять дней.

Следующий уровень: почему задержали монтаж? Ответ лежал на поверхности: «Бригада монтажников приехала на объект, но не смогла установить конструкцию, так как проём не соответствовал размерам, пришлось перезаказывать элементы». Стоп. Это уже не «плохие строители». Это сбой в цепочке передачи информации.

Почему проём не соответствовал? Строители, делавшие черновую отделку, получили на руки один комплект чертежей, а компания, изготавливавшая витраж, — другой, более старый. Олег стал проверять: «Я же лично передавал финальный план!» Но когда подняли почту и чаты в мессенджере, выяснилось: финальный чертёж был отправлен прорабу в мессенджере в виде фотографии, плюс параллельно в CRM висел прикрепленный документ с устаревшим чертежом. Инженер по закупкам взял то, что было в программе.

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

Фундаментальным решением, рождённым из анализа дерева отказов, стало простое правило: все чертежи для строителей и смежников теперь хранятся только в одной папке в корпоративном «облаке» с жёстким версионированием, а в задачу в CRM ставится не файл, а прямая ссылка на эту папку. Любое изменение документа фиксируется уведомлением всем участникам процесса.

Следующие три открытия прошли с отклонением от графика не более чем на два дня. Система была починена не героическими усилиями собственника, а дисциплиной выявления истинной причины на четвёртом уровне глубины. FTA помог Олегу увидеть не просто вину строителей, а структурную дыру в документообороте, которая каждый раз воспроизводила задержку.

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

Сбой перестаёт быть врагом, когда мы начинаем видеть в нём не повод для разноса, а сигнал для настройки вашей бизнес-системы.