За пять лет работы студии мы собрали внушительный список ошибок, которые повторяются проект за проектом. Не «глобальные катастрофы», а будничные грабли, делающие сроки длиннее, а бюджет шире. Перечислим самые частые с рабочими антидотами.
1. Запуск без ТЗ
«Давайте сначала начнём, по ходу разберёмся» — самый дорогой путь. На дистанции приводит к 30–50% переделок и срыву сроков на 2–4 недели.
Минимальный документ перед стартом: цели проекта, ключевые сценарии пользователя, список страниц, интеграции, требования к производительности и SEO, бюджет и сроки. 5–10 страниц текста стоят 8–16 часов работы менеджера и снимают большинство будущих споров.
2. Слишком амбициозный MVP
Команда хочет «всё и сразу»: сайт + личный кабинет + мобильное приложение + интеграция с пятью сервисами. Запускается через 6 месяцев вместо 2, и большую часть функций никто не использует.
Антидот: жёсткая приоритизация по MoSCoW (Must / Should / Could / Won't). MVP — только Must, остальное — следующие итерации. На запуске собираем фидбек, по нему планируем next.
3. Дизайн без учёта реалий контента
Дизайнер рисует красивые карточки с заголовками в одну строку и описаниями в три. На реальных данных заголовок в пять строк, описание в две. Вёрстка ломается, нужна переделка.
Дизайн делайте с реальным или близким контентом, не lorem ipsum. Тестируйте крайние случаи: пустые состояния, длинные тексты, отсутствие картинки. Это спасает 10–20% времени фронтенда.
4. Без работы с производительностью
«Оптимизацию сделаем в конце». В конце — большой набор накопившихся проблем: тяжёлые картинки, неоптимизированный JS, отсутствие ленивой загрузки. Lighthouse 30–40 на мобильном.
Мерять CWV нужно с первой версии. Бюджет производительности (LCP менее 2.5с, CLS менее 0.1) — часть DoD каждой страницы. Регрессии ловятся в CI.
5. SEO «потом, после релиза»
«Сначала запустимся, потом оптимизируем». На практике после запуска становится не до SEO. Через полгода замечают, что трафик из поиска нулевой, и заказывают SEO-аудит — с переделкой 30–40% страниц.
SEO-обвязка — часть архитектуры, не дополнение. Семантика, sitemap, JSON-LD, hreflang, мета-теги — закладываются на этапе вёрстки, не «когда уж до этого дойдут руки».
6. Аналитика на post-релизе
Релиз случился, маркетолог гонит трафик, но Yandex Metrika и GA4 не настроены. Цели не работают, события не отслеживаются. Через месяц непонятно, что давало конверсии.
Минимальная аналитика — обязательное требование к релизу. Цели расставлены, события размечены, дашборд с ключевыми метриками собран. Без этого продукт «летит вслепую».
7. Без бэкапов и мониторинга
Сайт работает, никто не настроил бэкап БД. Через месяц диск отказывает, неделя продаж теряется. Это не теория — мы видели такое у клиентов трижды.
Минимум: ежедневный бэкап БД и файлов в Object Storage (Yandex Cloud, S3) с retention 30 дней, ежемесячный — 6 месяцев. Мониторинг через Yandex Cloud Monitoring или UptimeRobot, оповещение в Telegram при падении.
8. Деплой через FTP вручную
«Зашёл, скопировал файлы, перезагрузил». Работает, пока проектом занимается один человек и спит он крепко. Когда команда — три человека и каждый деплоит по-своему, бардак гарантирован.
CI/CD на GitHub Actions с автоматическим деплоем — стандарт даже для маленьких проектов. Сборка, тесты, деплой по push в main или по тегу. Прозрачная история, откат за минуты.
9. Без юр.документов
Запуск без оферты, политики обработки ПДн, согласия пользователя на cookies. Через месяц приходит претензия от Роскомнадзора — штраф или предписание.
Шаблоны юр.документов готовятся на этапе финальной сборки, не «после релиза». Заявка с галочкой «согласие на обработку», политика по ссылке, оферта — обязательный минимум.
10. Сдача проекта без передачи
Студия закончила работу, отдала ссылку на хостинг, исчезла. Через два месяца клиенту нужно поправить заголовок на главной — никто не знает, как.
Передача — отдельный этап: документация админки, обучающее видео для контент-менеджера, FAQ по типовым задачам, контакты для технической поддержки. На пару дней работы, спасает отношения с клиентом.
11. Без плана поддержки
«Запустили — забыли». Через 3 месяца Next.js обновился, плагины устарели, появилась уязвимость в зависимостях. Сайт работает, но накапливает технический долг.
План поддержки: ежемесячное обновление зависимостей, квартальные security-аудиты, мониторинг алертов от Renovate или Dependabot. 4–8 часов в месяц — минимальный пакет, окупается на первой же критической CVE.
12. Незакрытое staging-окружение
Тестовое окружение с реальными данными, открытое в публичном интернете. Пароли в .env доступны в репозитории. Это банально, и это происходит еженедельно где-то в мире.
Staging — за basic auth или VPN, реальные данные обезличены, секреты — в Secrets Manager или Vault, не в файле. Делается за пол дня.
Итого
Большинство ошибок веб-проектов — не технические, а процессные: запуск без ТЗ, амбициозный MVP, отложенный SEO, отсутствие аналитики, ручной деплой, забытая поддержка. Антидот — дисциплина: чек-лист готовности к релизу, минимальные требования по перформансу/SEO/аналитике, автоматизация деплоя и мониторинга. Это окупается на первом же проекте, экономит десятки часов на втором.
Частые вопросы
Почему нельзя запускать веб-проект без ТЗ?
«Давайте сначала начнём, по ходу разберёмся» — самый дорогой путь. На дистанции приводит к 30–50% переделок и срыву сроков на 2–4 недели. Минимальный документ перед стартом: цели проекта, ключевые сценарии пользователя, список страниц, интеграции, требования к производительности и SEO, бюджет и сроки. 5–10 страниц текста стоят 8–16 часов работы менеджера и снимают большинство будущих споров. Без ТЗ команда строит «то, что показалось», а не что нужно бизнесу.
Как избежать слишком амбициозного MVP?
Команда хочет «всё и сразу»: сайт + личный кабинет + мобильное приложение + интеграция с пятью сервисами. Запускается через 6 месяцев вместо 2, и большую часть функций никто не использует. Антидот: жёсткая приоритизация по MoSCoW (Must / Should / Could / Won't). MVP — только Must, остальное — следующие итерации. На запуске собираем фидбек, по нему планируем next. Это позволяет получить рабочий продукт быстро и развивать на основе реальных данных, а не догадок.
Когда работать с производительностью в проекте?
«Оптимизацию сделаем в конце». В конце — большой набор накопившихся проблем: тяжёлые картинки, неоптимизированный JS, отсутствие ленивой загрузки. Lighthouse 30–40 на мобильном. Мерять CWV нужно с первой версии. Бюджет производительности (LCP менее 2.5с, CLS менее 0.1) — часть DoD каждой страницы. Регрессии ловятся в CI. То же с SEO: семантика, sitemap, JSON-LD закладываются на этапе вёрстки, не «когда дойдут руки», иначе через полгода трафик из поиска нулевой.
Зачем настраивать аналитику до релиза?
Релиз случился, маркетолог гонит трафик, но Yandex Metrika и GA4 не настроены. Цели не работают, события не отслеживаются. Через месяц непонятно, что давало конверсии. Минимальная аналитика — обязательное требование к релизу. Цели расставлены, события размечены, дашборд с ключевыми метриками собран. Без этого продукт «летит вслепую». То же с бэкапами: сайт работает, никто не настроил бэкап БД, через месяц диск отказывает, неделя продаж теряется.
Какие риски ручного деплоя через FTP?
«Зашёл, скопировал файлы, перезагрузил». Работает, пока проектом занимается один человек и спит он крепко. Когда команда — три человека и каждый деплоит по-своему, бардак гарантирован. CI/CD на GitHub Actions с автоматическим деплоем — стандарт даже для маленьких проектов. Сборка, тесты, деплой по push в main или по тегу. Прозрачная история, откат за минуты. Также критично закрыть staging-окружение от публичного интернета — реальные данные, открытые наружу — еженедельный инцидент в мире.
Почему нельзя сдавать проект «и забыть»?
Студия закончила работу, отдала ссылку на хостинг, исчезла. Через два месяца клиенту нужно поправить заголовок на главной — никто не знает, как. Передача — отдельный этап: документация админки, обучающее видео для контент-менеджера, FAQ по типовым задачам, контакты для технической поддержки. На пару дней работы, спасает отношения с клиентом. План поддержки: ежемесячное обновление зависимостей, квартальные security-аудиты, мониторинг алертов от Renovate. 4–8 часов в месяц минимум.