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

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

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

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

Почему оценка задач 1С часто ошибается

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

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

Третья причина — оценка только «чистого кодирования». В реальную задачу входят анализ, согласование, тестирование, исправление замечаний, обновление рабочей базы и иногда обучение пользователей. Если оценивать только написание кода, недооценка составит 30–50%.

Шаг первый: уточнение требований до оценки

Не давайте оценку по одной строке из мессенджера. Минимальный набор вопросов перед оценкой: какой результат нужен пользователю (не «что сделать», а «что должно работать»), в какой конфигурации и релизе это делать, сколько пользователей затронуто, есть ли сроки и ограничения, кто будет принимать работу.

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

Если требования расплывчаты и уточнить их невозможно, давайте оценку вилкой с явно прописанными допущениями: «4–8 часов при условии, что макет предоставляет заказчик и доработка не затрагивает обмен данными». Это честнее, чем точная цифра, взятая с потолка.

Методы оценки: что использовать на практике

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

Декомпозиция

Задача разбивается на подзадачи по 1–8 часов, каждая оценивается отдельно, результаты суммируются. Это самый надёжный метод для задач среднего и крупного размера: ошибки в мелких частях частично компенсируют друг друга, а сама разбивка выявляет забытые работы.

Оценка по аналогии

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

Оценка вилкой (оптимистичная / реалистичная / пессимистичная)

Оцените задачу тремя числами: если всё пойдёт идеально, если как обычно, если вылезут проблемы. Для заказчика называйте реалистичную оценку с резервом, пессимистичную держите как внутренний ориентир. Разрыв между оптимистичной и пессимистичной оценкой показывает уровень неопределённости: если он больше чем в два раза — требования нужно уточнять, а не оценивать.

Какой метод когда применять

Декомпозиция

Задачи от 8 часов и крупные доработки. Требует времени на разбивку, но даёт самую точную оценку

Аналогия

Повторяющиеся задачи: отчёты, печатные формы, типовые обработки. Не работает без учёта фактических трудозатрат

Вилка

Размытые требования и новые области. Честно показывает неопределённость, но заказчику нужно объяснять, что означает диапазон

Типовая структура оценки задачи по 1С

Для регулярности полезно оценивать любую задачу по одному шаблону. Это дисциплинирует и не даёт забыть «невидимые» работы.

1. Анализ требований и изучение конфигурации: сколько времени уйдёт, чтобы понять, что и где менять.
2. Разработка: объекты метаданных, код, запросы, формы, макеты.
3. Самопроверка и тестирование на копии базы, включая граничные случаи (пустые данные, большие объёмы, права).
4. Исправление замечаний после показа заказчику — заложите минимум одну итерацию.
5. Обновление рабочей базы: подготовка поставки или расширения, контроль обновления, возможная обработка данных.
6. Документация и передача: краткое описание для пользователя или администратора.

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

1. 1
   Уточните сценарий использования и критерии приёмки у заказчика
2. 2
   Откройте конфигуратор и посмотрите затрагиваемые объекты, расширения, обмены
3. 3
   Разложите работу на подзадачи по 1–8 часов и оцените каждую
4. 4
   Добавьте тестирование, итерацию правок и обновление рабочей базы
5. 5
   Добавьте резерв на риски 20–40% в зависимости от неопределённости
6. 6
   Зафиксируйте оценку письменно с допущениями и вилкой

Как учитывать риски и специфику 1С

Резерв на риски — не «накидка для наглости», а плата за неопределённость. Его размер зависит от конкретных факторов, а не от настроения.

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

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

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

Формат фиксации оценки и защита от перерасхода

Оценка, сказанная устно, юридически и практически ничего не стоит. Фиксируйте в письменном виде: объём работ (что входит и что не входит), оценку в часах или днях, допущения, условия пересмотра.

Ключевой пункт — условия пересмотра. Например: «оценка действительна при неизменных требованиях; новые требования оцениваются отдельно». Без этого любая мелкая просьба «а ещё добавьте колонку» превращается в бесплатную работу, а итоговый перерасход — в вашу вину.

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

Как проверять точность оценок и улучшать их

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

Разбирайте расхождения больше 30%: что именно не учли? Если регулярно недооцениваете тестирование — увеличьте норматив. Если регулярно «съедают» правки заказчика — ужесточите фиксацию требований или закладывайте две итерации вместо одной. Систематическая ошибка исправляется системно, а не героическими переработками.

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

Контрольные точки

Как проверить качество своей оценки

Структура оценки

Норма

Есть разбивка по этапам, включая тестирование и обновление

Тревожный признак

Одно число без расшифровки

Допущения

Норма

Письменно зафиксированы условия и что не входит в оценку

Тревожный признак

Допущения только в голове исполнителя

Факт против плана

Норма

Отклонение по портфелю задач близко к нулю

Тревожный признак

Систематический перерасход или недобор больше 20–30%

Реакция на новые требования

Норма

Есть процедура переоценки, заказчик её знает

Тревожный признак

Новые требования молча добавляются в старую оценку

FAQ

Как оценить задачу, если требования совсем размыты?

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

Сколько закладывать на тестирование?

Ориентир — 20–30% от времени разработки для типовых доработок. Для задач, затрагивающих обмены, проведение документов или большие объёмы данных, закладывайте больше: там выше вероятность найти проблемы именно на этапе проверки.

Что делать, если заказчик торгуется и просит срезать оценку?

Сокращайте объём работ, а не цену за тот же объём: уберите часть требований, упростите сценарий, перенесите часть функций на следующий этап. Срезанная «в столбик» оценка превращается в ваши неоплаченные переработки.

Как оценивать задачи в чужой доработанной конфигурации?

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

Нужен ли резерв на риски в мелких задачах на 1–2 часа?

Явный резерв обычно не нужен, но полезно правило минимальной оценки: даже «пятиминутная» правка включает запуск конфигуратора, проверку и обновление, поэтому минимальный биллинг обычно начинается с 30–60 минут. Это честнее, чем дробить время на минуты.

Как объяснить заказчику, почему «простая кнопка» стоит дорого?

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