Правки после запуска: как не растянуть проект на месяцы
Правки после запуска. Без правил и бэклога правки тянутся месяцами; отделите баги от новых фич и новых денег.
Запустили - и пошло «а давайте ещё»
Нормально хотеть улучшать сайт после запуска. Ненормально, когда каждая идея идёт в бесплатную очередь «допилите», а подрядчик молчит или делает бесконечно. Я после запуска перевожу проект в режим: баги чиним быстро, идеи - в бэклог с оценкой.
Заказчик и подрядчик должны заранее знать, что входило в смету, сколько раундов правок было до запуска, и как оплачивается поддержка после.
Три корзины задач
- Баг. Форма не шлёт, 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.
- Не назначить одного человека, кто утверждает правки.
- Ожидать бесплатных правок без лимита после приёмки.
- Месяц полировать текст, не включив рекламу и Метрику.
Другие материалы
- Сколько правок нормально - до запуска
- Сопровождение сайта - после сдачи
- После запуска - первые шаги
- Услуги - поддержка
Хотите обсудить похожую задачу? После запуска правки собираем списком - так быстрее для обеих сторон.
Обсудить проект →