| name | ocenka |
| description | Оценивает сложность технического проекта по 5 осям: техническая сложность, объём работ, неопределённость, интеграции, команда. Выдаёт уровень (Просто / Стандарт / Серьёзно / Сложно / Монстр), оценку трудозатрат в неделях, топ-риски и рекомендации. Вызывай когда пользователь говорит: «оцени проект», «насколько сложно», «сколько займёт», «оценка трудозатрат», «сложный проект?», «/оценка».
|
| allowedTools | ["AskUserQuestion","WebSearch"] |
Скилл: Оценка сложности проекта
Принципы калибровки
Шкала откалибрована так, чтобы:
- Большинство реальных задач попадало в «Стандарт» или «Серьёзно»
- «Просто» — реально редко, это действительно небольшая работа
- «Сложно» и «Монстр» — только когда есть реальные основания, не по умолчанию
- Минимальная единица оценки — 1 неделя (ничего «за день» в реальности не делается с учётом согласований, тестирования и правок)
Шаг 1 — Сбор информации
Если описания недостаточно, уточни через AskUserQuestion одним вопросом:
- Что нужно сделать (суть продукта/задачи)?
- Кто будет делать — один человек или команда?
- Есть ли уже что-то готовое (код, инфраструктура, данные)?
- Есть ли внешние зависимости — API, железо, заказчик, подрядчики?
- Насколько чётко сформулированы требования?
Если в контексте уже есть ТЗ или описание — работай с ним, не переспрашивай.
Шаг 2 — Оценка по 5 осям
Каждая ось — от 1 до 5 баллов. Сумма определяет уровень сложности.
Ось 1: Техническая сложность
| Балл | Описание | Примеры |
|---|
| 1 | Стандартные инструменты, решение очевидно | CRUD на известном стеке, статичный сайт, скрипт автоматизации |
| 2 | Есть нестандартные части, но решения известны | REST API с авторизацией, парсер, телеграм-бот с логикой |
| 3 | Несколько сложных компонентов, требует проектирования | Real-time функционал, сложная бизнес-логика, ML-пайплайн |
| 4 | Нестандартная архитектура, высокие требования | Распределённая система, CV/ML с нуля, высоконагруженный сервис |
| 5 | Исследовательская задача, нет готовых решений | Новая модель, низкоуровневая оптимизация, железо + ПО вместе |
Ось 2: Объём работ
| Балл | Ориентир по времени (1 разработчик) | Примеры |
|---|
| 1 | 1–2 недели | Лендинг, простой бот, доработка готового |
| 2 | 2–6 недель | MVP с 3-5 экранами, небольшой сервис |
| 3 | 6–16 недель (до 4 мес) | Полноценное веб-приложение, API + UI + БД |
| 4 | 4–8 месяцев | Платформа с несколькими ролями, ML + бэкенд + фронт |
| 5 | 8+ месяцев | Большая система, несколько взаимосвязанных продуктов |
Ось 3: Неопределённость требований
| Балл | Описание |
|---|
| 1 | Требования чёткие, согласованные, с примерами |
| 2 | Основное понятно, детали уточнятся по ходу |
| 3 | Общее направление есть, но много открытых вопросов |
| 4 | Требования размытые, заказчик сам не уверен |
| 5 | «Сделайте что-нибудь», исследовательская постановка |
Ось 4: Интеграции и зависимости
| Балл | Описание |
|---|
| 1 | Изолированная система, никаких внешних зависимостей |
| 2 | 1-2 простых интеграции (известный API, готовая библиотека) |
| 3 | 3-5 интеграций или одна сложная (легаси-система, железо) |
| 4 | Много интеграций, зависимость от третьих лиц, нестандартные протоколы |
| 5 | Критические зависимости вне контроля команды (госсистемы, уникальное железо, закрытые API) |
Ось 5: Командная/организационная сложность
| Балл | Описание |
|---|
| 1 | Один человек, решения принимает сам |
| 2 | 2-3 человека, простая координация |
| 3 | Команда 3-6 человек или сложный заказчик с долгими согласованиями |
| 4 | Несколько команд или подрядчиков, формальные процессы приёмки |
| 5 | Большая организация, регуляторные требования, много стейкхолдеров |
Шаг 3 — Определение уровня
Итоговый балл = сумма по 5 осям (5–25)
| Сумма | Уровень | Цвет | Смысл |
|---|
| 5–8 | 🟢 Просто | Зелёный | Небольшая задача, понятный путь, минимум рисков |
| 9–12 | 🔵 Стандарт | Синий | Типовой проект, решаемо без сюрпризов |
| 13–16 | 🟡 Серьёзно | Жёлтый | Требует опыта, нужно планирование и буфер |
| 17–20 | 🟠 Сложно | Оранжевый | Высокие риски, нужна сильная команда и процессы |
| 21–25 | 🔴 Монстр | Красный | Системный проект, нужна архитектура на старте и контроль рисков |
Шаг 4 — Оценка трудозатрат
Базовая формула (1 разработчик, полная занятость)
| Уровень | Диапазон |
|---|
| Просто | 1–3 недели |
| Стандарт | 3–10 недель |
| Серьёзно | 2–5 месяцев |
| Сложно | 4–9 месяцев |
| Монстр | 8+ месяцев |
Поправочные коэффициенты
| Условие | Эффект на срок |
|---|
| Команда 2-3 человека | ÷ 1.5 (не ÷ 2, есть накладные расходы) |
| Команда 4+ человек | ÷ 2–2.5 |
| Требования размытые (ось 3 ≥ 3) | × 1.3–1.5 |
| Интеграции вне контроля (ось 4 ≥ 4) | × 1.3–1.6 |
| Нет готовой инфраструктуры | + 1–3 недели |
| Есть готовый задел / бойлерплейт | × 0.7 |
| Буфер на риски (всегда) | + 15–25% к итогу |
Шаг 5 — Генерация отчёта
Вывести в формате:
ОЦЕНКА СЛОЖНОСТИ: [название проекта]
══════════════════════════════════════
УРОВЕНЬ: [эмодзи + название]
ИТОГОВЫЙ БАЛЛ: [X] / 25
ОЦЕНКА ПО ОСЯМ
──────────────
Техническая сложность: [X]/5 — [одна строка пояснения]
Объём работ: [X]/5 — [одна строка пояснения]
Неопределённость: [X]/5 — [одна строка пояснения]
Интеграции: [X]/5 — [одна строка пояснения]
Команда/организация: [X]/5 — [одна строка пояснения]
ТРУДОЗАТРАТЫ
────────────
Без буфера: [N] недель
С буфером: [N] недель (~[M] месяцев)
Команда: [состав] → итого ~[K] недель
ТОП-3 РИСКА
────────────
1. [риск] → [как митигировать]
2. [риск] → [как митигировать]
3. [риск] → [как митигировать]
РЕКОМЕНДАЦИИ
─────────────
• [что сделать в первую очередь]
• [на что обратить внимание]
• [что уточнить до старта]
══════════════════════════════════════
Примеры калибровки (чтобы не завышать)
| Проект | Ожидаемый уровень |
|---|
| Лендинг с формой заявки | 🟢 Просто (6-7 баллов) |
| Телеграм-бот для записи клиентов | 🟢 Просто / 🔵 Стандарт (8-10) |
| CRM-система для небольшой компании | 🔵 Стандарт (10-12) |
| Маркетплейс с оплатой | 🟡 Серьёзно (13-15) |
| Система CV/ML-распознавания (типа LEGO-сортировщика) | 🟡 Серьёзно / 🟠 Сложно (15-18) |
| Платёжная платформа с регуляторными требованиями | 🟠 Сложно (18-20) |
| ERP-система с нуля | 🔴 Монстр (20+) |
Специальные флаги (выводить отдельно если есть)
⚠️ «Стоп-сигналы» — если хотя бы один из факторов:
- Требования не зафиксированы письменно → риск scope creep
- Ключевая интеграция с системой вне контроля команды → риск срыва
- Нет буджета на итерации/правки → риск конфликта
- Один человек на весь проект без бэкапа → риск bus factor
- Нет критериев приёмки → риск «готово, но не то»
