Налог на хаос. Часть 3: закладки в коде, подписки на подрядчика и другие способы держать вас на крючке

В предыдущих частях серии «Налог на хаос» мы разобрали, почему без регламентов управляет подрядчик (часть 1) и где в 1С утекают реальные деньги (часть 2). Там речь шла о системных проблемах — размытые задачи, отсутствие приёмки, почасовка без границ.

Сегодня — о другом. О ситуации, когда проблемы в коде создаются намеренно.

Расскажу историю, которая происходит прямо сейчас — с одним из наших клиентов.

Компания сменила подрядчика по 1С. Причины стандартные: счета росли, сроки плыли, качество падало. Нашли нового, начали передачу. Первые недели — нормально. Новый подрядчик разбирается в базе, берёт задачи в работу.

А потом — через несколько недель после смены — «вдруг» перестаёт работать доработанный модуль. Просто перестаёт. Без обновлений, без изменений, без видимых причин.

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

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

Новый подрядчик — показал. Вот разница между работой в прозрачной среде и работой «на доверии».

Что это означает на практике? Компания вынуждена либо вернуться к старому подрядчику (который «знает, как починить»), либо платить новому за поиск и исправление чужих закладок. В обоих случаях — повторная оплата за то, что уже было оплачено.

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

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

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

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

У себя в ТГ канале t.me/itnihilist я пишу про подобные ситуации и рассказываю как их избежать.

Закладка с датой — самый грубый вариант. Но далеко не единственный способ заработать на заказчике больше, чем стоит честная работа. В 1С код конфигурации открытый — казалось бы, всё на виду. Но кто его читает? Бухгалтер — нет. Руководитель — нет. А выделенного ИТ-специалиста в большинстве компаний МСБ просто не существует.

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

Одна из самых распространённых и при этом неочевидных схем. Подрядчик разрабатывает «свой» отчёт по дебиторке, по оборотам, по остаткам — хотя типовой отчёт в конфигурации делает ровно то же самое. Иногда — буквально с теми же данными, только «в другом виде».

Что получает компания: счёт за разработку, потом счёт за доработку, потом счёт за поддержку. А типовой отчёт тем временем обновляется бесплатно с каждым релизом от 1С, поддерживает новые требования законодательства и не требует отдельного сопровождения.

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

Вместо того чтобы использовать расширения или аккуратные точечные доработки, подрядчик правит типовые объекты конфигурации напрямую. Модули, формы, регистры — всё изменено.

Пока подрядчик тот же — это незаметно. Но стоит выйти обновление от 1С (а они выходят регулярно — новые формы отчётности, изменения в законодательстве, исправления ошибок), и начинается кошмар. Десятки конфликтов при сравнении-объединении. Ручная работа на несколько дней. Риск потери данных. В итоге компания либо перестаёт обновляться — а это прямой путь к проблемам с отчётностью и безопасностью — либо платит за каждое обновление как за отдельный проект стоимостью 50–150 тысяч рублей.

Для подрядчика же испорченная конфигурация — это гарантированный контракт на годы вперёд. Никто другой не возьмётся обновлять этот «Франкенштейн».

Пароль от базы данных, от хранилища конфигурации, от сервера — только у подрядчика. При расторжении договора передавать их «забывают» или «не успевают».

Астрал, Контур, ЭДО, сертификаты электронной подписи — подрядчик при настройке оформляет всё на свой аккаунт и оплачивает со своего счёта (включая стоимость в свои счета клиенту, разумеется). Пока работаете вместе — незаметно. Но стоит расстаться — и выясняется, что доступ к сервису сдачи отчётности принадлежит не вам. Причём выясняется это, как правило, накануне отчётного периода. Быстро разобраться, как всё было настроено, перерегистрировать, оплатить, проверить — это дни и нервы. А отчётность ждать не будет.

Вся архитектура доработок — в голове одного человека. Код написан так, что разобраться может только автор: переменные названы бессмысленно, логика раскидана по модулям, комментариев нет. Другой программист потратит в 3–5 раз больше времени. Это не закладка, но эффект тот же — зависимость.

Для бухгалтера закладка в коде — это не абстрактная ИТ-проблема. Это конкретная ситуация: утро понедельника, нужно сформировать отчёт для руководства, а модуль не работает. Или конец квартала, а расчёт себестоимости выдаёт ошибку. Или акт сверки не формируется, потому что внешняя обработка «почему-то» перестала загружаться.

Бухгалтер не видит код. Бухгалтер видит результат: система, за которую компания заплатила, перестала работать. И срочно нужно исправлять — а значит, снова платить.

Именно бухгалтер первым замечает, что «что-то сломалось». Именно бухгалтер тратит своё рабочее время на переписку с подрядчиком. И именно бухгалтер вынужден объяснять руководству, почему отчёт не готов вовремя — хотя его вины здесь нет.

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

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

2. Сколько типовых отчётов вы заменили «своими»? Правильный ответ: ни одного, или минимум с обоснованием. Если подрядчик создал десяток «своих» отчётов — спросите, чем не устроили типовые. Часто ответа не будет.

3. Что произойдёт с системой, если мы расторгнем договор? Правильный ответ: ничего, всё продолжит работать. Если подрядчик мнётся, говорит «нужно обсудить», уходит от прямого ответа — это сигнал.

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

Если на два или более вопроса вы получили уклончивые ответы — ситуация требует внимания.

Защита не требует технических знаний. Она требует управленческих решений.

Зафиксируйте в договоре передачу всех доработок: расширения, внешние обработки, изменения конфигурации. Не «по запросу», не «после завершения проекта» — а регулярно, после каждой принятой задачи. Доработки — это актив компании, как и любая другая оплаченная работа.

Требуйте обоснования каждой доработки. Прежде чем подрядчик начнёт писать «свой» отчёт — спросите: «А типовой это не умеет?» Часто оказывается, что умеет. Просто подрядчику выгоднее написать новый и потом его поддерживать.

Запретите правку типовой конфигурации без согласования. Все доработки — через расширения. Если подрядчик говорит, что без правки типовых объектов никак — пусть обоснует письменно. Каждое изменение типовой конфигурации = удорожание каждого будущего обновления.

Проводите ревизию кода. Раз в полгода — привлекайте независимого специалиста для проверки. Это стоит 20–50 тысяч рублей и занимает 1–3 дня. Для сравнения: обнаружение закладки после её срабатывания стоит в разы больше — и в деньгах, и во времени простоя.

Храните всё у себя. База, конфигурация, внешние обработки, хранилище конфигурации — на ваших ресурсах. Пароли — в вашем менеджере паролей, а не в голове подрядчика.

Проверяйте обновляемость. Раз в квартал спрашивайте: «Мы можем обновить конфигурацию до актуального релиза? Сколько это займёт?» Если ответ «2–3 дня» — нормально. Если «неделю и 150 тысяч» — конфигурацию уже испортили.

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

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

А если ничего из этого нет — вы можете узнать о проблеме только когда она уже произойдёт. Как это произошло у нашего клиента.

Чек-лист: защита от зависимости (распечатайте и проверьте)

Если 3+ пункта — «нет», пора менять правила игры.

Предыдущие части серии:

• Часть 1: Налог на хаос — сколько стоит отсутствие регламентов

• Часть 2: Где в 1С утекают реальные деньги

Столкнулись с похожей ситуацией? Нашли закладку в коде? Расскажите в комментариях — разберём вместе.