Расскажу о недавнем кейсе на одном проекте из финтеха, на котором мы немного облажались.

Как у нас организованы спринты (на проектах, где работаем по задачам)?

Заказчик определяет список задач, мы проставляем планируемое время, отправляем на утверждение.

Если всё ок, то берём в работу.

Среднее превышение у нас — 20% над первоначальной оценкой.

Так вот что случилось: дошли до этапа сборки стенда, и что-то пошло не так. Сервисы не соединялись, мощностей не хватало. Кое-как собрали. Обнаружили кучу багов, в том числе от старой команды.

Итого превышение — в 2 раза.

Возникает логичный вопрос: почему не сообщили?

Интересно то, что это даже предусмотреть нельзя было. Уткнулись в одну проблему, думали: «Ну ок, щас потратим 2–3 часа и поднимем». Потом ещё 2–3 часа, потом ещё... Ну и в итоге вышли на то, на что вышли.

Следующий вопрос: как теперь объяснить клиенту и отстоять затраченное время?

Естественно, как и любой нормальный человек, клиент был в шоке и не понимал, что там можно было делать за столько часов.

Полтора часа объяснений его не очень убедили, и, когда остались один на один, ответ был таков: «Оплатим первоначальную оценку + 25%, как написано в договоре».

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

Мой вам совет — читайте книги по переговорам, тренируйтесь. Как раз одну книгу разбирали в клубе, по ней запишу подкаст.

В итоге вместо срезания 70% срезали 20% — в целом заслуженно, будет нам уроком.

Мне нравятся вот такие ситуации — на острие. Они сильно выматывают, но именно здесь ты показываешь настоящее мастерство.

Но, естественно, надо сделать выводы и больше такого не допускать.

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