# 1c Estimation > Оценка трудозатрат задачи 1С и проверка ЧТЗ перед оценкой/разработкой: чего не хватает, чтобы оценивать честно, оценка по аналогии на реальных закрытых задачах (не сумма придуманных атомов), проверка ЧТЗ тех-лидом по рамке требований и работа со списком замечаний (что именно вписать в замечание, чтобы оно было конкретным и проверяемым). ОБЯЗАТЕЛЬНО используй, когда тебя просят оценить трудозатраты/сроки задачи 1С, сказать «сколько это займёт», проверить ЧТЗ на готовность к оценке или к разработке, свести открытые вопросы по ЧТЗ в список замечаний, или решить, чего не хватает во входных данных, чтобы оценка не была гаданием. Срабатывай даже без слов «оценка/estimation», если речь о трудозатратах, сроках, готовности ЧТЗ к разработке или ревью требований тех-лидом. Главное правило: без нужных для размера задачи артефактов (паспорт/ ЧТЗ) не оценивать вслепую — назвать, чего не хватает; оценка — по аналогии на РЕАЛЬНЫХ похожих задачах, а не сумма изобретённых атомов; исторические данные о факт-часах использовать т - Skill: `vgtitov/1c-estimation` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add vgtitov/1c-estimation` - Raw SKILL.md: https://api.skillmd.com/api/skills/vgtitov/1c-estimation/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: vgtitov (https://skillmd.com/u/vgtitov) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/vgtitov/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` превращает принятый вход в атомарные задачи и код — это следующий шаг после того, как оценка и замечания закрыты.