| name | 1c-estimation |
| description | Оценка трудозатрат задачи 1С и проверка ЧТЗ перед оценкой/разработкой: чего не хватает, чтобы оценивать честно, оценка по аналогии на реальных закрытых задачах (не сумма придуманных атомов), проверка ЧТЗ тех-лидом по рамке требований и работа со списком замечаний (что именно вписать в замечание, чтобы оно было конкретным и проверяемым). ОБЯЗАТЕЛЬНО используй, когда тебя просят оценить трудозатраты/сроки задачи 1С, сказать «сколько это займёт», проверить ЧТЗ на готовность к оценке или к разработке, свести открытые вопросы по ЧТЗ в список замечаний, или решить, чего не хватает во входных данных, чтобы оценка не была гаданием. Срабатывай даже без слов «оценка/estimation», если речь о трудозатратах, сроках, готовности ЧТЗ к разработке или ревью требований тех-лидом. Главное правило: без нужных для размера задачи артефактов (паспорт/ ЧТЗ) не оценивать вслепую — назвать, чего не хватает; оценка — по аналогии на РЕАЛЬНЫХ похожих задачах, а не сумма изобретённых атомов; исторические данные о факт-часах использовать только после проверки их полноты/непрерывности. Подготовка самих документов (паспорт/ЧТЗ/тех-проект) — скилл `1c-analyst`; реализация — `1c-dev`.
|
Оценка трудозатрат и проверка ЧТЗ
Локализация (сначала, если есть)
Если в скилле есть каталог references/local/ — прочитай его ПЕРЕД работой: version-stack.md,
ролевые корзины оценки своей компании (estimation-buckets.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). Прежде чем дать число:
- Определи размер задачи (S/M/L/XL) и по нему — какие рамки обязательны.
- Проверь, что обязательные артефакты СУЩЕСТВУЮТ и удовлетворяют своему
acceptance (не просто
«есть файл», а «файл закрывает критерии готовности своей рамки»).
- Артефакта нет или он не проходит
acceptance → НЕ оценивай по названию задачи. Явно скажи,
чего не хватает («нет паспорта — не видно границ и критериев приёмки бизнеса», «ЧТЗ без
логической модели данных — нельзя оценить объём доработки данных»), и предложи получить это,
а не подставляй усреднённую догадку вместо отсутствующего входа.
- Исключение — предварительная (грубая, вилочная) оценка на этапе паспорта: она ЯВНО помечается
как предварительная, с широким диапазоном, и не заменяет уточнённую оценку после ЧТЗ.
Железное правило 2 — оценка по аналогии, не сумма придуманных атомов
- Основание оценки — РЕАЛЬНЫЕ похожие задачи, уже закрытые (тот же контур/тип доработки/размер), а
не декомпозиция на воображаемые подзадачи с придуманными часами на каждую. Декомпозиция здесь
нужна для ПОЛНОТЫ («не забыли ли кусок объёма»), а не как арифметика оценки.
- Если аналогов нет или они сильно расходятся между собой — так и скажи: диапазон шире, уверенность
ниже. Не сглаживай разброс одной уверенной цифрой, если основание для неё слабое.
- Оценка — вилка (мин/макс), а не одно число; если процесс требует одного числа для планирования —
бери среднюю ЯВНО из вилки, не выдумывай точность, которой нет.
- Раздели оценку по ролевым корзинам (аналитик/тех-лид/разработчик/тестирование/… — состав корзин
задаёт локализация компании), а не одной суммой на всю задачу: разные роли имеют разную историю
аналогов и разную точность.
- Изменение объёма ПОСЛЕ ЧТЗ (уточнение в ходе разработки) — повод вернуться и переоценить, а не
молча растянуть первоначальную цифру.
Железное правило 3 — гейт качества исторических данных
Прежде чем опереться на исторические «факт-часы» аналогов как на основание оценки — проверь ГЛУБИНУ
и НЕПРЕРЫВНОСТЬ их учёта, а не только их наличие:
- Короткий период регулярного учёта (тем более если он начался недавно) — недостаточная выборка;
аналоги ДО начала регулярного учёта могут быть неполными (не все часы зафиксированы) и занижать
оценку, если их взять как есть.
- Разнородный по времени учёт (часть периода фиксировалась исправно, часть — нет) — не усредняй по
всему периоду молча; либо ограничься надёжным окном, либо явно пометь оценку как менее уверенную.
- Итог гейта — не блокер сам по себе, а ОБЯЗАТЕЛЬНАЯ строка в выдаваемой оценке: на чём основана
уверенность (глубина/качество истории), а не только сама цифра. Скрытая от заказчика оценки
неопределённость хуже честно названного широкого диапазона.
Проверка ЧТЗ тех-лидом и список замечаний
Полный протокол ревью ЧТЗ по рамке требований (какие блоки/правила/acceptance проверять) и
механизм ведения списка замечаний (структура одного замечания, как предложить формулировку,
блокирующее/неблокирующее) — references/chtz-review-and-remarks.md.
Роли-корзины оценки
Состав и число корзин (аналитик/тех-лид/разработчик/тестирование/поддержка/…) — данные локализации
компании (references/local/estimation-buckets.md), не часть ядра: разные организации делят труд
по-разному. Ядро требует одного: оценка и её обоснование даются ПО КОРЗИНЕ, а не одной суммой.
Границы с соседними скиллами
1c-analyst готовит и владеет паспортом/ЧТЗ/тех-проектом (содержание документов). 1c-estimation
не переписывает эти документы — читает их, судит о готовности и даёт оценку/замечания; найденный
пробел в содержании — сигнал вернуть документ автору, а не молча дописать его самому. 1c-dev
превращает принятый вход в атомарные задачи и код — это следующий шаг после того, как оценка и
замечания закрыты.
