Как вывести из кризиса забуксовавший проект
Что я проверяю в первую очередь, когда проект сорвал сроки и потерял управляемость: типичные корневые причины кризиса и последовательность восстановления.
Запрос, с которым ко мне чаще всего обращаются по проблемным проектам, формулируется одинаково: «нужно ускориться» — добавить разработчиков или ужесточить сроки. В большинстве случаев это решение лишь усугубляет ситуацию. Проект, теряющий управляемость, страдает не от нехватки скорости, а от утраченной ясности: в требованиях, в архитектуре и в отношениях между бизнесом и командой.
За время работы я разбирал десятки таких ситуаций. Внешние признаки у них схожи: сорванные сроки, перенесённый релиз, работа по выходным, отсутствие предсказуемой даты завершения. Однако это симптомы, а не причины. Воздействие на симптомы — дополнительные люди, переработки, давление — проблему не устраняет и обычно ускоряет деградацию.
Первый этап — диагностика, а не действия
Работу я начинаю не с кода и не с пересмотра графика, а с диагностики. В первую очередь провожу отдельные беседы с представителями бизнеса и с инженерами. Как правило, две стороны описывают один и тот же проект по-разному, и именно в этом расхождении находится источник проблемы.
Затем анализирую не текущее состояние кодовой базы, а её историю: где регулярно задерживаются задачи, что переделывается повторно, какие архитектурные решения принимались и на каком основании. Код даёт значительную часть картины, но решающую информацию обычно дают люди.
Типичные корневые причины
Первая и самая распространённая — отсутствие общего понимания предмета работы. Бизнес рассчитывает на один результат, команда реализует другой, а граница между ними постепенно смещается. Увеличение темпа здесь контрпродуктивно: чем быстрее движется команда, тем дальше она уходит от исходной цели.
Вторая — архитектурные решения, принятые в отрыве от бизнес-контекста: либо избыточно проработанная система, решающая не ту задачу, либо временный прототип, на который продолжают наращивать промышленную функциональность. Оба варианта со временем становятся источником системных сбоев.
Третья — технический долг, вышедший за допустимые пределы. Сам по себе он неизбежен и управляем. Проблемой долг становится тогда, когда им перестают заниматься, и каждое последующее изменение начинает затрагивать несоразмерно большой объём кода.
Четвёртая причина редко фиксируется в отчётности, но присутствует почти всегда — утрата доверия между бизнесом и разработкой. Заказчик перестаёт полагаться на оценки команды, команда — на то, что её аргументы будут услышаны. Проект переходит в режим работы на износ, без устойчивых процессов, и именно этот режим истощается первым.
План восстановления
Полная переработка системы с нуля — почти всегда ошибочное решение. Оно выглядит привлекательно, но на практике означает потерю времени и накопленного в текущем коде знания.
Последовательность, которой я придерживаюсь, иная. Сначала стабилизация: зафиксировать работающую часть системы и прекратить вносить в неё изменения. Затем приоритизация совместно с бизнесом — определить, что действительно необходимо для ближайшей цели, а что может подождать. Параллельно восстанавливается рабочая коммуникация между сторонами, поскольку без доверия любой план теряет устойчивость при первой негативной новости. И только после этого, небольшими контролируемыми шагами, ведётся работа с техническим долгом и архитектурой — там, где они объективно препятствуют развитию.
Решения, которые не работают
Расширение команды на кризисном проекте, как правило, дополнительно замедляет его: новых участников требуется вводить в контекст, а ресурса для этого нет. Ужесточение сроков ведёт к новым компромиссам по качеству, которые проявятся позднее. Переработка с нуля приводит к потере времени и контекста. Эти три решения, кажущиеся очевидными, и доводят проекты до состояния, в котором привлекают внешнего специалиста.
Резюме
В большинстве случаев проект удаётся вывести из кризиса не за счёт мобилизации ресурсов, а за счёт восстановления ясности: согласованного понимания целей и предметного диалога между заказчиком и исполнителем. Технические проблемы решаются на следующем этапе, и их объём обычно оказывается меньше, чем представляется в условиях кризиса.