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

Живой пример

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

Дальше началось все самое интересное. Я погрузилась в проект и обнаружила, что половина срока реализации проекта уже прошла, требования ещё не сформулированы, команды проекта нет, а образ результата звучит как «сделай красиво». И тут мой немой вопрос, почему сняли прошлого руководителя проектов, отпал сам собой. Пришлось быстро включаться и что-то придумывать.

Первым делом я организовала регулярную коммуникацию с заказчиком, выявила все заинтересованные стороны, сформировала рабочую группу, надела шапочку бизнес-аналитика и отрисовала, как должны работать все процессы (да, любой РП – мультиинструменталист, а вы как думали? :) ). Затем оценила, в какой реалистичный срок мы можем выполнить этот проект с учётом простоя в предыдущие полгода, и договорилась об увеличении срока исполнения с 1 до 2 лет.

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

Но, как вы уже могли догадаться из названия статьи, хэппи энда у этой истории не будет. Меня позвали работать в другую компанию и предложили существенный рост. Я приняла предложение о новой работе, собрала все материалы по этому проекту и передала их в руки нового руководителя. О дальнейшей судьбе проекта мне известно, что «делали» его ещё 2,5 года после моего увольнения, и в конце концов закрыли со словами «да и черт бы с ним». К желаемому итоговому результату так и не пришли, и по сей день пользуются теми доработками, которые мы успели сделать за время моей работы.

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

Симптомы провала: как понять, что проект болен

Дело не в одной конкретной ошибке, а в их множестве и повторении. Разберёмся с ключевыми симптомами, которые показывают: в проекте что-то идёт не так.

Симптом №1: Требования меняются чаще, чем погода в Петербурге

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

Симптом №2: Команда перестаёт разговаривать

Диалоги сводятся к «когда уже будет готово?» и «это не баг, это фича». Разработчики уходят в глухую оборону, менеджеры делают вид, что всё под контролем, а заказчик подозревает, что его обманывают. Если митинги напоминают допрос с пристрастием, а не совместный поиск решений — проект в реанимации.

Симптом №3: Бюджет тает, а сроки плывут

Вы потратили 80% бюджета, а готово только 30% функционала. Сроки сдвигаются так часто, что в них уже никто не верит. Если каждый спринт заканчивается переносом релиза, а оценка задач напоминает гадание на кофейной гуще — это не временные трудности, это системный кризис.

Симптом №4: Качество — понятие абстрактное

Баги плодятся быстрее, чем их успевают чинить. Тестировщики пишут новеллы в баг-трекере. Пользователи жалуются, что интерфейс вызывает желание выбросить телефон в окно. Если каждый новый фикс ломает две старые функции, а техдолг растёт как снежный ком — проект не развивает свой продукт, а рушит его.

Симптом №5: Все ненавидят этот проект

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

Что делать, если проект в агонии

Главное — перестать делать вид, что всё в порядке.

Шаг 1: Остановиться и признать проблему

Соберите всех, кто ещё не сбежал, и без розовых очков посмотрите на ситуацию. Задайте три вопроса:

1. Что мы делаем? Есть ли чёткое, неизменное видение продукта?

2. Зачем мы это делаем? Решает ли это реальные проблемы пользователей?

3. Почему сейчас всё идёт не так? Ответьте честно, без поиска виноватых.

Если ответы звучат как «хм…», «ну…» и «вообще-то…» — у вас нет проекта. У вас есть хаос с дедлайнами.

Шаг 2: Если требования превратились в чудовище Франкенштейна — убейте его

Вернитесь к первоначальной цели или определите новый минимальный жизнеспособный продукт (MVP), который можно сделать за разумные сроки. Выбросьте 70% хотелок. Да, это больно. Но продолжать бессмысленный и беспощадный труд — ещё больнее.

Шаг 3: Перестаньте прятать проблемы

Если код — говно, назовите его говном. Если сроки нереальны, скажите это прямо. Введите правило: «Никаких намёков, только факты». Иногда один честный разговор стоит месяца «оптимизаций».

Шаг 4: Спасите то, что ещё можно спасти

Проанализируйте, что уже работает. Может, не всё так плохо? Если у вас уже готовы 20% функционала, приносящие 80% ценности, попробуйте выпустить в прод то, что есть. На этом этапе конкретная обратная связь пользователей по работе неидеального продукта будет полезнее ваших теорий «а что подумают пользователи?».

Шаг 5: Принять крайние меры

Если проект пожирает ресурсы, не проносит ничего, кроме стресса, и, проделав все предыдущие шаги, света в конце тоннеля вы не обнаружили — проект нужно закрыть. Да, это провал. Но продолжать вливать время и деньги в бездну — провал бОльшего масштаба. Иногда достойное поражение лучше бессмысленной борьбы.

Провальный IT-проект как болезнь: чем раньше вы увидели симптомы, тем выше шанс на излечение. Если все симптомы налицо, не надейтесь на чудо: либо реанимируйте проект жёсткими методами, либо закопайте с почестями и извлеките уроки. Главное —не позволяйте мёртвому проекту продолжать пожирать вашу команду, бюджет и веру в себя.

А у вас был проект, который следовало бы похоронить, но вы тащили его годами? Поделитесь историями — вместе поржем (или поплачем) :)