Режем оценки пополам…

Ну давайте разбавим недавний стрим по психологии менеджерской обыденностью.

Главная боль любого заказчика - оценки. Внешний ли заказчик, или внутренний, не важно. Оценки нужно “подстригать”.

Я не буду много писать про сам метод критической цепи, про него можно и погуглить, но мне интересно подсветить главные конфликты, которые часто идут с методом, и которые не всегда понятно как решать.

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

Разберёмся по порядку:
Что происходит в методе критической цепи:

- Каждая задача оценивается с учётом "надежного времени" (например, 100 часов — с высокой вероятностью выполнения).
- Это время делится на две части:
1) 50 часов (агрессивная оценка с 50% вероятностью выполнения) — входит в расписание.
2) Оставшиеся 50 часов — уходят в общий буфер (проектный и/или буферы цепей).

Буфер не прикреплён к конкретной задаче, он используется как защита от рисков по всей критической цепи.

Как это коммуницировать исполнителю?
❌ Неподходящий вариант:
Прямо сказать: "Твоя оценка 100 часов, но мы тебя попросим сделать за 50".
- > Это демотивирует, вызывает возражения и включает защитное поведение: “Ну делай сам тогда”.

Рекомендуемый подход — переход на другой ментальный фрейм:
Метод критической цепи предполагает, что культура оценки и выполнения задач должна измениться. Вот как это можно делать:

1. Объясни: традиционная модель неэффективна
Обсуди с командой, что обычные оценки (типа 100 часов) в реальности редко используются полностью эффективно.

Часто время “проедается” из-за:
- синдрома студента (начинают позже),
- многозадачности,
- неоправданных подстраховок,
- искажённой ответственности за дедлайны.

2. Переходи к культуре агрессивных, но реалистичных оценок
Предложи использовать оценку с 50% вероятностью: "Если всё пойдёт нормально — ты справишься за это время. Если что — есть буфер".

Подчеркни, что:
- ты не штрафуешь за промах, а следишь за состоянием буфера.
- задача — обеспечить поток, а не давить на человека.

3. Буфер — невидим для исполнителя
Это ключ. Буфер не должен быть его проблемой. Исполнитель работает по новой "средней" оценке.
Буфер управляется на уровне проекта — менеджер смотрит, как он расходуется, и принимает решения (например, помогает, ускоряет, усиливает).

4. Мотивируй завершать раньше
В классическом CCPM это достигается не индивидуальными бонусами, а:
- отсутствием наказаний за раннее завершение (в отличие от традиционного "если сделал за 60 вместо 100, в следующий раз дам тебе 60"),
- признанием усилий и вклада в успех проекта,
- фокусом на системную победу (всё быстрее движется, меньше пожаров).

Как можно объяснить это разработчику:
"Мы хотим попробовать новый подход: ты даёшь оценку, мы с тобой определяем реалистичное, но не переоценённое время — такое, которое получится, если пойдёт без сбоев. Мы строим план из таких оценок, но дополнительно резервируем время в буфере, чтобы в случае проблем у тебя был запас.
Наша задача — следить за буфером, а не давить на тебя. Если ты заканчиваешь раньше — отлично. Если позже — смотрим, как это влияет на буфер и помогаем."

Ответ на главный вопрос:
Должен ли разработчик знать, что его оценку сократили?
Лучше перестроить всю систему оценивания, чтобы он сам давал агрессивную оценку, зная, что:
- над ним не будут давлеть за просрочку,
- у проекта есть защита (буферы),
- он работает не на "попасть в 100%", а на улучшение потока.

Но я уверен, что среди нас есть опытные читатели из сервисного бизнеса, которые сразу могут подметить вторую дилему, которая будет звучать примерно так:
“Так а как это все помогает, когда нам нужно сокращать оценки для продажи клиенту?
- Если оставлять буферы, то все равно надо будет продавать 100 часов. А такое не хотят покупать.
- Если продавать 50 часов, то получается брать все риски?"