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

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

В Копидефенд обрабатывается более 3000 решений в неделю. При таком масштабе техдолг не просто накапливается. Он начинает влиять на результат. Но перед этим долго остаётся невидимым. Как и в коде.

Хардкод: ручные исключения, ставшие правилом

Первый тип техдолга: решения, которые принимались ситуативно, но остались навсегда.

Показательный случай из практики. Целый регион был исключён из работы. Основание: ощущение, что «там суды не работают нормально». Не данные, не аналитика, а именно ощущение, подкреплённое парой неудачных кейсов. Решение зафиксировали и забыли. Оно стало частью процесса.

Когда через время я наконец проверил гипотезу на данных, результат оказался неожиданным: показатели этого региона были выше среднего. Суды работали, и работали хорошо. А сервис всё это время терял дела, потому что допущение превратилось в правило без валидации.

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

Важное уточнение: не всякое ограничение является техдолгом. В Копидефенд есть осознанные политики, например ограничения по социально значимым категориям. Сервис не претензирует учреждения здравоохранения, образования, благотворительные организации. Это зафиксировано, обосновано и пересматривается. Это архитектурное решение, а не костыль. Техдолг начинается там, где ограничение не осознано, не зафиксировано и не проверяется.

TODO в продакшене: «потом разберёмся»

Второй тип: временные решения, которые стали постоянными. Каждое из них в момент принятия выглядело безобидно.

Генерация документов. На раннем этапе каждый сгенерированный документ проверялся: все ли поля заполнены, корректны ли данные. Потом объём вырос, проверку убрали, потому что «и так работает». Через время обнаружилось, что часть полей уходит как undefined. Документы отправлялись, формально всё было в порядке. Но данные в части из них были некорректны. Пропущенный тест, которого никто не заметил, пока не посмотрели внимательно.

Та же история с автоматическими письмами. Настроили, запустили, перестали проверять содержимое. Система отправляла, значит, работала. До момента, пока не выяснилось, что не совсем так.

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

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

Молчаливый сбой: техдолг, который не кричит

Самый опасный вид техдолга: тот, который не порождает ошибок. Всё работает. Метрики в норме. Никто не жалуется.

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

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

В разработке это аналог ситуации, когда QA молча правит баги руками вместо того, чтобы завести тикет. Процесс выглядит рабочим. Баг-трекер чистый. Все довольны. Но по факту система компенсируется ручным трудом, который не масштабируется.

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

Почему техдолг не видят

Техдолг в процессах невидим по тем же причинам, что и в коде. Он не ломает систему. Не порождает алертов. Не попадает в отчёты.

Три причины невидимости.

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

Компенсация. Люди закрывают дыры молча. Не потому что скрывают, а потому что считают это частью работы. Сотрудник, который каждый день правит сто документов вручную, не считает это проблемой. Он считает это своей задачей.

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

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

Как я с этим работаю

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

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

Главное изменение оказалось не технологическим, а культурным. Раньше «так исторически сложилось» было нормальным ответом на вопрос «почему так?». Сейчас это триггер для проверки: на каких данных основано решение? Когда последний раз его валидировали? Что покажут цифры, если посмотреть?

Техдолг: не только про код

Везде, где есть процессы, правила и масштаб, техдолг накапливается одинаково. Ручные исключения становятся правилами. Временные решения становятся постоянными. Люди компенсируют системные проблемы молча. И всё это невидимо, пока не начнёшь измерять.

Отличие одно: в разработке культура работы с техдолгом существует давно. Есть рефакторинг, код-ревью, линтеры, метрики качества. В юридических процессах, и шире, в любых операционных процессах, эта культура только формируется. Я строю её на данных.