Почему срываются дедлайны в IT — честно изнутри

За годы работы я понял простую вещь: вопрос «почему вы не уложились в срок» почти всегда задают не там, где находится настоящая причина. Срыв дедлайна — это финал длинной цепочки решений, многие из которых принимались задолго до начала разработки. В этой статье я честно, от первого лица, разбираю, почему IT-проекты выбиваются из сроков, где здесь моя ответственность как исполнителя, а где — общая, и как именно я строю работу, чтобы дата сдачи не превращалась в пустое обещание.

Правда о сроках в IT-проектах

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

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

Ещё одна правда: срок и объём связаны жёстко. Нельзя добавить новых задач в середине и сохранить ту же дату сдачи без потери качества. Это не упрямство исполнителя, это арифметика. Сроки срываются не потому, что кто-то плохо считал, а потому что условия, по которым считали, изменились — и об этом изменении часто забывают.

Почему дедлайны срываются: реальные причины

Расскажу о причинах, которые встречаю чаще всего. Они скучные и предсказуемые — и именно поэтому их можно предупредить.

Расплывчатое техническое задание. Самая частая причина. Когда задача описана общими словами — «сделать удобный личный кабинет», «настроить интеграцию», «чтобы всё работало быстро» — каждый участник представляет своё. Заказчик держит в голове один образ, я строю по другому, и расхождение всплывает только на демонстрации. Переделка съедает время, которого в плане не было. Размытое ТЗ — это не экономия на старте, это отложенный долг по срокам.

Правки на ходу. Проект живёт, появляются новые мысли — это нормально. Ненормально, когда правки вносятся бесконечно и без пересмотра срока. Каждая «мелочь» по отдельности кажется незначительной, но десять таких мелочей превращаются в новую неделю работы. Если объём растёт, а дата сдачи остаётся прежней, срыв заложен математически.

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

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

Интеграции с чужими системами. Когда проект завязан на внешний сервис — платёжку, мессенджер, CRM, API партнёра — часть управления уходит из моих рук. Чужой сервис может менять правила, тормозить, выдавать недокументированное поведение, уходить на технические работы. Я не управляю их сроками и их стабильностью, но именно я объясняю заказчику задержку. Это самая нервная категория рисков.

Форс-мажоры. Болезни, аварии хостинга, внезапные изменения у поставщиков, проблемы со связью. Их нельзя исключить, но можно заложить разумный запас, чтобы один сбой не обрушивал весь план.

Чья это вина — и почему не только подрядчика

Привычная картина: сорвался срок — виноват исполнитель. Иногда так и есть, и я первым это признаю: бывает, что недооценил задачу, взял слишком много параллельно или плохо проговорил условия. За это отвечаю я, и здесь нет смысла прятаться за обстоятельствами.

Но честный разбор почти всегда показывает, что причина обоюдная. IT-проект — это не услуга, которую заказывают и забирают готовой, как пиццу. Это совместная работа, где заказчик — полноценный участник. Его скорость ответов, готовность материалов, дисциплина по объёму напрямую влияют на дату сдачи не меньше, чем моя продуктивность.

Простой пример. Я заложил три дня на этап, который зависит от текстов заказчика. Тексты приходят через неделю. Эти потерянные дни уже не вернуть: пока я ждал, я переключился на другую работу и не могу мгновенно вернуться в контекст. Формально дедлайн сорван — но решение, которое его сорвало, принимал не я.

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

Как я работаю со сроками честно

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

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

Буфер времени. Я закладываю разумный запас на непредвиденное. Не потому что не уверен в себе, а потому что форс-мажоры случаются всегда — вопрос только в том, какие именно. План без буфера — это план, который держится, только если всё идеально. Идеально не бывает почти никогда.

Работа этапами. Я веду проект так, чтобы результат был виден частями, а не одним большим финалом «когда-нибудь». Каждый этап — это рабочий, проверяемый кусок. Это снижает риск накопленного непонимания: если мы разошлись в видении, это всплывёт на первом этапе, а не на сдаче всего проекта.

Честная оценка диапазоном. Я называю не одну цифру, а коридор — с понятными условиями, от чего зависит ближняя и дальняя граница. Это честнее и спокойнее для обеих сторон: заказчик видит реальную картину, а не приятную сказку, которая развалится через неделю.

Фиксация объёма. Мы заранее договариваемся, что входит в работу, а что — нет. Это не бюрократия и не способ отказывать в правках. Это защита срока и заказчика тоже: когда объём зафиксирован, новые идеи не растворяются незаметно в плане, а обсуждаются открыто — со сдвигом срока или без, но осознанно.

Регулярная связь. Я держу заказчика в курсе: что сделано, что дальше, где есть риск задержки. Плохая новость, сказанная вовремя, почти всегда решаема. Та же новость, всплывшая в день сдачи, — уже катастрофа. Большинство конфликтов по срокам — это не конфликты из-за самих сроков, а из-за молчания.

Этот же подход я переношу и на задачи, где нужно навести порядок в процессах и убрать ручную рутину — там предсказуемость сроков особенно важна, и об этом я пишу в услуге автоматизация бизнеса. А если вы хотите сразу посмотреть, с какими форматами сотрудничества можно начать, загляните в мои предложения.

Частые вопросы

Почему нельзя назвать точный срок сразу? Потому что в начале проекта известно меньше всего деталей. Точная цифра по паре предложений — это либо риск вашими ожиданиями, либо огромный скрытый запас в цене. Честнее назвать диапазон и сузить его после уточнения задачи.

Если срок сорвался по вине внешнего сервиса — что делать? Я не управляю чужими системами, но управляю реакцией: предупреждаю заранее, ищу обходные пути, при необходимости пересматриваем план вместе. Именно поэтому в проекты с интеграциями я закладываю буфер.

Я вношу правки по ходу — это нормально? Да, проекты живут и меняются. Главное — обсуждать, как правки влияют на срок. Если объём растёт, честно сдвигаем дату или выносим часть в следующий этап. Незаметно работа не растворяется.

Что от меня зависит как от заказчика? Скорость ответов, готовность материалов и доступов, дисциплина по объёму. Это влияет на срок не меньше моей работы. Я заранее даю понятный список того, что нужно и к какому моменту, чтобы вам было легко.

Зачем дробить проект на этапы, если можно сделать всё сразу? Этапы вскрывают расхождения в видении рано, когда исправить дёшево. Сдача одним большим финалом — это максимальный риск: если мы разошлись в понимании, узнаете об этом в самом конце.

Коротко о главном

Срыв дедлайна почти никогда не бывает случайностью или ленью — это следствие неопределённости и решений, принятых задолго до видимого опоздания. Размытое задание, бесконечные правки, задержка материалов, недооценка сложности и капризы чужих систем работают предсказуемо, а значит, поддаются управлению. Я отношусь к проекту как к совместной работе, где у меня и у заказчика есть свои зоны ответственности, и где честная оценка диапазоном, буфер, этапы, фиксация объёма и регулярная связь делают дату сдачи настоящей, а не вежливой выдумкой. Это не гарантия, что всё пройдёт идеально, — это способ сделать так, чтобы один сбой не превращался в провал всего проекта.