Содержание
Доработка сайта — это изменение того, что уже работает и приносит заявки. Поэтому главное требование к ней — ничего не сломать по дороге. Отсюда наш порядок: сначала понять задачу и код, потом оценить, потом делать на копии. Так мы работаем и с проектами на популярных CMS, и с самописными, в том числе сделанными другими студиями.
ТЗ на доработку: что написать
Хорошее ТЗ не обязано быть длинным. Оно отвечает на пять вопросов: что должно получиться, кто будет этим пользоваться, как это выглядит сейчас, как понять, что задача сделана, и что трогать нельзя. Последний пункт часто забывают, а именно он спасает от сюрпризов вроде «переделали форму, а заявки перестали уходить в CRM».
Полезно приложить примеры: скриншоты, ссылки на ресурсы, где нужная функция уже работает, текущие письма или выгрузки, если задача связана с данными. Если хочется поменять несколько вещей сразу, разбейте их на отдельные пункты — так их проще оценить и принимать по очереди.
Пример короткой постановки: «В карточке товара добавить калькулятор стоимости доставки по весу и региону. Тарифы — в приложенной таблице. Результат показывать до оформления заказа. Корзину и оплату не менять». Этого достаточно для первой оценки.
К описанию полезно добавить три вещи: разрешение сделать тестовую копию, контакты прежнего разработчика, если он на связи, и список модулей и интеграций, если он у вас есть. Это сокращает время на просмотр кода, а значит, и срок оценки.
Почему оценка — после просмотра кода
Одна и та же задача на разных проектах стоит по-разному. Добавить поле в форму на аккуратно написанном ресурсе — полчаса. На проекте, где форма собрана тремя плагинами и половина логики лежит в шаблоне, — полдня, потому что сначала нужно разобраться, что за что отвечает.
Поэтому до просмотра кода мы называем только вилку. После — точную оценку и риски: что может сломаться, что стоит поправить заодно, а что трогать не нужно. На это уходит от одного до трёх дней, и в итоге вы платите за работу, а не за наши догадки.
Доработка или новый сайт: как решить
Иногда проще сделать заново, чем латать старое. Признаки такие: платформа больше не обновляется, каждый новый модуль ломает два старых, мобильная версия требует переделки всех шаблонов, а по коду видно, что его писали разные люди без общего подхода.
Но переделка — это новые расходы и риск потерять позиции в поиске при переезде. Поэтому решение принимаем после просмотра кода и с цифрами: сколько стоит доработать нужное сейчас, сколько — поддерживать дальше и сколько — сделать новый проект. Если доработка нужного обходится дороже половины нового проекта, второй вариант пора считать всерьёз.
Промежуточный путь — постепенная замена. Новый раздел делаем уже на современной основе, старые переносим по мере сил. Так бизнес не останавливается, а проект обновляется частями.
Если всё-таки решили переезжать, заранее составьте таблицу старых и новых адресов. Для каждой страницы, которая приносит посетителей из поиска, нужен постоянный редирект на новую, а тексты и заголовки лучше переносить без лишних изменений — улучшать их удобнее уже после переезда.
Если у вас интернет-магазин
В магазине любая правка касается денег. Прежде чем менять корзину, оплату или обмен с 1С, договариваемся о тестовых заказах: сколько их провести, какими способами оплаты и доставки, кто проверит, что заказ дошёл до склада.
Переносить изменения лучше в часы наименьшей нагрузки и не накануне выходных, когда исправлять ошибку некому. А перед переносом у нас всегда есть свежая копия и понятный способ быстро вернуть всё как было.
Как оформить доработку в документах
Для небольших задач хватает договора с почасовой ставкой и акта по итогам месяца. Для проекта — договора со сметой, этапами и порядком приёмки. В акте перечисляем, что именно сделано: какие функции добавлены или изменены. По такому акту бухгалтеру проще решить, как учитывать расходы, а вам — через год вспомнить, за что платили.
В договоре стоит записать и срок, в течение которого исполнитель без доплаты исправляет ошибки в своей работе. Ошибки, которые проявились позже или возникли из-за чужих правок, оцениваются как новая задача — это справедливо для обеих сторон, если правило известно заранее.
Отдельно договариваемся о правах на код. Всё, что мы написали для вашего проекта, передаём вам — код лежит в вашем репозитории, а не у нас. Встречаться для доработки не нужно: смету, показ на тестовом адресе и приёмку проводим онлайн. Так устроена доработка сайта в Уфе.
