В 1С-командах техдолг часто обсуждают так:
- “Тут надо переписать обработку”.
- “Этот обмен сделан на костылях”.
- “В расширении бардак”.
- “Запрос написан плохо”.
- “Нужно время на рефакторинг”.
- “Код старый, страшно трогать”.
Разработчику обычно понятно, о чем речь. Он видел этот код, ловил ошибки, помнит ночной релиз, знает, где система может сломаться.
А бизнес слышит другое:
“Разработчики хотят потратить время на внутреннюю красоту, которая не дает новой функции”.
И вот тут начинается главная проблема.
Технический долг сам по себе может быть реальным, опасным и дорогим. Но если его объяснять только техническим языком, он почти всегда проигрывает новым задачам.
Потому что новая задача звучит понятно:
- добавить отчет;
- запустить обмен;
- ускорить согласование;
- сделать печатную форму;
- подключить ЭДО;
- поправить права;
- добавить реквизит на форму.
А техдолг звучит туманно:
“Нужно привести код в порядок”.
В этой статье разберем, как говорить о техдолге 1С языком бизнеса: через риски, сроки, стоимость изменений, устойчивость релизов, зависимость от людей и влияние на пользователей.
Что такое техдолг в 1С простыми словами
Техдолг — это не просто “плохой код”.
Это накопленная цена прошлых решений, которая начинает мешать будущим изменениям.
Иногда техдолг появляется из-за ошибок. Иногда — из-за спешки. Иногда — из-за нормальных компромиссов, которые были оправданы в моменте.
Например, была срочная задача:
- нужно быстро починить обмен;
- нужно к утру добавить реквизит;
- нужно срочно выгрузить документы;
- нужно временно обойти ограничение типовой конфигурации;
- нужно быстро закрыть проблему пользователей перед отчетным периодом.
Команда сделала решение быстро. Бизнес получил результат. Все выдохнули.
Но если потом это временное решение не разобрали, не описали, не улучшили и не включили в нормальный процесс сопровождения, оно становится техдолгом.
Техдолг — это не всегда ошибка. Часто это компромисс, за который забыли заплатить позже.
Как техдолг выглядит в 1С
В 1С техдолг редко выглядит как одна большая проблема. Чаще это набор маленьких участков, которые по отдельности вроде бы терпимы, но вместе делают систему тяжелой и рискованной.
1. Внешние обработки без владельца
Где-то лежит внешняя обработка. Она важная. Ей пользуются. Но непонятно:
- кто ее написал;
- какая версия актуальная;
- для какой конфигурации она проверялась;
- можно ли ее обновить;
- что она меняет;
- кто отвечает, если она сломается.
Пока работает — никто не трогает. После обновления — начинается расследование.
2. Расширения, которые стали второй конфигурацией
Расширение создавали для одной задачи. Потом туда добавили еще одну. Потом еще. Потом временную правку. Потом перехват формы. Потом служебный регистр.
Через год расширение уже никто не воспринимает как аккуратный слой доработки. Это отдельный кусок системы, который страшно отключать и сложно обновлять.
3. Обмены, которые держатся на памяти одного разработчика
Обмен работает, пока все идет по привычному сценарию.
Но если меняется формат, падает API, приходит неожиданный JSON, заканчивается сертификат, меняются права пользователя или контрагент присылает нестандартный документ — выясняется, что всю логику знает только один человек.
4. Запросы и отчеты, которые “просто долго строятся”
Отчет строится 10 минут. Пользователи привыкли запускать его на обед. Разработчики знают, что запрос тяжелый. Руководитель слышит: “ну он всегда так работал”.
Но это тоже техдолг. Он выражается не только в коде, а в потерянном времени пользователей, нагрузке на базу и риске зависаний в критичные периоды.
5. Регламентные задания без контроля
Есть фоновые задания. Они что-то загружают, отправляют, пересчитывают, синхронизируют.
Но нет понятного реестра:
- что запускается;
- когда запускается;
- сколько длится;
- что делать при ошибке;
- кто владелец;
- можно ли отключать на копии базы;
- что будет, если задание не выполнится.
Пока всё тихо — кажется, что проблемы нет. Но одна ошибка в фоновом процессе может затронуть документы, обмены, уведомления или отчетность.
Почему бизнес не слышит техдолг
Чаще всего не потому, что бизнес “не понимает разработку”.
А потому что разработчики говорят о техдолге словами, которые не связаны с бизнес-результатом.
| Как говорит разработчик | Что слышит бизнес | Как лучше сказать |
|---|---|---|
| Нужно переписать старую обработку | Хотят заняться внутренней красотой | Сейчас обработка зависит от одного человека и может сломаться после обновления |
| Запрос написан плохо | Разработчику не нравится чужой код | Отчет создает нагрузку на базу и занимает время пользователей каждый день |
| В расширении бардак | Опять технические придирки | Мы не можем быстро оценить, что сломается при обновлении типовой конфигурации |
| Нужно сделать рефакторинг | Новой функции не будет | Без этого каждая следующая доработка в этом месте будет дольше и рискованнее |
| Нет нормального логирования | Зачем делать, если работает? | При следующем сбое мы снова потратим часы на поиск причины вместо быстрого восстановления |
Бизнесу не обязательно понимать все технические детали. Но бизнес должен понимать последствия.
Техдолг надо объяснять не через “код плохой”, а через “что будет дороже, медленнее или рискованнее, если ничего не делать”.
Пять языков техдолга, которые понятны бизнесу
1. Риск
Самый понятный язык — риск.
Не “у нас плохой обмен”, а:
“Если изменится формат ответа API, мы можем потерять загрузку документов на несколько часов или дней, потому что нет нормальной обработки ошибок и повторных попыток”.
Не “расширение непонятное”, а:
“Перед обновлением мы не можем оценить влияние расширения на критичные формы. Значит, растет риск ошибки в рабочей базе”.
2. Срок
Техдолг часто увеличивает срок будущих изменений.
Например:
- задача могла бы занять 8 часов, но занимает 24;
- разработчик сначала разбирается в старой логике;
- половина времени уходит на страх “что бы не сломать”;
- тестирование растягивается, потому что нет понятных сценариев;
- после релиза появляется больше исправлений.
Бизнесу можно объяснить так:
“Мы можем продолжать добавлять функции в этот участок, но каждая следующая доработка будет дороже по времени, потому что база решения неустойчива”.
3. Деньги
Деньги — не всегда прямой бюджет. Внутри компании это может быть время сотрудников, простой процесса, задержка релиза или отвлечение команды.
Например:
- отчет строится 10 минут и его запускают 20 человек в день;
- разработчики каждый месяц вручную исправляют последствия одного и того же обмена;
- после каждого обновления команда тратит день на проверку внешних обработок вручную;
- пользователи ведут параллельный Excel, потому что процесс в 1С неудобен;
- одна ошибка в правах блокирует работу отдела.
Если показать стоимость повторения, техдолг перестает быть “внутренней задачей ИТ”.
4. Зависимость от людей
Один из самых сильных аргументов — зависимость от конкретного человека.
В 1С это встречается часто:
- только один разработчик знает обмен;
- только один аналитик понимает маршрут согласования;
- только один человек умеет обновлять конкретную базу;
- только один сотрудник знает, где лежат актуальные внешние обработки;
- только один специалист помнит, зачем сделано расширение.
Для бизнеса это риск непрерывности.
“Если этот человек недоступен, мы не можем безопасно изменить или восстановить критичный процесс”.
5. Скорость изменений
Техдолг редко полностью останавливает работу. Чаще он делает систему вязкой.
Каждая новая задача требует больше уточнений, больше проверок, больше ручного контроля и больше осторожности.
В итоге бизнес видит:
- команда занята, но изменения идут медленно;
- простые задачи почему-то долго оцениваются;
- обновления откладываются;
- релизы становятся нервными;
- разработчики часто говорят “надо сначала разобраться”.
Это и есть влияние техдолга на скорость.
Как оценить техдолг без сложной методологии
Не обязательно сразу внедрять тяжелую систему оценки технического долга.
Для 1С-команды часто достаточно простой карточки.
| Поле | Что писать | Пример |
|---|---|---|
| Участок | Где находится проблема | Обмен с СБИС, расширение согласования, отчет по задолженности |
| Симптом | Как проблема проявляется | Падает при нестандартном ответе API |
| Бизнес-риск | Что может пострадать | Документы ЭДО не загрузятся вовремя |
| Частота | Как часто повторяется | 1–2 раза в месяц |
| Последствия | Что происходит при сбое | Ручная проверка, задержка обработки, обращения пользователей |
| Зависимость | Кто понимает участок | Один разработчик |
| Оценка исправления | Сколько нужно времени | 16–24 часа |
| Что будет, если отложить | Цена бездействия | Повторяющиеся сбои и риск проблем после обновления |
Такая карточка помогает уйти от абстрактного “надо бы когда-нибудь переписать” к понятному управленческому решению.
Матрица приоритета техдолга
Не весь техдолг нужно закрывать сразу.
Это важный момент. Если прийти к бизнесу со списком из 100 пунктов и сказать “надо всё исправить”, скорее всего, не исправят ничего.
Лучше разделить техдолг по приоритету.
| Приоритет | Описание | Что делать |
|---|---|---|
| Критичный | Может остановить важный процесс, сорвать релиз, заблокировать пользователей или привести к потере данных | Планировать в ближайший релиз или отдельное окно |
| Высокий | Регулярно увеличивает сроки, создает ручную работу или зависит от одного человека | Включать в квартальный план улучшений |
| Средний | Мешает сопровождению, но не создает острого риска | Закрывать вместе с изменениями в этом участке |
| Низкий | Неприятен технически, но почти не влияет на пользователей, сроки и риски | Не трогать отдельно, вернуться при доработке участка |
Этот подход помогает не превращать техдолг в бесконечную борьбу “разработчики против бизнеса”.
Команда не просит остановить всё ради улучшений. Она показывает, где долг действительно опасен, а где его можно осознанно оставить.
Пример: как одна и та же проблема звучит по-разному
Возьмем типовую ситуацию.
Есть старая внешняя обработка для загрузки документов. Она работает давно, но:
- нет владельца;
- нет описания;
- нет логирования;
- при ошибке API пользователь видит непонятное сообщение;
- после обновления ее каждый раз проверяют вручную;
- часть логики знает только один разработчик.
Плохая формулировка:
“Нужно переписать старую обработку, потому что она плохо написана”.
Лучше:
“Сейчас загрузка документов зависит от обработки без владельца и нормального логирования. При сбое мы не можем быстро понять причину, а после обновлений каждый раз проверяем ее вручную. Если выделить 24 часа на доработку, мы снизим риск простоя загрузки и сократим время диагностики ошибок”.
Во втором варианте бизнес видит:
- какой процесс затронут;
- какой риск есть сейчас;
- что именно предлагается сделать;
- какой эффект ожидается;
- почему это не просто “переписать ради красоты”.
Как включать техдолг в план
Есть несколько рабочих вариантов.
Вариант 1. Процент времени
Например, команда заранее договаривается: 10–15% времени в каждом месяце уходит на техдолг и улучшения.
Плюс: долг не выпадает из потока.
Минус: если нет приоритизации, это время может уходить на самые заметные, но не самые важные проблемы.
Вариант 2. Один пункт техдолга в каждый релиз
Команда включает в каждый релиз хотя бы одно улучшение:
- разобрать старую обработку;
- добавить логирование;
- описать сценарий проверки;
- оптимизировать тяжелый запрос;
- убрать ручной шаг;
- закрыть зависимость от одного человека.
Плюс: подход простой и понятный.
Минус: крупный техдолг так может закрываться слишком медленно.
Вариант 3. Квартальная карта рисков
Раз в квартал команда собирает список технических рисков и выбирает несколько пунктов, которые реально нужно закрыть.
Это хорошо работает для команд сопровождения, где всегда есть поток срочных задач.
Можно сделать простую таблицу:
| Риск | Влияние | Вероятность | Оценка работ | Решение |
|---|---|---|---|---|
| Старая обработка загрузки документов | Высокое | Средняя | 24 часа | Включить в план месяца |
| Медленный отчет по задолженности | Среднее | Высокая | 16 часов | Оптимизировать вместе с задачей по отчету |
| Непонятное расширение формы договора | Высокое | Средняя | 8 часов на анализ | Проверить перед обновлением |
Что не стоит называть техдолгом
Есть обратная проблема: иногда техдолгом называют всё, что разработчику не нравится.
Это опасно. Если бизнес один раз увидит, что под видом техдолга ему продают субъективную “красоту”, доверие снизится.
Не каждый некрасивый участок кода нужно срочно переписывать.
Не каждый старый отчет нужно переделывать.
Не каждое расширение нужно дробить.
Не каждый модуль должен быть идеальным.
Техдолг стоит поднимать в план, когда есть хотя бы один понятный эффект:
- снижение риска;
- ускорение будущих изменений;
- уменьшение ручной работы;
- снижение нагрузки на базу;
- повышение устойчивости релизов;
- уменьшение зависимости от конкретного человека;
- сокращение повторяющихся инцидентов;
- улучшение диагностики и сопровождения.
Если такого эффекта нет, возможно, это не техдолг для бизнеса, а техническое предпочтение разработчика.
Как говорить с руководителем или заказчиком
Хорошая структура разговора выглядит так:
- Назвать участок. Где проблема?
- Показать симптом. Как она проявляется?
- Связать с бизнесом. Какой процесс или пользователи страдают?
- Описать риск. Что может случиться, если ничего не делать?
- Дать оценку. Сколько нужно времени?
- Предложить вариант. Что делаем сейчас, что можно отложить?
- Показать эффект. Что станет лучше после закрытия?
Пример:
“У нас есть техдолг в обмене с ЭДО. Сейчас ошибки обрабатываются плохо: при нестандартном ответе API пользователь видит общее сообщение, а разработчик ищет причину вручную. Это влияет на скорость обработки входящих документов и создает риск задержек. Предлагаю выделить 16 часов: добавить нормальное логирование, статусы ошибок и повторную обработку. Эффект — быстрее диагностика, меньше ручного разбора и ниже риск простоя загрузки”.
Такой разговор звучит совсем иначе, чем “дайте время на рефакторинг”.
Мини-шаблон описания техдолга
Можно использовать такой шаблон:
| Участок | Где находится проблема |
| Что сейчас не так | Симптом без лишних технических деталей |
| Кого затрагивает | Пользователи, отдел, процесс, команда сопровождения |
| Риск | Что может случиться |
| Цена бездействия | Что будет повторяться, дорожать или замедляться |
| Что предлагаем | Конкретное действие |
| Оценка | Время, сложность, ограничения |
| Ожидаемый эффект | Что станет лучше |
Если по техдолгу нельзя заполнить эту карточку, значит проблема либо недостаточно изучена, либо пока не готова к обсуждению с бизнесом.
Типовые ошибки при продаже техдолга
Ошибка 1. Давить техническим авторитетом
“Я разработчик, я знаю, что надо переписать”.
Может быть, и знаете. Но бизнесу нужно принять управленческое решение: на что потратить ограниченное время команды.
Лучше не давить авторитетом, а показать последствия.
Ошибка 2. Просить слишком много сразу
Если команда просит месяц на “разбор техдолга”, решение могут отложить.
Иногда лучше предложить маленький первый шаг:
- 8 часов на анализ;
- 16 часов на логирование;
- 1 день на реестр внешних обработок;
- 2 дня на оптимизацию самого тяжелого отчета;
- 1 релиз на закрытие одного критичного риска.
Ошибка 3. Не показывать эффект после исправления
Если техдолг закрыли, это нужно фиксировать.
Например:
- время отчета уменьшилось с 12 минут до 40 секунд;
- ошибка обмена теперь диагностируется за 5 минут, а не за 2 часа;
- после обновления проверка внешних обработок заняла 30 минут вместо дня;
- новый разработчик разобрался в участке за 2 часа, а не за 2 дня;
- количество повторяющихся обращений снизилось.
Без этого бизнес не видит, что инвестиция в техдолг сработала.
Главный вывод
Техдолг в 1С — это не про “разработчики хотят красивый код”.
Это про устойчивость системы, скорость изменений, стоимость сопровождения, риски релизов, зависимость от людей и качество работы пользователей.
Но чтобы бизнес это услышал, нужно перестать говорить только техническими словами.
Не “плохой код”, а “каждая следующая доработка будет дольше”.
Не “костыль”, а “риск сбоя при изменении процесса”.
Не “нужно переписать”, а “сейчас участок зависит от одного человека”.
Не “нет логирования”, а “при следующем инциденте мы снова потеряем часы на поиск причины”.
Не “надо рефакторить”, а “мы можем вложить 16 часов сейчас, чтобы снизить риск повторяющихся ошибок и ускорить будущие изменения”.
Технический долг начинают оплачивать не тогда, когда разработчик доказал, что код некрасивый. А тогда, когда команда показала, во что этот долг обходится бизнесу.
Поэтому задача 1С-специалиста — не только видеть техдолг, но и уметь переводить его на язык решений: риск, срок, деньги, зависимость, скорость и эффект.
Тогда разговор меняется.
Это уже не просьба “дать время на внутренние улучшения”.
Это нормальное управление устойчивостью 1С-системы.