Как контролировать работу программиста 1С: постановка задач, приемка и оценка результата

Контроль работы программиста 1С часто сводят к количеству отработанных часов и закрытых задач. Но эти показатели мало говорят о качестве разработки. Разработчик может быстро закрывать задачи, оставляя ошибки. Или тратить больше времени, потому что разбирается в сложной архитектуре и предотвращает будущие проблемы. Поэтому оценивать работу стоит по трем направлениям.

Например, программисту поручили ускорить отчет в 1С. Он потратил 12 часов вместо запланированных 8, но сократил время формирования отчета с 90 до 8 секунд, сохранив корректность данных. Формально оценка превышена. Однако задача принесла бизнесу ожидаемый результат. И наоборот: если программист уложился в 8 часов, но ускорил отчет за счет исключения части данных, такую работу нельзя считать качественной.

Главный принцип — контролировать не количество действий программиста, а соответствие результата согласованным требованиям.

Качество разработки во многом зависит от постановки задачи. Например, руководитель пишет в рабочем чате: «Нужно поправить отчет по продажам, сейчас данные отображаются неправильно».

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

Для небольших доработок необязательно составлять многостраничное техническое задание программисту 1С. Достаточно карточки в Jira, YouTrack, Битрикс24 или другой системе управления задачами.

Что должно быть в задаче:

1. Проблема. Что сейчас работает неправильно или чего не хватает пользователям.
2. Ожидаемый результат. Что должно измениться после доработки.
3. Контекст. В какой конфигурации и бизнес-процессе требуется изменение.
4. Условия и исключения. Какие данные учитывать, какие ситуации обрабатывать.
5. Критерии приемки. Как проверить, что задача выполнена правильно.
6. Ответственный. Кто будет принимать результат.

Пример постановки задачи программисту 1С

Ситуация: руководитель отдела продаж хочет видеть в 1С заказы, по которым нарушены сроки отгрузки.

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

Хорошая постановка:

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

Практический совет: создайте единый шаблон постановки задач. Это сократит количество уточнений и упростит приемку доработок.

Контроль сроков начинается с оценки задачи. Важно разделять два показателя:

• Трудоемкость — сколько рабочих часов потребуется программисту.
• Дата завершения — когда результат будет передан на проверку с учетом загрузки и зависимостей.

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

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

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

Удобнее всего вести учет задач программиста 1С в едином трекере со статусами:
К оценке → В работе → На технической проверке → На приемке → Принята.

Если разработчик работает на почасовой оплате, фиксируйте время по конкретным задачам. Вместо записи «Программирование — 10 часов» лучше указывать выполненные работы: анализ алгоритма — 2 часа, разработка — 5 часов, тестирование — 3 часа.

Для небольших задач достаточно обновления статуса при переходе между этапами. Для длительных работ полезен короткий ежедневный отчет: что сделано, что осталось и есть ли препятствия.

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

Если программист не укладывается в оценку, попросите объяснить:

• Что уже сделано и что можно проверить?
• Почему изменилась оценка?
• Сколько работы осталось?
• Когда будет готов результат?

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

Руководителю необязательно самостоятельно анализировать программный код. Важно разделить функциональную и техническую проверку. Функциональная проверка показывает, решена ли бизнес-задача. Ее может провести руководитель, аналитик или пользователь. Техническая проверка позволяет выявить ошибки реализации, проблемы с производительностью и риски для дальнейшего сопровождения. Ее должен выполнять квалифицированный 1С-специалист.

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

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

Также необходимо убедиться, что изменение не нарушило связанные механизмы. Например, доработка проведения документа реализации может повлиять на остатки, взаиморасчеты и отчеты. Такая проверка называется регрессионным тестированием.

Если вы не читаете код 1С, попросите разработчика или технического руководителя ответить на вопросы:

• Какие объекты конфигурации изменены?
• Повлияют ли изменения на обновление типовой конфигурации?
• Проверены ли права доступа и обработка ошибок?
• Выполнялась ли проверка кода и кто ее проводил?
• Как отменить изменения при возникновении проблем?

Для контроля кода можно использовать 1C Development Tools (EDT), Git и другие инструменты разработки. Для критичных изменений в 1С, 1С:УХ и других сложных конфигурациях желательно привлекать ведущего разработчика или архитектора для независимой проверки.

Статус «Выполнено» в системе задач еще не означает, что заказчик получил качественный результат. Приемка должна подтверждать соответствие доработки согласованным требованиям.

Чек-лист приемки доработки 1С:

1. Реализованы все согласованные требования.
2. Проверены основные и исключительные сценарии.
3. Результаты расчетов и обработки данных корректны.
4. Проверены необходимые права доступа.
5. Изменения не нарушили связанные процессы.
6. Производительность соответствует требованиям, если они предусмотрены.
7. Выполнена необходимая техническая проверка.
8. Известен порядок установки и отмены изменений.
9. Заказчик подтвердил результат.

Для небольшой доработки печатной формы проверка может занимать несколько минут. Для изменения алгоритмов учета или интеграции потребуется более тщательное тестирование.

Кто должен принимать результат:

Если обнаружена ошибка, фиксируйте конкретный сценарий, фактический и ожидаемый результат. Например: «В отчете по заказу № 154 отображается 100 шт. вместо неотгруженного остатка 30 шт.». Также важно отделять дефекты от новых пожеланий заказчика. Если после согласования задачи потребовалась дополнительная функциональность, ее следует оценивать отдельно.

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

Например, за месяц программист завершил 14 задач: 11 приняли с первого раза, 3 вернули на исправление, 12 выполнены в согласованный срок. Эти данные помогают увидеть проблемные места. Но оценивать специалиста лучше в динамике за несколько месяцев, учитывая сложность задач и причины отклонений.

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

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

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

При аутстаффинге компания управляет задачами и принимает результат самостоятельно, а поставщик предоставляет специалиста в рамках договора.

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

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

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