1c-estimation

Оценка трудозатрат и проверка ЧТЗ

Локализация (сначала, если есть)

Если в скилле есть каталог references/local/ — прочитай его ПЕРЕД работой: version-stack.md, ролевые корзины оценки своей компании (estimation-buckets.md), шкала размеров и множители коэффициента готовности (estimation-scale.md), источник данных для аналогов (analogues-source.md), где ведётся реестр замечаний (remarks-registry.md). При противоречии локальное побеждает generic. Контракт — docs/SKILL_LOCALIZATION.md toolkit.

Роль этого скилла — не писать ЧТЗ (это 1c-analyst) и не писать код (это 1c-dev), а ответить на два смежных вопроса: «готовы ли мы честно оценить эту задачу» и «сколько это будет стоить с учётом похожих задач, которые уже сделаны». Оценка — не изолированное число, а суждение, опирающееся на конкретные документы и конкретные прецеденты; если их нет — оценки тоже нет, есть только гипотеза.

Железное правило 1 — без артефактов не оцениваем вслепую

Глубина требуемых артефактов зависит от размера/риска задачи (см. document-frames.md скилла 1c-analyst: рамки brief/requirements/tech-design). Прежде чем дать число:

1. Определи размер задачи (S/M/L/XL) и по нему — какие рамки обязательны.
2. Проверь, что обязательные артефакты СУЩЕСТВУЮТ и удовлетворяют своему acceptance (не просто «есть файл», а «файл закрывает критерии готовности своей рамки»).
3. Артефакта нет или он не проходит acceptance → НЕ оценивай по названию задачи. Явно скажи, чего не хватает («нет паспорта — не видно границ и критериев приёмки бизнеса», «ЧТЗ без логической модели данных — нельзя оценить объём доработки данных»), и предложи получить это, а не подставляй усреднённую догадку вместо отсутствующего входа.
4. Исключение — предварительная (грубая, вилочная) оценка на этапе паспорта: она ЯВНО помечается как предварительная, с широким диапазоном, и не заменяет уточнённую оценку после ЧТЗ.

Железное правило 2 — оценка по аналогии, не сумма придуманных атомов

• Основание оценки — РЕАЛЬНЫЕ похожие задачи, уже закрытые (тот же контур/тип доработки/размер), а не декомпозиция на воображаемые подзадачи с придуманными часами на каждую. Декомпозиция здесь нужна для ПОЛНОТЫ («не забыли ли кусок объёма», для крупной задачи — минимальный полезный результат + Must/Should/Could/Won't), а не как арифметика оценки.
• Вилку вокруг аналога показывай через PERT (optimistic/most likely/pessimistic → (O+4M+P)/6) и коэффициент готовности входа (сырое описание — не «задача больше», а «выше неопределённость»). Если аналогов нет — веди чистым PERT с расширенной вилкой, но так и скажи. Подробности — references/estimation-by-analogy.md.
• Если роли в вашем процессе реально разделены (аналитик/тех-лид/разработчик/тестирование/… — состав корзин задаёт локализация компании) — раздели оценку по корзинам, а не одной суммой: разные роли имеют разную историю аналогов и разную точность. Роль, чьё участие нужно, но не оценивается в часах на этой стадии — флагом, не нулевой строкой. Если работаешь один или локализации ролей нет — одна корзина «моя работа» нормальна, не выдумывай чужое разделение труда там, где его нет.
• Оценка, данная до полного ЧТЗ, замораживается в рамках зафиксированных границ. Появление подробного ЧТЗ само по себе не повод пересчитывать — требования стали подробнее внутри тех же границ (для этого и коэффициент). Пересматривать — только если реально ИЗМЕНИЛСЯ ОБЪЁМ (новый сценарий/интеграция/роль/границы/риск, которых не было на момент оценки). Разделяй эти два случая явно, не растягивай молча.