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

Напоминаю исходную точку: 🔻 Продукт заказчикам показывать сегодня 🔻 Разработчики работу не сдали и ушли в закат 🔻 Заказчики бушуют 🔻 Руководство в ярости 🔻 Ваш второй глаз начинает дергаться в такт секундной стрелке часов

Мои предложения по решению ситуации:

1️⃣ Самый важный момент – найти нового исполнителя горящей задачи.

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

2️⃣ Договориться с заказчиками. Если они ждут сегодня, а сдавать им нечего –объяснения неизбежны.

▫️ открытый и честный разговор с заказчиками – лучше, чем придумывать оправдания, поэтому я выхожу на созвон и честно говорю: «да, мы допустили ошибку, наш косяк. Нам очень жаль, но мы уже приняли все меры и исправим к -- числу». Конечно, честность дозированная – всю внутрянку процесса раскрывать не стоит, но и юлить про стуацию – тоже. Так и заказчики в курсе актуальной ситуации, и уровень доверия не опустится ниже плинтуса.

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

▫️ Если со стороны заказчика есть pm/рп – дружите с ним. Хорошие специалисты со стороны заказчика в этой ситуации ваши лучшие помощники, потушить свою организацию им проще, чем вам – чужую. Важно не злоупотреблять: их доброта не вечна.

3️⃣ Ретроспектива. Если такая ситуация произошла, то где-то явно есть мой менеджерский косяк:

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

4️⃣ Разговор с бушующим начальством.

Здесь я тоже за открытость. 💬 Возникла проблема, потому что: 1. … 2. … 3. … 💬 Чтобы исправить ситуацию, я сделала: 1. … 2. … 3. … 💬 С заказчиками договорилась о следующем: 1. … 2. … 3. …

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