Правки после запуска: как не растянуть проект на месяцы

Правки после запуска. Без правил и бэклога правки тянутся месяцами; отделите баги от новых фич и новых денег.

Запустили - и пошло «а давайте ещё»

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

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

Три корзины задач

  • Баг. Форма не шлёт, ssl слетел, сайт упал на iPhone. Чинить сразу.
  • Мелкая правка. Опечатка, фото, текст в рамках согласованного блока. По договору или пакету.
  • Новая фича. Новая страница, фильтр, интеграция. Отдельная смета.

Почему правки растягиваются

Нет одного decision maker: три человека шлют противоречивые правки. Нет приоритета: всё «срочно». Нет фиксации: правки голосом в WhatsApp. Подрядчик ждёт оплату за этап 2, заказчик ждёт «мелочь» бесплатно. Каждый пункт добавляет недели.

ПричинаЛекарство
Размытые границы сметыТЗ + «не входит» списком
10 мелких сообщений в деньОдин список раз в неделю
Новый функционал «как правка»Оценка часов до старта

До запуска - сколько правок нормально. В договоре - ТЗ.

Бэклог после запуска

Я завожу таблицу: задача, тип (баг/правка/фича), приоритет, оценка, статус. Заказчик видит, что в работе, что в очереди. Одна колонка «хотелки без срока» - туда складываем идеи с созвонов, не смешивая с багами.

Пример строки бэклога:
| Заменить фото в hero | правка | P2 | 0.5ч | ждёт контент от клиента |
| Страница /promo | фича | P3 | 8ч | оценка отправлена |

SLA на баги

После запуска я обычно даю: критичный баг (сайт down, форма) - ответ в течение рабочего дня, фикс 1-2 дня. Некритичное - в ближайший слот поддержки. Без SLA заказчик пишет «СРОЧНО» на замену запятой, подрядчик выгорает.

Сайт работал, форма сломалась после правки текста в админке клиентом. Баг, не «вы плохо сделали изначально».

Пакет часов vs абонемент

Абонемент сопровождения: N часов в месяц на мелочи. Разовые задачи сверх - по ставке. Так правки не висят «потому что некогда». Про состав абонемента - что входит в сопровождение.

Контентные правки своими силами

Если сайт на CMS или Tilda, тексты и фото заказчик меняет сам. Меньше пинг-понга. Если на статике без админки - каждая правка к разработчику, закладывайте пакет или учитесь минимальному редактированию.

Как писать список правок

  • Один документ или тикет, не 15 сообщений.
  • Ссылка на страницу + «было / стало».
  • Скрин, если про визуал.
  • Приоритет: блокер / можно на неделе / когда-нибудь.

Когда остановить правки и смотреть цифры

После запуска две недели крутите трафик, смотрите Метрику, потом правите по данным. Бесконечный полировщик hero без заявок - прокрастинация. Лендинг не продаёт, цели в Метрике.

Конфликт «это было в ТЗ»

Достаёте версию ТЗ, смотрите пункт. Нет пункта - новая задача. Эмоции отдельно, факты отдельно. Я сохраняю переписку с датами в одном треде проекта.

Релизы после запуска

Не править прод в пятницу вечером пять раз подряд. Собрали правки, выкатили staging, проверили, один deploy. Меньше поломок, меньше «а теперь сломалось другое».

В конце

Правки после запуска неизбежны. Хаос - нет. Бэклог, типы задач, SLA на баги, оплата фич отдельно. Так проект заканчивается, а не растворяется в вечном «ещё чуть-чуть».

Freeze и окна изменений

На некоторых проектах договариваемся: «freeze на prod за 48 часов до рекламной кампании». Только баги, не эксперименты. Заказчик знает: если хотел поменять hero, делал до freeze.

После крупной акции - retrospective: что в бэклог, что выкинуть. Идеи копятся, не все достойны dev-часов.

Оценка в часах

«Заменить фото» - 0.25 ч. «Переставить блоки местами» - 1-2 ч. «Добавить фильтр» - 8+ ч. Подрядчик называет оценку до старта, заказчик решает, сейчас или в следующем месяце. Прозрачность снимает «почему мелочь неделю».

Я отправляю короткое сообщение после каждого деплоя: «выложено: правка footer, задача #12». История в Telegram спасает при «мы же просили в прошлый вторник».

Когда пора остановить правки и масштабировать трафик

Если форма работает, ssl ок, оффер понятен, а правки косметические больше месяца - включайте рекламу или SEO. Данные покажут, что менять. Без трафика полировка бесконечна.

Шаблон тикета на правку

Страница: /prices
Было: кнопка «Узнать цену»
Стало: «Получить смету»
Тип: косметика / контент / новая функция
Срок: по SLA договора

Без «сделайте красивее» в одном сообщении и десяти правок в голосовых. Я обычно прошу одним списком раз в неделю, не потоком в Telegram.

Когда правка бесплатна, когда нет

В смете: 2 раунда по согласованному макету. Замена фото в готовом блоке - часто косметика. Новый блок «как у конкурента» - новая задача. Фиксируйте в договоре, не «на глаз».

Retainer vs оплата по факту

Retainer: N часов в месяц на мелочи, остальное по оценке. Без retainer каждая «замени фото» - переговоры заново. Я предлагаю пакет 2-4 часа для клиентов после запуска.

Новая страница, новый язык, интеграция - всегда отдельная смета. Правка typo в footer - в рамках retainer, если есть.

Коммуникация

Один канал: Telegram-тред или email-тикet. Не правки в WhatsApp + звонок + «ну вы же поняли». Про границы - сколько правок входит в цену.

Приоритеты в бэклоге

P0: сайт лежит, форма мертва. P1: ошибка на мобиле. P2: текст кнопки. Заказчик может ставить P2 каждый день - я показываю очередь и SLA. Прозрачность снимает «вы нас игнорируете».

С чего начать

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

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

После созвона - в документ

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

Hosting, ssl, домен, форма, Метрика - базовая инфраструктура любого сайта, даже если статья про другую тему. См. hosting и ssl и доступы. Покупка сайта целиком - порядок шагов.

На практике я советую не откладывать проверку «на потом»: один вечер на чеклист дешевле недели переделок после запуска рекламы. Запишите дату проверки и ответственного в том же файле, где храните доступы к сайту.

Как действовать заказчику

  • Разделите задачи на баг, правку и новую фичу.
  • Ведите бэkлог в одном месте, не в личке.
  • Согласуйте пакет поддержки или ставку за час до запуска.
  • Отправляйте правки списком раз в неделю, если не баг.
  • Два weeks после запуска смотрите аналитику, потом меняйте оффер.
  • Храните финальное ТЗ и переписку о границах сметы.

Если нужен код, а не совет

Разработчик выстраивает процесс деплоя, staging и оценки задач после запуска; без процесса даже мелкие правки ломают prod и отношения. Ориентиры по срокам и бюджету - на странице цен, услуги - в разделе услуг.

Где чаще всего ошибаются

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

Другие материалы

Хотите обсудить похожую задачу? После запуска правки собираем списком - так быстрее для обеих сторон.

Обсудить проект →