Почему даже у опытных команд может гореть жопа дедлайн 🤘 Среди моих коллег и клиентов часто гуляет один миф: если команда опытная, значит проекты у неё всегда идут чётко по таймингу, без сдвигов и форс-мажоров. На практике же горит даже у тех, кто делает сайты и продукты много лет подряд. В этом посте я хочу разобрать основные причины из своего опыта и опыта моих коллег по цеху: ➡️Причина первая: "эффект знакомого проекта" Когда команда уже работала с похожими нишами, задачами или форматами, появляется ощущение, что всё понятно заранее. Мы быстрее стартуем, меньше уточняем и чаще полагаемся на свой прошлый опыт. Проблема в том, что ни один проект не повторяется на 100%: отличается бизнес-модель, процессы внутри компании, ожидания клиента, ограничения по бюджету и срокам. В моменте это кажется несущественным, но по ходу проекта именно эти различия начинают всплывать и требовать времени на переосмысление решений. ➡️Причина вторая: скорость работы выше скорости принятия решений. Почти любой мой проект упирался в этапы согласований: долгие обсуждения, возвраты с комментариями, фразы "давайте подумаем", "а если попробовать другой стиль" растягиваются сильнее, чем сама работа. В итоге кажется, что команда тянет, хотя по факту она просто ждёт финального фидбэка от клиента. ➡️Причина третья: ТЗ почти всегда дорабатывается ТЗ обычно фиксирует общее видение проекта на старте, но по мере работы бизнес может менять приоритеты, появляются новые вводные и корректируются цели. Команда оказывается в ситуации, когда из-за доработки задания приходится корректировать всю концепцию и логику. Особенно это касается больших продуктовых проектов, в котором множество путей взаимодействия с пользователем. ➡️Причина четвёртая: опытные команды берут ответственность раньше, чем всё понятно Начинающие исполнители чаще всего ждут максимально подробных вводных, полного брифа и стопроцентной ясности ещё до старта работ. Опытные команды действуют иначе: они начинают работу, понимая, что часть вопросов неизбежно прояснится уже в процессе. Такой подход позволяет запускать проекты быстрее, но одновременно увеличивает количество решений, которые приходится принимать по ходу. Наша команда как раз работает в этом формате - мы помогаем клиенту увидеть общую картину, предлагаем решения, показываем альтернативы и берём на себя инициативу в согласованиях. ➡️Причина пятая: накопительный эффект микроулучшений По моему опыту, редко сроки сдвигаются из-за одной крупной ошибки. Гораздо чаще это десятки мелких улучшений: чуть упростили пользовательский путь, переписали тексты, сделали интерфейс понятнее или улучшили логику экранов. Каждое такое изменение кажется незначительным, но в сумме они дают заметный прирост времени. Это осознанный выбор в пользу качества, который редко закладывается в первоначальный дедлайн полностью. 🕋Что действительно помогает держать сроки? Практика показывает, что важнее любых планов работают быстрые решения, наличие одного ответственного человека за выбор (а не когда клиент показывает макет жене, теще, маме, соседу), заранее согласованные контрольные точки (у нас их 4: сдача исследований, демонстрация прототипа, презентация дизайна и финальная сдача готового продукта) и понимание, где проект уже достаточно хороший. ⭐️Что мы даём клиенту, когда сдвигаем сроки: Если моя команда понимает, что мы не укладываемся в сроки, то клиент всегда может быть уверен, что получит различные бонусы: дополнительные месяцы технического обслуживания и гарантии на продукт, 1-2 варианта концепций макета или хорошая скидка на любые наши дополнительные услуги. К тому же, в договоре с клиентом у нас четко прописана ответственность за любые нарушения сроков и размер пени.