← Все статьи

AI-конвейер на поддержке: как развивать работающий продукт, а не переписывать его

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

Разберём, как AI-конвейер ведёт себя на существующем продукте: что он ускоряет, где становится опаснее и какие правила делают быстрые правки безопасными.

Почему поддержка сложнее, чем кажется

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

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

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

Что конвейер реально ускоряет на поддержке

Выигрыш здесь другой, чем на новом проекте, и он больше связан с рутиной, чем с творчеством:

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

Где на поддержке нужно быть осторожнее

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

1. Данные. Любая правка, которая меняет или удаляет накопленное, делается с резервной копией и проверяется на копии, а не на боевой базе. Это правило не имеет исключений.
2. Деньги и документы. Расчёты, счета, договорные формулировки. Здесь машина может подготовить, но подтверждает человек.
3. Общие места. Правка в том, что используется везде, требует отдельной проверки соседних экранов — именно здесь рождается регресс.

Как ловят регресс

Регресс — это когда починили одно, а сломалось соседнее. На поддержке он опаснее всего, потому что ломается то, чего никто не трогал и потому не проверял.

Рабочая связка из трёх проверок:

• Обход основных экранов после каждой значимой правки: открыть по очереди все ключевые разделы и посчитать ошибки. Занимает секунды, ловит непропорционально много.
• Сверка возможностей. Список того, что система умеет, до и после изменения. Если из списка что-то пропало непреднамеренно, выкладка отменяется.
• Проверка глазами на телефоне. Не вместо предыдущих, а вместе с ними.

Заказчику эти проверки не нужно уметь делать самому — нужно знать, что они есть, и требовать подтверждения. Хороший подрядчик прикладывает к работе не отчёт, а доказательство.

Как выстроить поток мелких доработок

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

1. Одно место для задач. Не мессенджер, не почта, не звонки. В переписке задачи теряются, а договорённости невозможно восстановить. В кабинете задача остаётся с историей: кто поставил, что ответили, что приложили, кто принял.
2. Явный приоритет. Если всё срочное, срочного нет. Порядок задаёте вы — этого достаточно, чтобы конвейер делал сначала важное.
3. Регулярная приёмка. Двадцать минут дважды в неделю. Иначе сделанное копится непринятым и блокирует зависимые задачи.

Когда переписывать всё-таки дешевле

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

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

Во всех остальных случаях разумнее развивать существующее, а обновлять — частями. Это скучнее, но дешевле и безопаснее для бизнеса, который работает прямо сейчас.

Практический вывод

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

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

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

Возьмётесь ли вы дорабатывать продукт, который писали не вы?

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

Что быстрее: доработать существующее или написать заново?

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

Как понять, что доработка не сломает работающее?

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

Можно ли отдавать мелкие правки пачками?

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

Что происходит, если после выкладки что-то отвалилось?

Сначала возвращается предыдущее рабочее состояние, потом разбирается причина. Откат должен занимать минуты — если он занимает часы, это не поддержка, а лотерея.