1c Estimation

---
name: 1c-estimation
description: >
  Оценка трудозатрат задачи 1С и проверка ЧТЗ перед оценкой/разработкой: чего не хватает, чтобы
  оценивать честно, оценка по аналогии на реальных закрытых задачах (не сумма придуманных
  атомов), проверка ЧТЗ тех-лидом по рамке требований и работа со списком замечаний (что именно
  вписать в замечание, чтобы оно было конкретным и проверяемым). ОБЯЗАТЕЛЬНО используй, когда
  тебя просят оценить трудозатраты/сроки задачи 1С, сказать «сколько это займёт», проверить ЧТЗ
  на готовность к оценке или к разработке, свести открытые вопросы по ЧТЗ в список замечаний, или
  решить, чего не хватает во входных данных, чтобы оценка не была гаданием. Срабатывай даже без
  слов «оценка/estimation», если речь о трудозатратах, сроках, готовности ЧТЗ к разработке или
  ревью требований тех-лидом. Главное правило: без нужных для размера задачи артефактов (паспорт/
  ЧТЗ) не оценивать вслепую — назвать, чего не хватает; оценка — по аналогии на РЕАЛЬНЫХ похожих
  задачах, а не сумма изобретённых атомов; исторические данные о факт-часах использовать только
  после проверки их полноты/непрерывности. Подготовка самих документов (паспорт/ЧТЗ/тех-проект) —
  скилл `1c-analyst`; реализация — `1c-dev`.
---

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

## Локализация (сначала, если есть)
Если в скилле есть каталог `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`.
- **Если роли в вашем процессе реально разделены** (аналитик/тех-лид/разработчик/тестирование/… —
  состав корзин задаёт локализация компании) — раздели оценку по корзинам, а не одной суммой:
  разные роли имеют разную историю аналогов и разную точность. Роль, чьё участие нужно, но не
  оценивается в часах на этой стадии — флагом, не нулевой строкой. **Если работаешь один или
  локализации ролей нет** — одна корзина «моя работа» нормальна, не выдумывай чужое разделение
  труда там, где его нет.
- **Оценка, данная до полного ЧТЗ, замораживается в рамках зафиксированных границ.** Появление
  подробного ЧТЗ само по себе не повод пересчитывать — требования стали подробнее внутри тех же
  границ (для этого и коэффициент). Пересматривать — только если реально ИЗМЕНИЛСЯ ОБЪЁМ (новый
  сценарий/интеграция/роль/границы/риск, которых не было на момент оценки). Разделяй эти два случая
  явно, не растягивай молча.

## Железное правило 3 — гейт качества исторических данных
Прежде чем опереться на исторические «факт-часы» аналогов как на основание оценки — проверь ГЛУБИНУ
и НЕПРЕРЫВНОСТЬ их учёта, а не только их наличие:
- Короткий период регулярного учёта (тем более если он начался недавно) — недостаточная выборка;
  аналоги ДО начала регулярного учёта могут быть неполными (не все часы зафиксированы) и занижать
  оценку, если их взять как есть.
- Разнородный по времени учёт (часть периода фиксировалась исправно, часть — нет) — не усредняй по
  всему периоду молча; либо ограничься надёжным окном, либо явно пометь оценку как менее уверенную.
- Итог гейта — не блокер сам по себе, а ОБЯЗАТЕЛЬНАЯ строка в выдаваемой оценке: на чём основана
  уверенность (глубина/качество истории), а не только сама цифра. Скрытая от заказчика оценки
  неопределённость хуже честно названного широкого диапазона.

## Проверка ЧТЗ тех-лидом и список замечаний
Полный протокол — `references/chtz-review-and-remarks.md`: определить тип документа (новый
функционал/изменение/расширение/перенос/интеграция/техзадача/инцидент), пройти рамку требований,
дать вывод СРАЗУ по нескольким осям (годится подтвердить предыдущую оценку / годится для
технической проработки / годится для входа в разработку — не один общий вердикт), и — железно —
**не заявлять пробел, не поискав его в тексте документа** («нет в реализации» ≠ «нет в
требованиях» — если это уже описано, но не реализовано, это задача разработки, а не замечание
автору). Отдельно — проверка на ТИХОЕ расхождение с более ранним документом по той же задаче (то
же правило описано другим условием, а не другим объёмом). Замечание — структура (где / что не так
/ что будет, если не закрыть / чем закрывается дословно / кто закрывает / где решается), один
владелец на замечание, термины документа — дословно, не своими словами.

## Роли-корзины оценки
Состав и число корзин (аналитик/тех-лид/разработчик/тестирование/поддержка/…) — данные локализации
компании (`references/local/estimation-buckets.md`), не часть ядра: разные организации делят труд
по-разному. Если у тебя есть такой файл (команда с разделением ролей) — оценка и обоснование даются
ПО КОРЗИНЕ, не одной суммой, общая цифра прячет узкое место в конкретной роли. **Если файла нет или
работаешь один** (соло-разработчик, нет разделения на аналитика/тех-лида/тестировщика) — правило не
про то, чтобы выдумать роли, которых нет: одна корзина «моя работа» полностью нормальна, весь
остальной метод (аналогия, PERT, коэффициент готовности, гейт качества данных, заморозка оценки)
работает так же. Разделение по ролям — там, где роли РЕАЛЬНО есть, а не обязательный формат сам
по себе.

## Границы с соседними скиллами
`1c-analyst` готовит и владеет паспортом/ЧТЗ/тех-проектом (содержание документов). `1c-estimation`
не переписывает эти документы — читает их, судит о готовности и даёт оценку/замечания; найденный
пробел в содержании — сигнал вернуть документ автору, а не молча дописать его самому. `1c-dev`
превращает принятый вход в атомарные задачи и код — это следующий шаг после того, как оценка и
замечания закрыты.