Технический долг в деньгах: как объяснить бизнесу цену «быстро и криво»

Любой разработчик 1С хотя бы раз слышал фразу: "Сделай быстро, потом переделаем". Иногда это действительно разумно: проверить гипотезу, успеть к отчетности, закрыть критичный участок. Но чаще "быстро" превращается в "криво", а "потом" не наступает никогда. Через год команда уже боится трогать этот код, а бизнес удивляется, почему любая мелочь стоит как крыло самолета. Технический долг - это не абстрактное понятие из книжек. Это реальные деньги, которые компания теряет каждый день. В этой статье я покажу, как посчитать эти потери и как объяснить руководителю, что "быстро и криво" на самом деле стоит дороже, чем кажется.

🧾 Что такое технический долг на самом деле

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

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

Возьмем строительство дома. Можно быстро сложить стены из пеноблоков без фундамента. Дом простоит какое-то время. Но когда нужно добавить второй этаж, выяснится, что стены не выдержат. Придется либо сносить все, либо укреплять стены, а это дороже, чем сразу сделать нормально. С кодом та же история. Только дом видно, а код - нет. Поэтому бизнесу сложно понять, почему "просто добавить поле в отчет" занимает две недели.

🐢 Почему "быстро" сейчас = медленно потом

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

Типичные симптомы (перечень автора; состав мест правки зависит от вашей конфигурации, проверьте поиском по конфигурации, где реквизит используется):

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

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

💰 Как оценить стоимость техдолга в деньгах

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

1. Время на задачу

Сравните, сколько времени занимает типовая задача в "чистой" системе и в системе с долгом. Например, добавление нового вида документа. В условном примере в нормальной конфигурации это 8 часов, в запутанной - 40 часов. Разница - 32 часа. При стоимости часа разработчика в 2000 рублей (возьмем среднюю зарплату 100-150 тысяч на руки плюс налоги) получается 64 000 рублей на одну задачу. А если таких задач в год двадцать? Это уже 1,28 миллиона рублей.

2. Количество переделок

Из-за некачественного кода часто возникают ошибки. Каждая ошибка - это время на ее воспроизведение, исправление и проверку. Плюс нервы пользователей и потеря данных. Посчитайте, сколько времени команда тратит на поддержку "горящих" проблем. Если это 20% рабочего времени - это зарплата одного разработчика из пяти. В год это около 300 000 рублей на человека, а для команды из пяти человек - 1,5 миллиона.

3. Текучесть команды

Разработчики не любят работать с "легаси". Если код сложный и запутанный, опытные специалисты уходят. На поиск нового разработчика уходит в среднем 2-3 месяца, плюс адаптация. Единого норматива стоимости замены нет, посчитайте свою из трех частей: зарплата за время поиска и адаптации, оплата рекрутера, недополученная выработка. Условный пример без рекрутера: 2-3 месяца при зарплате 150 000 рублей дают 300 000-450 000 рублей на одного ушедшего. А если уходит вся команда - это катастрофа.

4. Риски срыва сроков

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

🔥 Замер по истории Git: где долг копится

Часы из трекера показывают цену задач, а история Git показывает, где именно они тратятся. Если конфигурация выгружена в файлы (Конфигуратор: "Выгрузить конфигурацию в файлы", либо EDT), то модули лежат как .bsl, а git log --numstat знает, сколько раз и на сколько строк правили каждый. Скрипт git_hotspots.py (Python 3, только стандартная библиотека, текст в конце статьи) собирает это в таблицу: коммиты, изменённые строки, размер сейчас и произведение "коммиты x строки" как оценку горячести модуля.

python git_hotspots.py <путь к репозиторию> --since 2025-01-01 --top 10

Ниже вывод скрипта на учебном репозитории из трех модулей, который я собрала для проверки (учебные данные, не реальная конфигурация: модуль документа на 900 строк, обмен на 300 строк, мелкий общий модуль на 20 строк):

Как читать: мелкий модуль правили чаще всех (8 коммитов), но он маленький, и правки дешевые. Модуль документа правили 6 раз, и в нем 950 строк: сюда уходит больше всего внимания разработчика. Рефакторинг стоит начинать с верхней строки таблицы. Деньги из таблицы не получаются: часы на правки этих модулей берите из своего трекера и умножайте на ставку так же, как в примерах выше. Цифры по вашей конфигурации даст только запуск на вашем репозитории.

🤝 Как говорить с бизнесом: "скорость поставки" вместо "техдолга"

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

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

Еще один хороший аргумент - "скорость поставки новых фич". Если конкуренты выпускают обновления раз в месяц, а вы раз в полгода, потому что все ломается, вы теряете рынок. Посчитайте, сколько вы недозарабатываете из-за того, что не можете быстро выкатить нужную функцию. Это и есть цена техдолга.

🧮 Практические шаги: как подсчитать и показать цифры

Чтобы разговор с бизнесом был предметным, нужно провести небольшое исследование. Что можно сделать.

Шаг 1. Выберите 5-10 типовых задач

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

Шаг 2. Оцените "идеальное" время

Допустим, система написана идеально. Сколько бы заняла та же задача? Можно спросить у опытного разработчика или оценить по аналогии с типовой конфигурацией. Разница между "идеалом" и фактом - это и есть избыточные затраты из-за долга.

Шаг 3. Посчитайте потери за год

Умножьте разницу на количество задач в год. Например, 10 задач в месяц, каждая перерасходуется на 8 часов. Итого 80 часов в месяц, 960 часов в год. При стоимости часа 2000 рублей это 1,92 миллиона рублей. Плюс время на исправление ошибок и поддержку - еще столько же. Получается около 4 миллионов рублей в год. Это и есть стоимость техдолга для компании.

Шаг 4. Оцените стоимость исправления

Теперь оцените, сколько нужно вложить, чтобы погасить долг. Это может быть рефакторинг модулей, переход на новую конфигурацию, обновление платформы. Сравните эти затраты с ежегодными потерями. Если рефакторинг стоит 2 миллиона, а потери - 4 миллиона в год, то окупаемость - полгода. Это отличный аргумент для бизнеса.

Условный пример: перенос доработок при обновлении

Допустим, у вас есть конфигурация на базе "1С:Управление торговлей". За годы разработки в ней накопилось много "кастомного" кода. Обновление типовой конфигурации занимает две недели вместо двух дней, потому что приходится переносить доработки. Каждое обновление - это 10 рабочих дней по 8 часов, то есть 80 часов. При стоимости часа 2000 рублей - 160 000 рублей. Если обновления выходят раз в квартал, это 640 000 рублей в год только на перенос доработок. А если добавить сюда простой бизнеса, пока система недоступна, - сумма вырастет в разы.

🏢 Аргументы для разных типов бизнеса

В зависимости от того, с кем вы разговариваете, акценты могут смещаться.

Для продуктовой компании

Здесь главный аргумент - скорость вывода новых функций. Если вы не можете быстро реагировать на запросы рынка, вы проигрываете конкурентам. Посчитайте, сколько прибыли приносит одна новая функция в месяц. Если она стоит 500 000 рублей, а из-за техдолга вы выпускаете ее на месяц позже, то теряете 500 000. Это наглядная цифра.

Для заказной разработки

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

Для внутренней автоматизации

Здесь главный аргумент - риски. Если система упадет в середине квартала, вы потеряете данные и остановите производство. Стоимость простоя может быть огромной. Посчитайте, сколько стоит час простоя вашего отдела продаж или склада. Если это 100 000 рублей в час, то простой на один день - это 800 000. Техдолг - это бомба замедленного действия.

📌 Как не скатиться в абстракции: конкретные сценарии

Чтобы разговор был убедительным, приведите несколько конкретных сценариев, которые знакомы бизнесу.

Сценарий 1. Обновление платформы 1С

Вышла новая версия платформы. В ней исправлены ошибки, повышена производительность, но есть и изменения, которые могут сломать ваш код. Если код написан с использованием устаревших методов, обновление займет много времени. Бизнес спрашивает: "Зачем нам это обновление?" А вы отвечаете: "Если мы не обновимся, мы не сможем получать обновления законодательства и использовать новые возможности, и через два года переход будет еще больнее". Это и есть цена техдолга.

Сценарий 2. Интеграция с новым сервисом

Компания решила подключить новый онлайн-магазин или банк. Для этого нужна интеграция с 1С. Если внутренняя структура данных запутана, интеграция превращается в ад. Придется переписывать обмен, менять логику обработки заказов. В итоге проект, который мог бы занять неделю, растягивается на месяцы. Бизнес платит за разработку, а также теряет прибыль от неработающего канала продаж.

Сценарий 3. Расширение штата

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

🛑 Что делать, если бизнес все равно не соглашается

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

Но чаще всего бизнес просто не понимает, что такое техдолг. Поэтому ваша задача - просвещать. Рассказывайте о нем на регулярных встречах, показывайте графики скорости, приводите примеры из своей практики. Чем больше вы говорите, тем меньше техдолг будет восприниматься как отговорка ленивых программистов.

🚀 Как начать погашать техдолг уже сегодня

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

• Код-ревью. Пусть каждый разработчик проверяет код коллеги.
• Автотесты. Хотя бы для ключевых сценариев.
• Регулярное обновление платформы и конфигурации.
• Документирование нестандартных решений.
• Выделяйте 10-20% времени на "уборку" в коде (ориентир автора, подберите долю под свою команду).

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

🏁 Вывод

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

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

💻 Приложение: скрипт git_hotspots.py

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74

#!/usr/bin/env python3
"""Горячие модули по истории Git: где чаще всего правят большие файлы.

Читает `git log --numstat` выгрузки конфигурации 1С в файлы (по умолчанию *.bsl),
считает по каждому файлу число коммитов, изменённых строк (добавлено + удалено) и текущий размер,
ранжирует по «коммиты × размер» и печатает таблицу Markdown.
Числа берутся только из истории репозитория; ничего не оценивается на глаз.

Запуск: python git_hotspots.py <путь к репозиторию> [--since 2025-01-01] [--top 10] [--ext .bsl,.xml]
"""
import argparse
import subprocess
import sys
from collections import defaultdict
from pathlib import Path


def git(repo, *args):
    r = subprocess.run(["git", "-c", "core.quotepath=off", "-C", str(repo), *args], capture_output=True, text=True, encoding="utf-8", errors="replace")
    if r.returncode:
        sys.exit(f"git {' '.join(args)}: {r.stderr.strip()}")
    return r.stdout


def collect(repo, since, exts):
    args = ["log", "--numstat", "--no-renames", "--format=@@%H"]
    if since:
        args.append(f"--since={since}")
    commits, churn = defaultdict(int), defaultdict(int)
    for line in git(repo, *args).splitlines():
        parts = line.split("\t")
        if len(parts) != 3 or not parts[2].lower().endswith(exts):
            continue
        add, dele, path = parts
        if add == "-":  # бинарный файл
            continue
        commits[path] += 1
        churn[path] += int(add) + int(dele)
    return commits, churn


def size(repo, path):
    p = Path(repo) / path
    if not p.is_file():
        return None  # файл удалён
    with p.open(encoding="utf-8", errors="replace") as f:
        return sum(1 for _ in f)


def main():
    sys.stdout.reconfigure(encoding="utf-8")
    ap = argparse.ArgumentParser(description=__doc__, formatter_class=argparse.RawDescriptionHelpFormatter)
    ap.add_argument("repo")
    ap.add_argument("--since", default="")
    ap.add_argument("--top", type=int, default=10)
    ap.add_argument("--ext", default=".bsl")
    a = ap.parse_args()
    exts = tuple(e.strip().lower() for e in a.ext.split(","))
    commits, churn = collect(a.repo, a.since, exts)
    rows = []
    for path, n in commits.items():
        s = size(a.repo, path)
        if s:
            rows.append((n * s, path, n, churn[path], s))
    rows.sort(reverse=True)
    print(f"Файлов с историей: {len(commits)}, существует сейчас: {len(rows)}")
    print("| Модуль | Коммитов | Изменено строк | Строк сейчас | Коммиты × строки |")
    print("|---|---:|---:|---:|---:|")
    for score, path, n, ch, s in rows[:a.top]:
        print(f"| {path} | {n} | {ch} | {s} | {score} |")


if __name__ == "__main__":
    main()

 

Нинель Адольевна Щербакова (Ninel_S)

Архитектор • SRE & DevOps инженер • HighLoad 1С

Автор 28+ технических публикаций на Infostart. Разработчик NOPik, SRE-Suite-for-1C и мультиагентных ассистентов для экосистемы 1С:Предприятие.