# Как мы оцениваем проекты: от брифа до вилки в смете

Оценка «на глаз» почти всегда ошибается в 1.5–2 раза. Показываем, как мы декомпозируем задачу перед тем, как называть сроки и бюджет.

*Рубрика: Процессы и кейсы · Опубликовано: 22 апреля 2026 г. · Автор: Александр Покидов*

Канонический URL: https://pokidov.dev/blog/kak-my-otsenivaem-proekty

---

Клиент почти всегда спрашивает точную цифру в первую неделю знакомства с проектом — и почти всегда это худший момент, чтобы её называть.

## Как устроена декомпозиция

| Этап | Что делаем | Результат |
| --- | --- | --- |
| Бриф | Собираем цели, ограничения, интеграции | Список открытых вопросов |
| Декомпозиция | Разбиваем на модули и экраны | Список задач с диапазоном часов |
| Вилка сметы | Суммируем диапазоны, добавляем риск | Итоговая вилка бюджета и сроков |

1. Фиксируем цели проекта в терминах бизнеса, не технологий.
2. Раскладываем по модулям: авторизация, каталог, оплата и так далее.
3. На каждый модуль — диапазон часов, а не единственное число.
4. Отдельно считаем риск интеграций с чужими системами.

> **Почему вилка, а не число**
Диапазон в 20–30% честнее отражает неопределённость технического задания на старте, чем ложно точная цифра.

## Ключевые выводы

- Оценка без декомпозиции на модули — это гадание, а не расчёт.
- Вилка в смете (а не точное число) честнее отражает неопределённость на старте.
- Технический риск (интеграции, легаси) закладывается отдельной строкой, а не «про запас».
- Оценка пересматривается после первого спринта, когда неопределённость уже ниже.