Запрос, который начал тысячу споров
«Вы можете просто передвинуть эту кнопку вправо?»
«Вы можете просто изменить шрифт?»
«Вы можете просто добавить ещё одно поле в форму?»
Эти запросы кажутся простыми. Часто они таковыми не являются. И разрыв между ожиданиями клиента и реальностью разработчика — один из самых распространённых источников разочарования в любом веб-проекте.
Позвольте объяснить, что на самом деле происходит.
Проблема айсберга
То, что вы видите на веб-сайте, составляет, возможно, 10% от того, что существует. Остальное — это невидимая инфраструктура: настройки сервера, таблицы базы данных, код, обрабатывающий десятки пограничных случаев, плагины, взаимодействующие друг с другом, мобильные макеты, совместимость с браузерами, уровни безопасности.
Когда вы просите «просто изменить» что-то видимое, разработчику часто приходится пробираться через всю эту невидимую инфраструктуру, чтобы добраться туда — не сломав ничего.
Та кнопка, которую вы хотите переместить? Она может быть компонентом, который используется в 12 разных местах. Перемещение её в одном месте без влияния на другие требует найти все 12 случаев использования, протестировать каждый и убедиться, что мобильный макет всё ещё работает.
Что на самом деле происходит, когда разработчик получает «мелкое исправление»
Настройка среды (30–90 мин)
Профессиональный разработчик не вносит изменения напрямую на вашем живом сайте. Сначала он работает с локальной копией или промежуточной средой. Настройка этого — получение правильной базы данных, правильных плагинов, правильной конфигурации — занимает время.
Понимание существующего кода (переменная)
Если сайт создавал кто-то другой, новому разработчику придётся читать и понимать код, которого он никогда раньше не видел. Это всё равно, что получить чьё-то эссе с просьбой «просто добавить одно предложение» — сначала нужно прочитать всё, чтобы понять, куда это предложение вставить.
Внесение изменений (иногда быстро, иногда нет)
Собственно изменение может занять 10 минут. Или оно может выявить что-то неожиданное — конфликт с другим плагином, макет, который ломается на планшете, поле базы данных, которое также нужно обновить.
Тестирование (как минимум 30–60 мин)
После каждого изменения: тест на компьютере, тест на мобильном, тест в нескольких браузерах, тест, что изменение ничего не сломало рядом. Это занимает время, и его нельзя пропустить без риска сломать что-то хуже.
Развёртывание (15–30 мин)
Перенос изменений из тестовой среды на живой сайт, проверка, что всё перенесено правильно, проверка работы живого сайта.
Подытоживая: для «простого» изменения часто требуется 3–5 часов фактической работы, прежде чем оно безопасно попадёт на живой сайт. «Трёхдневный срок» обычно означает, что разработчик впишет это между другими задачами.
Когда это действительно всего 5 минут
Некоторые вещи действительно быстры. Изменение текстовой строки. Обновление цвета в CSS-переменной. Добавление электронной почты в список контактов.
Опытные разработчики часто могут это заметить и сказать: «Я могу сделать это сегодня». Но им нужно достаточно информации, чтобы принять такое решение — и им действительно нужно сначала посмотреть на код.
Как ускорить исправление
Будьте конкретны. «Исправьте кнопку» → «Кнопка "Добавить в корзину" на странице товара не работает на iPhone 12, iOS 16, Safari. Кнопка нажимается, но ничего не добавляется в корзину.»
Группируйте запросы. Вместо того чтобы отправлять 8 отдельных «мелких исправлений» в течение 8 дней, отправьте их все вместе. Настройка и развёртывание будут происходить один раз вместо восьми.
Не спешите с изменениями на продакшене. «Вы можете просто сделать это напрямую на живом сайте?» — это то, из-за чего сайты падают в 3 часа дня в пятницу. Хороший разработчик настаивает на тестировании. Это занимает время.
Определяйте приоритеты. Из ваших 8 запросов, какой на самом деле стоит вам денег, если не исправить его сегодня? Исправьте это сначала. Остальное может подождать.
Честно говоря: «Почему это занимает столько времени?»
Потому что «сделано» означает не «изменено». Это означает «изменено, протестировано, не сломано, развёрнуто и проверено на живом сайте».
Последняя миля — вот куда уходит время.
Если вы попробовали советы выше, но всё ещё не уверены, как эффективнее работать с исправлениями, или у вас нет времени делать это самостоятельно — мы в DevCev Digital можем взять это на себя. Напишите нам, и мы расскажем, как сделать процесс быстрее и безопаснее для вашего сайта.