Техподдержку обычно воспринимают как страховку. Что-то сломалось — починили. Упал сайт — подняли. Пока всё работает, про студию не вспоминают.

Мы относимся к этому иначе. Один наш клиент-девелопер пришёл с готовым сайтом, который вела другая команда. С тех пор прошло шесть лет, через нас прошло больше 560 задач, и за это время сайт ни разу не переделывали с нуля. Он просто рос.

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

Чем «вести продукт» отличается от «чинить сайт»

Разовый проект заканчивается сдачей. Подрядчик выкатил сайт, закрыл акт, ушёл. Дальше начинается типичная история: мелкие правки делает кто попало, каждый трогает чужой код наугад, и через год продукт превращается в лоскутное одеяло, которое страшно открывать.

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

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

Первый подход быстрее на сегодня. Второй дешевле на дистанции.

И ещё одно отличие, которое редко проговаривают. Подрядчик, который сдал и ушёл, не несёт ответственности за последствия своих решений — он их просто не увидит. Команда, которая остаётся на годы, живёт с каждым своим решением. Это лучшая мотивация делать аккуратно: костыль, который ты воткнул в прошлом квартале, вернётся к тебе же новой задачей через полгода.

Мы умеем заходить в чужой проект

Большинство студий любят делать с нуля. Чужой код — это чужие решения, чужая логика и риск, что под капотом окажется минное поле. Поэтому подрядчики часто отвечают на запрос о поддержке одинаково: «давайте лучше всё перепишем».

Мы умеем заходить именно в существующие проекты. У нас десятки случаев, когда сайт к нам приходил после других разработчиков — тех, кто его делал и вёл годами. И почти всегда повторяется одно и то же: внятной документации нет. Есть код, есть прод, есть пара контактов «спросите вот у него» — и всё.

Один из показательных примеров. Мы приняли на поддержку крупный и сложный сайт ещё одного застройщика. Команда, которая его передавала, была сильной и специализировалась именно на таких проектах. Заказчик отдельно заплатил за подготовку документации к передаче. На выходе он получил половину листа А4, где полезного было ровно ноль.

Это не редкость, это норма рынка. Документацию либо не ведут, либо она устаревает через месяц, либо её пишут для галочки. Поэтому ценность подрядчика измеряется не тем, как красиво ему всё передали, а тем, как быстро он разберётся, когда не передали ничего.

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

Для бизнеса это означает одно: смена подрядчика перестаёт быть катастрофой. Не нужно выбрасывать сайт и платить за новый только потому, что прежняя команда ушла и «никто больше в этом не разберётся». Разберёмся.

560+ задач — это не про объём, а про доверие

Шесть лет и больше 560 задач звучат как статистика. Но за этой цифрой стоит другое: заказчик столько раз возвращался с новой задачей, потому что предыдущие были сделаны хорошо.

Доверие тут накапливается не на словах, а на потоке. Задачи идут через канбан и чаты, мы оцениваем их в часах, заказчик расставляет приоритеты под бюджет. Никаких «давайте соберём ТЗ на полгода» — есть поток работы, который видно и можно планировать. Если у заказчика появляется срочная задача, она просто двигает остальные, и причина сдвига сразу видна в плане. Это снимает половину конфликтов про сроки ещё до того, как они начинаются.

Диапазон задач — от обводки новой секции на генплане за пару часов до интеграций на сотни часов. Маленькие правки и большие куски функционала живут в одном процессе. Это удобно бизнесу: не нужно искать отдельного подрядчика под «что-то крупное» и отдельного под «по мелочи», а потом сводить их между собой.

Внутри этого потока перемешано всё. Заменить номер телефона на странице тендеров и поправить опечатку. Развернуть отдельную базу для аналитики и подключить её к коннектору. Сжать видео на главной, которое весило полгигабайта и роняло загрузку. Нарисовать таймер для новогодней акции к вечеру того же дня. Спроектировать онлайн-сделку на сотни часов. Для команды, которая ведёт продукт, это нормальный разброс — она умеет переключаться между «срочно и на час» и «вдумчиво и на месяц».

И ежемесячная отчётность. Заказчик всегда видит, на что ушли часы. Это скучная часть, но именно она держит отношения честными шесть лет подряд. Когда бизнес понимает, за что платит, у него не возникает ощущения, что студия «что-то там делает и присылает счёт».

Развитие без переделок

Самый дорогой сценарий для бизнеса — переделать сайт целиком. Это значит выбросить накопленную логику, заплатить заново и на несколько месяцев заморозить развитие. А ещё — заново объяснять новой команде то, что старая уже знала.

За шесть лет мы этого ни разу не сделали. Хотя сайт изменился до неузнаваемости.

Он начинался как обычный корпоративный сайт застройщика: главная, проекты, контакты, форма заявки. Сейчас это платформа, на которой каталог квартир завязан на 1С и обновляется сам, отдел продаж бронирует лоты, клиент оформляет ипотеку и подписывает договор электронной подписью без визита в офис. Между этими двумя состояниями — не переделка, а сотни последовательных шагов.

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

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

Отдельно стоит сказать про дизайн-систему. В какой-то момент сайт оброс страницами, которые собирались вручную, и стало непонятно, почему кнопка тут синяя, а там серая. Мы провели аудит всех страниц, нашли уникальные и дублирующиеся элементы, собрали UI-kit и пересобрали макеты под десктоп, планшет и мобильные. После этого каждая новая страница перестала быть отдельным изобретением — она собирается из готовых блоков. Это и есть развитие без переделок: чем дольше ведёшь продукт, тем быстрее в нём появляются новые вещи, а не медленнее.

Ответственное отношение: мы относимся к проекту как к своему

Вовлеченность — это когда исполнитель думает не только про текущую задачу, но и про продукт целиком. Не «сделать что просили», а «сделать так, чтобы продукту было хорошо».

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

Другой пример. Менеджеры вручную прятали проданные квартиры — каждый день, по списку. Никто не ставил задачу это автоматизировать, это считалось «просто работой». Мы предложили ночную сверку выгрузок из 1С: квартира пропала из фида — скрылась на сайте, вернулась — снова активна. Рутина исчезла, а вместе с ней и ошибки, когда забывали что-то скрыть.

Хороший подрядчик закрывает задачи. Вовлеченная команда подсказывает, какие задачи вообще стоит поставить. Часто самые ценные доработки рождаются не из ТЗ заказчика, а из фразы «слушайте, мы тут заметили, что…».

Сюда же — честность в оценках. Когда приходит крупная задача вроде шахматки с разными правами для агентов и менеджеров или онлайн-сделки с ЭЦП, мы не бросаемся писать код. Сначала оцениваем, иногда отговариваем от лишнего, предлагаем разбить на этапы. Бизнесу спокойнее, когда подрядчик готов сказать «это можно сделать дешевле» или «это пока не нужно», а не просто берёт деньги за всё подряд.

И последнее про вовлеченность, которое звучит парадоксально. Мы собрали дизайн-систему и написали инструкции, по которым менеджер заказчика сам заводит новый ЖК — от объекта до планировок. То есть сознательно снижаем зависимость клиента от нас. Но именно это и есть зрелое партнёрство: мы держимся на результате и доверии, а не на том, что без нас всё развалится. Заказчик, которого держат «в заложниках» через закрытый доступ и недокументированный код, рано или поздно уходит. Заказчик, которому дали свободу, остаётся, потому что ему удобно.

Одна команда вместо переписки между подрядчиками

Когда сайтом занимается то один фрилансер, то другой, бизнес незаметно превращается в интегратора. Заказчик сам сводит дизайнера с разработчиком, пересказывает одному, что имел в виду другой, и собирает осколки контекста в своей голове. На это уходит время людей, которые должны заниматься продажами и маркетингом, а не управлением подрядчиками.

За шесть лет у проекта сложилась постоянная команда: дизайн, фронтенд, бэкенд, девопс, поддержка контента и планировок. Внутри неё дизайнер понимает ограничения разработки, разработчик понимает бизнес-цель, а не просто закрывает тикет. Заказчику не нужно объяснять одно и то же трём людям — он ставит задачу один раз.

Это особенно важно в недвижимости, где у задачи часто несколько слоёв сразу. Условный «новый раздел ипотеки» — это и дизайн страниц, и вёрстка адаптива, и логика расчётов, и интеграция с банковскими сервисами, и заполнение контента. Если это растащено по разным исполнителям, проект встаёт на стыках. Когда всё внутри одной команды, стыков просто нет.

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

Почему это сильнее редизайна

Редизайн — это разовый всплеск. Красиво на старте, дальше снова деградация, если за продуктом некому следить. Через два года снова «сайт устарел, давайте обновлять».

Долгосрочное ведение — это сложный процент. Каждый месяц сайт становится чуть лучше: новая функция, закрытое узкое место, ускоренная страница, убранная рутина у отдела продаж. По отдельности это незаметно. За шесть лет складывается в продукт, который конкуренты пытаются догнать редизайнами, а он просто работает и приносит заявки.

Для собственника или директора по маркетингу аргумент простой. Когда подрядчик ведёт ваш сайт шесть лет и за это время ни разу не предложил «давайте всё перепишем», — это доказательство, что он умеет строить вдолгую. Студии, которые живут с проекта, наоборот заинтересованы в переделках: каждый редизайн — это новый большой чек. Мы зарабатываем на том, что продукт растёт ровно и не требует капитального ремонта.

Сайт, за которым следят как за продуктом, не устаревает скачками. Он развивается ровно, без болезненных рывков и заморозок. И для бизнеса это спокойствие стоит дороже любого нового дизайна — потому что сайт всё это время не «обновляется», а работает и продаёт.