Сроки в заказной разработке — интересная субстанция. Они вроде бы есть, но редко соблюдаются. Давайте разберем, почему так происходит и с какими переменными мы сталкиваемся.

🗂 Согласования. Требуют гораздо больше времени, чем кажется. Когда вам называют сроки до старта работ, в них обычно не заложено время на обратную связь. Представьте дизайн типового ecom-проект с 100+ экранами: предварительное согласование, затем правки, потом утверждение всего пула, а еще адаптив под минимум 4 разрешения. И ведь нужно не просто посмотреть, но и вникнуть, дать конкретные замечания. Сколько на это заложить времени?

👥 Команда. Еще один критический фактор. Люди болеют, уходят в отпуск. Конечно, эти риски лежат на подрядчике, и если его менеджмент умеет виртуозно жонглировать ресурсами, то сроки едут не сильно или вовсе не едут. Тут многое зависит от проектного менеджера — сильный PM вывезет проект с любой командой.

Распространенное заблуждение: если добавить программистов, проект пойдет быстрее. На практике новому специалисту нужно вникнуть в код, понять структуру, адаптироваться. Если был один разработчик с производительностью 1, то с двумя в лучшем случае получим 1.75, а не 2.

🔗 Интеграции. Сегодня есть почти в каждом проекте — 1С, ERP, Microsoft Dynamics или какая-нибудь шина данных. И даже при максимально качественном предпроектном обследовании что-то может пойти не так. Данные в каталоге могут оказаться заполненными наполовину или быть в неожиданном формате.

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

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

🤔 Недооценка сложности задач. Это классическая проблема — разработчики склонны оптимистично оценивать задачи, не учитывая «закон Хофштадтера»: все занимает больше времени, чем кажется, даже с учётом закона Хофштадтера.

🌐 Внешние зависимости. Иногда проект зависит от сторонних сервисов, API или поставщиков, которые могут изменить условия, задержать обновления или предоставить неожиданные ограничения.

✅ Нечёткое определение готовности. Без чётких критериев приёмки или «definition of done» команды могут бесконечно полировать функциональность или, наоборот, считать задачу завершённой раньше времени.

🧠 Переключение контекста. Если разработчики вынуждены работать над несколькими проектами одновременно, эффективность падает из-за постоянного переключения и необходимости заново погружаться в контекст.

Минимизируем риски

— 📋 Четкое определение требований. Зафиксировать требования на раннем этапе и детально согласовать их. Четкие и фиксированные требования позволяют избежать частых изменений и недопонимания.

— 🌀 Гибкое управление проектом. Это позволяет оперативно реагировать на изменения, отслеживать прогресс и пересматривать задачи по мере их выполнения. Разделить проект на маленькие итерации (спринты) с четкими результатами по каждой, что позволяет отслеживать и контролировать риски в реальном времени.

— 🧑‍⚕️ Резервирование ресурсов. Создание резервных ресурсов и планов на случай отсутствия ключевых сотрудников (по болезни, отпуску).

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

— 🧩 Планирование рисков. Идентификация потенциальных рисков на старте проекта и подготовка стратегий для их минимизации.

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