Как проверить качество доработки 1С: чек-лист для директора

Если всё было «на словах» — у вас нет основания для претензий при несоответствии. Хорошая доработка всегда имеет письменно согласованный объём работ.

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

Хороший программист делает backup перед любыми изменениями. Спросите: «Когда вы делали копию и где она хранится?»

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

Создайте тестовый документ/запись и проверьте, что функция работает так, как описано в ТЗ. Не просто «открывается» — а выполняет нужное действие от начала до конца.

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

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

После доработки поработайте в базе как обычно 1–2 дня. Если возникли новые ошибки в не связанных местах — доработка затронула что-то лишнее.

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

Хорошие доработки управляемы. Плохие — намертво вшиты в логику и «выключить» их без риска сломать всё остальное нельзя.

Хороший ответ: «Вот документация, вот где лежит код». Плохой: «Только я знаю, как это работает».

Если программист использует Git или хранилище конфигурации — вы можете видеть все изменения с комментариями. Это признак профессиональной работы.