В восьми случаях из десяти правильный ответ — дорабатывать. Решение переписать работающую систему принимается обычно не по расчёту, а после третьей подряд правки, которая обошлась дороже ожидаемого: накапливается раздражение, и в какой-то момент фраза «да проще заново написать» звучит как вывод, хотя это ещё не вывод, а эмоция.
Проверяемых оснований для замены всего пять, и все они считаются по вашим же журналам заявок за последний год. Ниже — эти пять критериев с порогами, числовое правило 40 % для отдельного модуля, модельный расчёт на трёхлетнем горизонте и честный третий вариант, при котором ничего менять не надо вообще.
Сквозные ставки во всех расчётах: инженер подрядчика — 3 000 ₽/час, полная стоимость часа рядового сотрудника компании — 700 ₽/час. Модельная система: связка «сайт + CRM + учёт», внедрена три года назад за 900 000 ₽, обслуживает компанию на 18 сотрудников.
Пять критериев и пороги, при которых они срабатывают
Критерии устроены так, чтобы их можно было посчитать за один вечер по журналу заявок, письмам подрядчику и опросу трёх человек. Ни один из них не про «систему неудобно» — это ощущение, а не критерий.
| Критерий | Как измерить | Норма | Сработал, если |
|---|---|---|---|
| Доля отклонённых правок | Сколько заявок на изменение за квартал подрядчик оценил как «дешевле переписать» или не взял | до 10 % | свыше 30 % за квартал |
| Стоимость типового изменения | Часы на изменение того же класса сегодня против часов год назад | рост до 20 % в год | рост втрое и больше |
| Поддерживаемость стека | Сколько подрядчиков с рынка готовы взять систему на сопровождение после просмотра кода | три и больше | один, и это автор системы |
| Соответствие процессу | Доля операций, которые сотрудники делают в обход системы — в таблице, в мессенджере, на бумаге | до 10 % | свыше 30 % |
| Зависимость от человека | Сколько людей могут развернуть систему с нуля по документации, не спрашивая автора | два и больше | ноль или один |
Четвёртый критерий — самый недооценённый. Когда треть операций идёт мимо системы, дорабатывать нечего: люди уже построили параллельный процесс, и новая функция в систему просто не попадёт в работу. Как выглядит эта стадия и как её измерить за один рабочий день, разобрано в статье про систему, которую все обходят.
Пять горизонтальных шкал одна под другой, подписанных: «Отклонённые правки», «Стоимость изменения», «Поддерживаемость стека», «Соответствие процессу», «Зависимость от человека». На каждой шкале зелёная зона нормы слева (10 %, 20 %, три подрядчика, 10 %, два человека) и красная зона справа (30 %, рост втрое, один подрядчик, 30 %, один человек). Справа от шкал вертикальная легенда вердиктов: «0–1 сработали — дорабатывать», «2–3 — менять модуль», «4–5 — переписывать». Чертёжный стиль, подписи по-русски.
Правило 40 % для отдельного модуля
Пять критериев отвечают на вопрос о системе целиком. Но чаще проблема локальна: гниёт один модуль — слой обмена, генератор документов, расчёт цен, — а остальное работает нормально. Для модуля есть отдельное числовое правило, и оно проще.
Если три подряд оценки изменений в одном модуле оказались дороже 40 % стоимости переписывания этого модуля, дорабатывать его дальше бессмысленно: вы уже оплатили модуль заново, но остались со старым и с тремя заплатками поверх.
На числах модельной системы: слой обмена с учётом переписывается за 260 000 ₽, порог — 104 000 ₽. За полугодие пришли три правки, оценённые в 110 000 ₽, 130 000 ₽ и 120 000 ₽. Каждая выше порога, суммарно 360 000 ₽ — на 100 000 ₽ больше полной замены модуля. Дальше каждая следующая правка будет дороже предыдущей, потому что заплатки складываются.
Порог именно 40 %, а не 50 или 100, потому что в оценку замены модуля не входят ваши внутренние часы, тестирование и период сосуществования старой и новой версии. Реальная замена почти всегда дороже сметы примерно в полтора раза, и запас в 60 % как раз это покрывает.
Правило не работает, если складывать оценки из разных частей системы: дорогая правка отчётов ничего не говорит о состоянии обмена. Ведите журнал изменений с указанием модуля — без него правило не на чем применять, а спор с подрядчиком превращается в обмен впечатлениями.
Модельный расчёт: три года, два сценария
Сравнивать смету доработки со сметой замены — ошибка, из-за которой замену выбирают чаще, чем следует. Сравнивать надо накопленные затраты на одинаковом горизонте, и в затраты на замену обязаны попасть строки, которых нет ни в одном коммерческом предложении: параллельная работа двух систем, переобучение людей и потеря темпа на переходе.
Разница — 534 600 ₽ в пользу доработки, и это при том, что новой системе мы записали более дешёвое сопровождение и более дешёвые изменения. Риск срыва сроков в расчёт не заложен вообще, а он у проекта на 1 100 000 ₽ реален: полгода вместо трёх месяцев — обычная история, и каждый лишний месяц параллельной работы добавляет 30 000 ₽ прямых расходов и неизвестное количество потерянного темпа.
Разворачивается картина ровно в одной точке. Если ежегодные расходы на изменения в старой системе поднимаются с 120 000 ₽ до 298 200 ₽, трёхлетние суммы сравниваются: 1 280 000 ₽ постоянных затрат плюс три года изменений дают те же 2 174 600 ₽. Всё, что выше 300 000 ₽ в год на правки, — территория замены. Это примерно 100 часов работы инженера в год, то есть два часа в неделю только на то, чтобы система не отставала.
Двухосевой график за 36 месяцев. Ось X — месяцы, ось Y — накопленные затраты в рублях. Синяя линия «Доработка» стартует со ступени 380 000 ₽ и растёт равномерно до 1 640 000 ₽. Оранжевая линия «Замена» стартует со ступени 1 100 000 ₽, в первые три месяца растёт круче (параллельная работа, переобучение, провал темпа) и приходит к 2 174 600 ₽. Справа между концами линий фигурная скобка с подписью «534 600 ₽». Отдельная пунктирная линия подписана «замена сравнивается при изменениях 298 200 ₽ в год». Чертёжный стиль, подписи по-русски.
Частичная замена модулем: вариант, который считают реже всех
Между «терпеть» и «переписать всё» лежит третье инженерное решение: вырезать один гнилой модуль и поставить на его место новый, оставив остальное нетронутым. Оно требует, чтобы у системы были границы между частями, — и если их нет, это уже сам по себе аргумент в пользу того, что стек непригоден к развитию.
- 1Шаг 1. Найти границу
Определить, чем модуль обменивается с остальной системой: какие данные принимает, какие отдаёт, какие таблицы читает. Если список умещается на страницу — замена возможна. Если модуль лезет напрямую в половину базы, границы нет, и вырезать его нельзя.
- 2Шаг 2. Зафиксировать поведение
Собрать набор проверок: 20–30 реальных случаев с входом и ожидаемым выходом, включая исключения. Это самая ценная часть работы: именно здесь всплывают неписаные правила, которые иначе потерялись бы.
- 3Шаг 3. Собрать новый модуль рядом
Новый модуль пишется параллельно и какое-то время работает вхолостую на том же потоке: результаты сравниваются со старым, расхождения разбираются. Старый контур при этом остаётся рабочим.
- 4Шаг 4. Переключить и подождать
Переключение — одна настройка, откат — та же настройка обратно. Старый модуль не удаляют минимум месяц. Это принципиально отличает частичную замену от переписывания с нуля, где откатываться некуда.
На числах модельной системы замена слоя обмена вместе с набором проверок обходится в 340 000 ₽ — против 1 100 000 ₽ за полную замену и против 360 000 ₽, которые уже потрачены на три бесполезные правки того же модуля. Практически всегда это лучший из трёх вариантов, и практически всегда его не рассматривают, потому что он не выглядит ни как экономия, ни как решительный шаг.
Что теряется при переписывании и не попадает в смету
Смета на замену считает работу по написанию функций. Она не считает то, чего в функциях нет, но что накопилось за три года эксплуатации. Три потери повторяются в каждом проекте замены.
- Неявные правила. За три года в систему въехали десятки исключений: этому клиенту скидка считается иначе, эти позиции не резервируются, для этого склада округление в другую сторону. Их нет в документации, они есть в коде и в головах двух человек. Восстанавливать их приходится либо разбором старого кода, либо по инцидентам после запуска — то есть на живых клиентах.
- Повторное обучение людей. Восемнадцать сотрудников по шесть часов — это 75 600 ₽ прямых потерь рабочего времени, но настоящая цена в другом: первые недели человек делает знакомую операцию медленнее и ошибается там, где не ошибался. Этот эффект длится 4–8 недель и не компенсируется инструкцией.
- Провал темпа на переходе. Пока новая система не набрала данные и доверие, часть работы возвращается в ручной режим. В расчёте это два месяца по 60 часов — 84 000 ₽, и это оптимистичная оценка для системы, через которую идут заявки.
Отдельно стоит проверить, не путаете ли вы усталость от системы с расхождением системы с реальностью. Второе лечится обновлением знаний и справочников за часы, а не заменой за миллион, и выглядит снаружи почти так же: система уверенно делает не то, что нужно сегодня.
Сравнение в две колонки. Левая «Переносится по смете»: функции, отчёты, интеграции, права доступа, справочники. Правая «Остаётся в старой»: неписаные исключения, привычка сотрудников, накопленные пороги и настройки, история решений. Под правой колонкой подпись с числами: «75 600 ₽ переобучение, 84 000 ₽ провал темпа — расходы, которых нет в смете». Чертёжный стиль, подписи по-русски.
Третий вариант: оставить как есть и дописать регламент
Самый недооценённый исход — не делать ничего с системой, а закрыть недостающее руками и записать это в регламент. Он честно выигрывает, когда объём ручной работы мал, а цена доработки велика.
Порог здесь считается в одну строку: доработка за 380 000 ₽ окупается за три года, если снимает ручной работы не меньше чем на 126 700 ₽ в год — это 15 часов в месяц по ставке 700 ₽/час. Всё, что ниже, дешевле делать руками и записать в инструкцию. Тот же принцип лежит в основе методики расчёта окупаемости: считается снятая работа, а не удобство.
У ручного регламента есть одно жёсткое условие: у операции должен быть письменно назначенный исполнитель и заместитель. Регламент без имени — это не решение, а обещание, и через два месяца операция начнёт пропускаться в отпусках и на пиках.
Когда переписывать не надо, даже если очень хочется
Четыре ситуации, в которых замена гарантированно окажется дороже и хуже. Проверьте их до того, как запрашивать сметы.
- Сработал один критерий из пяти, и это «неудобно». Один сигнал — это повод сделать четыре доработки, а не проект на 1 100 000 ₽. Пересчитайте критерии через квартал: если ни один не ушёл в красную зону, разговор о замене закрыт на год.
- Не описан процесс, который должна поддерживать новая система. Переписывание без описания процесса воспроизводит старую систему с новыми ошибками. Сначала карта процесса, потом смета, и часто на этапе карты выясняется, что менять надо не систему, а порядок работы.
- У компании впереди 3–6 месяцев пиковой нагрузки. Сезон, переезд склада, крупный контракт, отчётный период. Переход между системами обязательно съест темп, и делать это на пике — способ получить и старые проблемы, и новые одновременно.
- Причина замены — конфликт с подрядчиком, а не состояние системы. Смена исполнителя и смена системы — это два разных решения, и второе стоит в три-четыре раза дороже. Сначала проверьте третий критерий: если систему готовы взять на сопровождение хотя бы три компании с рынка, менять надо подрядчика, а систему оставить.
И одно правило, которое стоит проговорить вслух до начала любого из трёх сценариев: решение о замене не принимается на встрече, где обсуждают конкретный сбой. В этот момент цена ошибки видна, а цена перехода — нет. Считайте через неделю после инцидента, по журналу за год, и с числом из последней строки — сколько стоят изменения в вашей системе за год.
Систему меняют не потому, что она старая, а потому, что каждая следующая правка в ней дороже предыдущей. Это измеряется, а не ощущается.
