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

📋 Шаг 1. Сформулируйте проблему, а не решение

Самая частая ошибка — прийти к программисту с готовым техническим решением вместо описания бизнес-задачи. «Сделайте кнопку, которая...» — плохо. «Менеджеры тратят 2 часа в день на ручной перенос данных из Excel в 1С — нужно это автоматизировать» — хорошо.

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

📝 Шаг 2. Составьте ТЗ (или попросите помочь)

Техническое задание — это защита обеих сторон. Не нужно писать 50-страничный документ. Достаточно зафиксировать:

• Что должно быть на входе — откуда берутся данные, кто запускает процесс
• Что должно быть на выходе — конкретный результат, форма, отчёт, кнопка
• Исключения и граничные случаи — что делать, если нет данных, если ошибка
• Критерии приёмки — как вы будете проверять, что всё работает

Если затрудняетесь — нормальный разработчик поможет составить ТЗ. Это часть диагностики задачи.

🔍 Шаг 3. Выберите подрядчика

На что смотреть при выборе программиста 1С для доработки:

• Задаёт уточняющие вопросы до оценки, а не сразу называет цену
• Предлагает работать на копии базы, а не в боевой
• Готов подписать договор или хотя бы фиксирует ТЗ письменно
• Объясняет, почему выбирает расширение или прямую доработку конфигурации
• Может показать примеры похожих работ

Красные флаги: работает без ТЗ, не объясняет что делает, просит доступ сразу к продуктивной базе, не тестирует на тестовых данных.

💰 Шаг 4. Зафиксируйте цену и сроки

Два варианта договорённости:

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

В любом случае согласуйте предоплату (обычно 30–50%), сроки сдачи и порядок исправления замечаний.

🧪 Шаг 5. Организуйте тестирование

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

• Стандартный рабочий сценарий — работает ли основной кейс
• Граничные случаи — пустые значения, нулевые суммы, документы без строк
• Нагрузочный сценарий — как ведёт себя на большом объёме данных
• Сценарий ошибки — что происходит, если что-то пошло не так

🚀 Шаг 6. Запуск и гарантия

После приёмки убедитесь, что у вас есть:

• Описание того, что сделано и как это работает
• Понимание, как включить/выключить функцию при необходимости
• Договорённость о гарантийном периоде (обычно 1 месяц)
• Резервная копия базы до внедрения — на случай отката

✅ Итоговый чек-лист