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

Железное правило 3 — гейт качества исторических данных

Прежде чем опереться на исторические «факт-часы» аналогов как на основание оценки — проверь ГЛУБИНУ и НЕПРЕРЫВНОСТЬ их учёта, а не только их наличие:

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

Проверка ЧТЗ тех-лидом и список замечаний

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

Роли-корзины оценки

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

Границы с соседними скиллами

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