Оценка трудозатрат на доработки в 1С: от правки печатной формы до интеграции
Содержание
Оценить задачу в 1С — значит назвать срок и трудозатраты, которые выдержат встречу с реальностью. Рабочая схема такая: разбить задачу на кусочки по 2–8 часов, оценить каждый тремя числами (оптимистично, реалистично, пессимистично), сложить и добавить запас 15–30% на риски. Одна цифра «на глаз» почти всегда ошибается в меньшую сторону.
Оценка задач в 1С ломается не потому, что программисты плохо считают. Задача в начале выглядит как «добавить поле в отчёт», а в конце оказывается правкой регистра, обновлением типовой конфигурации и согласованием с тремя отделами. Ниже — как этого избежать: методы, инструменты, примеры с числами.
Почему оценка задач в 1С так часто промахивается
Причины повторяются от проекта к проекту. Их полезно знать, чтобы закладывать поправку заранее.
- 🧩 Размытое требование. «Сделайте удобнее» нельзя оценить. Оценивается только то, что можно проверить: «в форме документа появляется кнопка, которая заполняет табличную часть из выбранного файла».
- 🔍 Скрытая сложность типовой конфигурации. Видимая правка в одной форме тянет за собой обработчики, права, подписки на события, отчёты.
- 👥 Чужие данные. Реальная база отличается от демо: нестандартные реквизиты, дубли в справочниках, исторические «костыли».
- ⏳ Ожидания. Согласования, доступы к базе, тестовые данные, ответы заказчика — это часы и дни, которые в оценку разработчика обычно не входят.
- 🧠 Оптимизм. Человек оценивает идеальный сценарий, где всё сработало с первого раза. Отладки, пересборки и повторных тестов в этом сценарии нет.
Хорошая привычка: в конце каждой задачи записывайте факт рядом с оценкой. Через 20–30 задач у вас будет собственный коэффициент ошибки, и он точнее любых методик.
Что выяснить до того, как называть цифру
Оценка без вводных — гадание. Перед тем как отвечать «сколько это займёт», задайте несколько вопросов.
- Результат. Как заказчик поймёт, что задача сделана? Нужен проверяемый критерий приёмки.
- Платформа и конфигурация. Какая конфигурация, какой релиз, типовая она или уже изменена. Если поддержка снята с части объектов, любое обновление потом потребует ручного слияния.
- Среда. Есть ли тестовая копия базы, или проверять придётся на рабочей. Размер базы и время загрузки копии тоже считаются.
- Объём данных. Сколько строк в документе, сколько документов в месяц. Алгоритм, который хорош на сотне строк, на ста тысячах может не пережить запроса.
- Заинтересованные стороны. Кто принимает работу и кто может изменить требования по ходу.
- Сроки. Это срок «когда нужно» или «когда реально»? Это разные задачи оценки.
Если на половину вопросов ответа нет, честная первая оценка — это не число, а диапазон с пометкой «после уточнения требований уточню». Заказчики такое принимают лучше, чем цифру, которую придётся менять через неделю.
Методики оценки: от «на глаз» до покер-планирования
Выбор метода зависит от того, насколько задача понятна и сколько времени есть на оценку.
| Метод | Когда применять | Риски |
|---|---|---|
| Экспертная («на глаз») | Мелкие правки, привычная область, нужен быстрый ответ | Сильно зависит от опыта и настроения; не проверяется |
| Аналогия | Есть похожая выполненная задача | Скрытые отличия: «почти то же» оказывается другим |
| Декомпозиция (по работам) | Средние и крупные задачи | Можно забыть этап; много мелочей — ложное чувство точности |
| Трёхточечная (PERT) | Есть неопределённость, важен учёт риска | Требует честных пессимистичных значений |
| Покер-планирование | Команда из 3+ человек, спорные оценки | Тратится время команды; на мелочах не нужно |
Декомпозиция
Разбейте задачу на кусочки так, чтобы каждый укладывался в 2–8 часов. Всё, что больше, — ещё раз делите. Типовой набор этапов для доработки:
- анализ и уточнение требований;
- проектирование (где в конфигурации будут жить изменения);
- разработка;
- самопроверка и отладка;
- тестирование с участием заказчика;
- перенос в рабочую базу и сопровождение первых дней;
- описание изменений для пользователей и следующего программиста.
Самый часто забываемый пункт — перенос и сопровождение. На практике это 10–15% от разработки.
Трёхточечная оценка
Для каждого кусочка называете три числа: O (оптимистичная), M (реалистичная), P (пессимистичная). Расчёт по формуле (O + 4×M + P) / 6.
Пример. Нужно написать загрузку номенклатуры из Excel:
- O = 8 часов (файл чистый, формат фиксирован);
- M = 12 часов (будут пустые значения и дубли);
- P = 24 часа (формат файла придётся уточнять с поставщиком, структура нестабильна).
Расчёт: (8 + 4×12 + 24) / 6 = 80 / 6 ≈ 13,3 часа. Заметьте: итог выше реалистичной оценки. Это и есть учёт неопределённости.
Покер-планирование
Команда оценивает задачу не вслух, а карточками: каждый одновременно показывает свою оценку (часто используют ряд 1, 2, 3, 5, 8, 13). Если разброс большой, самый низкий и самый высокий объясняют, почему так. Обычно выясняется, что один знает про подводный камень, о котором второй не думал. После обсуждения повторяют круг.
Это не про точность, а про выявление скрытых допущений. Для одиночного программиста метод бесполезен, но его можно заменить вопросом себе: «что может пойти не так, чего я сейчас не учитываю?».
Инструменты для оценки трудозатрат в 1С
Специального «калькулятора оценок 1С» не существует, и это нормально. Оценке нужны три вещи: место, где хранится история, способ разбиения и источник фактических данных.
- 📊 Таблица. Обычный лист с колонками «задача / O / M / P / расчёт / факт / комментарий». Самый недооценённый инструмент: простой, прозрачный, его видит заказчик.
- 🗂 Трекер задач. Подойдёт любой, где у задачи есть поле «оценка» и «затрачено». Главное — вносить факт сразу, а не по памяти в конце месяца.
- 🕒 Учёт времени. В самой 1С для этого годятся конфигурации управления проектами или подсистемы учёта рабочего времени, если они у вас стоят. Для небольшой команды хватит трекера.
- 🔬 Анализ готовой базы. Конфигуратор помогает прикинуть объём: сравнение и объединение конфигураций показывает, сколько объектов изменено, а «Поиск ссылок на объект» — сколько мест затронет правка.
- 📝 Шаблон оценки. Список этапов, которые нужно пройти по каждой задаче. Тогда вы не забудете тестирование и перенос.
Если вы оцениваете чужую базу по описанию, не смотря в неё, добавляйте к итогу отдельную строку «изучение базы» — 2–6 часов, в зависимости от размера доработок.
Оценка задач с интеграциями и обменами
Интеграция — самый частый источник срыва сроков. Причина проста: половина работы находится вне вашей базы.
Что обязательно входит в оценку:
- 🔌 Изучение второй стороны. Документация к API или формату файла, тестовый стенд, доступы. Если документации нет, закладывайте время на реверс: смотреть реальные примеры сообщений.
- 🗺 Сопоставление данных. Какое поле откуда берётся и как сопоставляются справочники. Сопоставление номенклатуры, контрагентов, единиц измерения часто занимает больше, чем сам обмен.
- 🔁 Обработка ошибок и повторы. Что делать, если вторая система не ответила, вернула ошибку, прислала дубль. Без этого интеграция работает только в хорошую погоду.
- 🧪 Тестирование на реальных данных. Минимум один прогон на выборке, похожей на боевую.
- 🛠 Эксплуатация. Журнал обмена, уведомления о сбоях, инструкция для пользователя.
Пример прикидки обмена с внешней системой по «простому» сценарию (выгрузка заказов):
| Этап | Часы |
|---|---|
| Изучение формата и согласование полей | 6 |
| Разработка выгрузки | 12 |
| Обработка ошибок и повторов | 6 |
| Тестирование на реальных данных | 6 |
| Перенос и первые дни сопровождения | 4 |
| Итого | 34 |
Сумма: 6 + 12 + 6 + 6 + 4 = 34 часа. Если формат второй стороны неизвестен, к строке «изучение» добавляйте пессимистичный вариант в 2–3 раза больше.
Типовое и нетиповое решение: как меняется оценка
Правило простое: настройка типового механизма стоит дешевле, чем его переписывание. Но у «типового» есть своя цена.
Настройка без программирования. Если задача решается штатными средствами — настройкой прав, дополнительными реквизитами, сведениями, произвольными отчётами, — оценка короткая и предсказуемая. Спросите себя: можно ли решить без разработки? Часто можно, и это самый дешёвый путь.
Доработка в рамках расширения. Изменения выносятся в расширение конфигурации , основная остаётся на поддержке. Разработка может быть чуть дороже, зато обновления типовой пройдут проще, а значит, снижаются будущие затраты на сопровождение. Закладывайте дополнительное время на проверку поведения расширения после обновлений.
Изменение конфигурации «в лоб». Быстрее сегодня, дороже потом: при каждом обновлении придётся объединять изменения вручную. Если решаете так, в оценку добавляйте сопровождение: например, 2–4 часа на каждое обновление релиза.
Нетиповая конфигурация или сильно изменённая. Здесь верните коэффициент неопределённости: оценка по аналогии с типовой не работает . Начните с короткой разведки и оценивайте после неё.
При выборе между вариантами показывайте заказчику сравнение: срок сейчас и затраты на сопровождение через год. Тогда решение принимает он, а не вы по умолчанию.
Как учитывать риски и запас в оценке
Запас — не «подушка безопасности на всякий случай», а явная часть оценки с понятной логикой.
Что считать риском
- зависимость от третьих лиц (доступы, ответы, документация);
- неясные или меняющиеся требования;
- незнакомая технология или конфигурация;
- большой объём данных и вопросы производительности;
- сжатые сроки: чем меньше времени, тем выше вероятность ошибки.
Как посчитать запас
Простой и честный подход — процент от суммы по уровню неопределённости:
| Ситуация | Запас |
|---|---|
| Всё понятно, похожая задача уже делалась | 10–15% |
| Есть вопросы по требованиям или данным | 20–30% |
| Интеграция, чужая система, незнакомая область | 30–50% |
Пример. Доработка печатной формы с учётом данных из нового реквизита:
- анализ — 4 часа;
- разработка — 12;
- тестирование с заказчиком — 4;
- описание изменений — 2;
- перенос и обкатка — 3.
Сумма: 4 + 12 + 4 + 2 + 3 = 25 часов. Требования уточнялись по ходу, берём запас 20%: 25 × 0,2 = 5 часов. Итого заказчику называем 30 часов.
Не прячьте запас внутри кусочков — показывайте его отдельной строкой. Тогда заказчик видит, за что платит, а вы не оказываетесь в положении «почему у вас всё всегда дороже».
Частые ошибки при оценке задач в 1С
Часть ошибок уже встречалась выше. Здесь — то, что не вошло в разбор методов.
- 🙈 Оценка по памяти. Если «примерно помню, что делал похожее», проверьте фактические часы по тому проекту. Память почти всегда занижает.
- 🎯 Единая цифра вместо диапазона. Любая единственная цифра воспринимается заказчиком как обещание. Диапазон с условиями честнее.
- 🤝 Оценка под желание заказчика. Если срок «сверху» нереалистичен, правильнее урезать объём, а не сжимать оценку.
- 🔄 Нет пересмотра. Требования поменялись — оценка тоже должна. Договоритесь заранее, что изменения фиксируются и оцениваются отдельно.
- 📉 Игнорирование собственной скорости. Новичок и опытный программист оценивают одну и ту же задачу по-разному. Оценку делает тот, кто будет её выполнять, либо вводится поправка.
- 🧱 Забытые мелочи. Обновление типовых отчётов после изменения структуры, права доступа для новых объектов, миграция исторических данных.