Диагностика техдолга за 2–3 недели: что проверяем и как считаем цену

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

Диагностика нужна, чтобы перевести разговор из оценок в цифры: что именно стоит денег, сколько и в каком порядке это чинить. Ниже — как устроена такая работа на две-три недели.

Аудит без плана — это отчёт в стол

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

Хороший результат диагностики отвечает на четыре вопроса:

• что происходит сейчас — без оценок и прилагательных;
• сколько стоит каждая проблема — в инженерных днях, деньгах и риске;
• что делать в первые 90 дней, что — в следующие 180 и 365;
• что можно не делать вообще.

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

Шесть срезов

Код и архитектура

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

Пайплайн и качество

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

Инфраструктура и расходы

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

Безопасность и доступы

Кто куда имеет доступ, где лежат секреты, что будет при утечке, как устроена работа с персональными данными. В малом бизнесе это обычно самая запущенная часть — просто потому, что ею никто не занимается системно.

Команда и подрядчики

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

Данные и метрики

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

Как техдолг превращается в деньги

У каждой находки в карте три оценки:

• Стоимость исправления — в инженерных днях, с разбивкой по этапам;
• Стоимость бездействия — сколько времени теряется на каждом релизе, сколько стоит простой, сколько — внеплановые работы;
• Риск — вероятность и последствия: от «неприятно» до «остановка продукта» или «штраф за персональные данные».

Дальше приоритизация: сначала то, что одновременно дорого стоит и создаёт риск; потом то, что просто дорого; отдельно — то, что можно не трогать. В плане на 90 дней обычно оказывается 5–8 пунктов, а не 40.

Что происходит по неделям

Неделя 1. Доступы, интервью, чтение кода и конфигураций, разбор инцидентов и бэклога. Цель — увидеть, как всё устроено на самом деле, а не как описано в документации.

Неделя 2. Каждая находка получает цену и риск. Здесь важна дисциплина: если оценку нельзя обосновать, она не попадает в карту.

Неделя 3. План на 90/180/365 дней, оценка ёмкости команды, презентация для руководства — с вопросами и ответами, без «мы всё улучшим».

Защита документа перед не-техническим руководством — не формальность. Это тот момент, когда решение либо принимается, либо откладывается навсегда.

Чего в диагностике нет

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

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

Когда диагностика не нужна

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