Почему техническая поддержка проекта за год может выйти дороже, чем разработка сайта и что с этим делать бизнесу?

Достаточно частый кейс, когда бизнес начинает разработку сайта с одним подрядчиком, а завершает уже с другим. Это может происходить по разным причинам:

• Низкое качество менеджмента в агентстве
• Нехватка ресурсов или кризис в организации подрядчика
• Слабая вовлеченность ответственного специалиста заказчика в проект и т.п.

Любая из причин способна катастрофически растянуть сроки и нервы руководства и/или владельца бизнеса не выдерживают. Далее, как правило, в спешке находится другой подрядчик. И, если повезет, то новая команда даже за более скромный бюджет (опять же - если простаивает производство, или остро нужны свежие работы в портфолио) доделывает всю грязную работу.

Итак, проект запущен! Даже пройдены первые тесты и, кажется, все хорошо. Трафик идет, лиды начинают просачиваться в воронки CRM. Как правило неделю-две Заказчик с новым подрядчиком пьют шампанское и правят мелкие баги.

Далее начинаются следующее:

• доработки разделов, которые скрывали в момент запуска (лишь бы запуститься)
• настройка отчетов электронной торговли и вообще целями конверсий сайт забыли обвесить
• выясняются неудобные моменты для работы с контентом (например для того, чтобы изменить главный слайд нужно его специальным образом заверстать и т.д.)

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

Что же делать Заказчику в этой ситуации? Как работать максимально качественно с оптимальным соотношением времени/денег на этапе поддержки сайта?

1. Составить план по доработкам на ближайшие 6-12 месяцев и сгруппировать их по логическим блокам вместе с подрядчиком
2. Договориться о деталях:
   • каким образом и какие именно элементы будут подключаться к админке (можно, например, оставить в шаблоне дизайна те элементы, которые точно не будут часто изменяться)
   • четко формировать желаемый результат по каждой задаче (в идеале приводить референсы), чтобы сократить кол-во правок
   • разделить работы по дизайну/верстке/программированию и делать каждый блок работ в исходниках проекта. дизайн принимать в фигме, верстку отсматривать отдельно от программной части и только после согласования визуала (design+frontend) переносить в программную часть на тестовое окружение, а затем уже в production.
3. Оценить +/- время, необходимое на работу по каждому блоку и зарезервировать ресурсы команды Исполнителя (большинство агентств предоставляют скидку при предоплате X+ часов поддержки)
4. Взять в штат web-мастера (специалист, который немного умеет html/css, сфотографировать и обработать изображения, оптимизировать их и загрузить в CMS) и всю работу по контенту перевести на него, завязав его с подрядчиком для получения недостающей экспертизы в виде консультаций
5. Больше вовлекаться в детали своего проекта, интересоваться как он устроен, как работают функциональные блоки, где хранятся данные, каким образом происходит резервное копирование и т.п.

Проактивность менеджера на стороне Заказчика позволяет предупреждать большое количество инцидентов, а также существенно упростит и сделает работу подрядчика более приятной.