---
title: Оценка задач и проектов
description: "Выбор между оплатой за отдельные операции и работой команды за период: категории и баллы, спринты, абонементы и метрики сервиса."
---

Оптимальная модель оценки зависит прежде всего от того, что клиент покупает: **отдельный завершённый результат** или **регулярную работу и доступность команды в течение периода**. Это два разных способа организовать коммерческое предложение. Часы и ставка могут использоваться внутри обоих способов для проверки экономики, но не обязаны быть единицей продажи.

Почему оплата по часам как единица продажи вознаграждает затраченное время, а не результат, и какие единицы используют вместо неё в других отраслях, разобрано в статье [«Альтернативы почасовой оплате»](https://wpcraft.ru/kb/processes/pricing/hourly-alternatives.md).

## Две базовые модели оценки

### Транзакционная модель: цена за операцию

Транзакционная модель подходит, когда запрос можно отделить от остальных работ и описать ожидаемый результат. Клиент оплачивает конкретную операцию, задачу или пакет работ.

Есть два распространённых способа оценить такую единицу:

- **По типу операции.** Для повторяемых работ задают категории с составом и границами: например, диагностика ошибки, настройка формы, обновление типового модуля. Указывают, что входит в цену, какие исходные данные нужны, что считается завершением и какие случаи оцениваются отдельно.
- **По баллам.** Если задачи различаются, команда оценивает их относительную сложность по общей шкале и связывает балл с ценой или диапазоном. Баллы учитывают объём, сложность и неопределённость, но не являются часами и сроком. Шкалу калибруют на завершённых задачах.

Для обеих схем до начала работы нужны описание результата, критерии приёмки и правила обработки изменений. Неизвестную интеграцию или плохо изученную кодовую базу лучше сначала исследовать, а затем оценивать реализацию. Иначе фиксированная цена будет опираться на неподтверждённые предположения.

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

### Итерационная модель: цена за период

Итерационная модель подходит для регулярного развития или поддержки, когда следующий набор задач уточняется по ходу работы. Клиент оплачивает согласованную ёмкость, команду или сервис за период — например, спринт, месяц, квартал или год. Срок задаёт бюджетный и рабочий цикл, а не обещание выполнить любое число задач.

В договорённости задают доступную ёмкость команды, способ приоритизации, рабочие часы и каналы коммуникации, состав отчёта, правила переноса остатка и порядок изменения бюджета. Для долгого периода дополнительно фиксируют даты пересмотра объёма и цены. В Scrum спринт — короткий фиксированный цикл с целью и инкрементом; в Kanban работу ведут непрерывным потоком и управляют её поступлением и незавершённой работой.

#### Поддержка с SLA

Для техподдержки периодическая модель продаёт готовность принимать и обрабатывать обращения в согласованных границах. Помимо периода и цены, фиксируют часы покрытия, каналы, приоритеты, время первого ответа и целевое время решения или обходного пути. Нужно определить, какие события останавливают отсчёт SLA, например ожидание ответа клиента или внешнего поставщика.

Ежемесячный отчёт может показывать соблюдение SLA по приоритетам, время первого ответа и решения, число обращений, повторные открытия и удовлетворённость. [Метрики ServiceDesk](https://wpcraft.ru/kb/processes/kpi/service-desk.md) помогают определить показатели и знаменатели: SLA считают только для обращений, к которым применим соответствующий целевой срок. SLA описывает качество сервиса, а не гарантирует фиксированный объём задач.

#### Разработка по Kanban и метрикам поставки

Для непрерывной разработки можно согласовать месячную или квартальную ёмкость команды, вести приоритетный бэклог и пополнять поток по мере освобождения WIP-лимитов. Вместо обещания закрыть заранее неизвестное число задач команда показывает данные потока: throughput (сколько элементов завершено за период), lead time (сколько проходит от принятия задачи до завершения), возраст незавершённых задач и WIP. Термины и правила измерения потока описаны в [метриках потока](https://wpcraft.ru/kb/processes/kpi/flow-metrics.md) и [руководстве Kanban University](https://kanban.university/kanban-guide/).

Для оценки результата разработки к показателям потока можно добавить метрики DORA: частоту поставки, время от коммита до production, долю неудачных изменений, время восстановления после неудачного изменения и долю незапланированных переделок. Они показывают скорость и стабильность поставки; смотрите на динамику в контексте конкретного продукта и команды. DORA-метрики не следует превращать в отдельный тариф или индивидуальную квоту без согласованного способа измерения и влияния команды на показатель. Описание показателей и их текущих определений — в [метриках Delivery и DORA](https://wpcraft.ru/kb/processes/kpi/delivery.md) и на сайте [DORA](https://dora.dev/guides/dora-metrics/).

**Когда выбирать:** развитие продукта и техническая поддержка с повторяющейся потребностью, изменяющимися приоритетами и готовностью клиента регулярно выбирать следующий объём работ.

## Популярные модели ценообразования

Транзакционная и итерационная модели описывают, как организованы единица продажи и рабочий ритм. Популярные коммерческие модели уточняют, что именно фиксируют в договорённости и кто несёт риск изменения объёма. Поэтому они пересекаются: например, итерационный Agile-контракт может иметь фиксированный бюджет, а T&M — ограничиваться месячным бюджетом.

### Fixed Price — фиксированная цена

- **Что оплачивается:** заранее согласованный результат за фиксированную сумму; границы и критерии приёмки закреплены до начала работ.
- **Когда подходит:** объём и требования достаточно ясны. Изменения проходят отдельную оценку и согласование.

### Time & Materials (T&M)

- **Что оплачивается:** фактически затраченное время по ставкам ролей; дополнительные расходы оговариваются отдельно.
- **Когда подходит:** требования уточняются по ходу работы, а заказчик готов участвовать в приоритизации. Бюджетный лимит помогает контролировать расходы.

### Dedicated Team — выделенная команда

- **Что оплачивается:** состав и доступность команды за регулярную плату, обычно помесячно.
- **Когда подходит:** продукт развивается долго, команде важно накапливать контекст, а заказчик управляет приоритетами.

### Agile-контракт

- **Что оплачивается:** бюджет и срок либо цена спринта; состав работ пересматривается по итерациям.
- **Когда подходит:** работа идёт короткими циклами, стороны регулярно выбирают следующий объём и заранее договариваются о распределении риска.

### Retainer — абонемент

- **Что оплачивается:** регулярная плата за оговорённую ёмкость, пакет работ или доступность команды.
- **Когда подходит:** есть постоянный поток поддержки и доработок. До старта определяют лимит, перенос остатка и порядок оплаты сверхлимитных работ.

Ещё несколько практик дополняют эти модели или подходят для особых случаев:

- **Managed Services** — подрядчик отвечает за работу сервиса и согласованный SLA; цена зависит от состава услуги, покрытия и уровня обязательств.
- **Outcome-based pricing** — оплата связана с измеримым результатом; нужна надёжная метрика и понятный способ определить вклад исполнителя.
- **Value-based pricing** — цену определяют исходя из ценности решения для клиента, а не только себестоимости работ; ценность нужно обосновать и согласовать.
- **Cost-plus** — фактические затраты плюс заранее согласованное вознаграждение или маржа.
- **Гибрид Fixed Price + T&M** — определённое ядро фиксируют, а изменения и развитие ведут по фактическим затратам.
- **Budget Cap** — верхний предел затрат, который дополняет T&M; при его достижении работу останавливают или согласуют следующий лимит.

Название модели само по себе не устраняет риск. Зафиксируйте, что считается завершением, как учитываются изменения и какие отчёты получает заказчик. Сравнивайте модели по определённости объёма, предсказуемости бюджета и необходимой вовлечённости клиента.

## Как выбрать модель

Выбирайте модель по ясности объёма, регулярности потребности и готовности клиента участвовать в управлении работой:

- **Результат и границы понятны** — цена за тип операции или фиксированную задачу. Согласуйте состав, исключения, критерии приёмки и цену изменений.
- **Есть поток сравнимых задач разной сложности** — баллы за задачу или пакет. Определите шкалу и эталоны, цену балла, ограничения и период пересмотра.
- **Нужна регулярная поддержка с измеримым уровнем сервиса** — абонемент или бюджет на месяц/год с SLA. Зафиксируйте покрытие, приоритеты, целевые сроки, отчётность и сверхлимитные работы.
- **Нужно непрерывно развивать продукт с меняющимся бэклогом** — ёмкость команды за спринт или период. Согласуйте цель и ёмкость, правила приоритизации, метрики потока и качества.
- **Объём пока неизвестен, но расходы нужно ограничить** — T&M с бюджетным лимитом или короткими этапами. Установите ставки, порядок учёта, лимит, точки сверки и условия продолжения.

Модели можно сочетать по границам работ: например, обследование оценить отдельной операцией, а дальнейшее развитие вести месячными итерациями. Внутренняя ставка помогает проверить покрытие затрат во всех этих форматах; формула приведена в статье [расчёт стоимости нормо-часа](https://wpcraft.ru/kb/processes/pricing/hourly-rate.md).

## Что зафиксировать до старта

Независимо от модели опишите ожидаемый результат или сервис, входящие и исключённые работы, зависимости, правила приоритизации, способ подтверждения выполненного и процесс изменения договорённости. Для транзакционной оценки это защищает границы операции; для периодической — задаёт ёмкость, качество сервиса и прозрачный порядок выбора следующих задач.

## Материалы и источники

- [Цены и форматы работы WPCraft](https://wpcraft.ru/pricing)
- [Метрики ServiceDesk](https://wpcraft.ru/kb/processes/kpi/service-desk.md)
- [Метрики потока](https://wpcraft.ru/kb/processes/kpi/flow-metrics.md)
- [Метрики Delivery и DORA](https://wpcraft.ru/kb/processes/kpi/delivery.md)
- [5 популярных моделей ценообразования в разработке — WPCraft](https://wpcraft.ru/blog/5-populyarnyh-modelej-cenoobrazovaniya-v-razrabotke)
- [The Official Guide to The Kanban Method — Kanban University](https://kanban.university/kanban-guide/)
- [DORA software delivery performance metrics](https://dora.dev/guides/dora-metrics/)