Большинство планов рождаются так:

  • команда даёт оценки,
  • менеджеры превращают их в даты,
  • бизнес строит вокруг этого ожидания и бюджеты.
    На бумаге всё красиво. В жизни – снова переработки, переносы и поиски виноватых.

Разберёмся, почему так выходит.

  1. Оценки – это не измерение, а догадка.
    Каким бы опытным ни был разработчик, он оценивает не реальный поток событий, а свою ментальную картинку “как должно пойти”. Психологи называют это planning fallacy: люди системно недооценивают время и риски. И да, это подтверждено исследованиями и на индивидуальных задачах, и на крупных инфраструктурных проектах.
  2. Как только оценка стала обещанием – она перестала быть честной.
    “Назови цифру, но чтобы уложиться в квартал”. “Понимаем, что 3 месяца, но напиши 6 недель, нам нужно занести это наверх”. В игру вступают страх, политика и карьера. Оценки разъезжаются с реальностью ещё на старте.
  3. Story points в роли KPI – тот же vanity metric.
    Пока вы используете точки или размеры, чтобы понять, что крупнее, а что мельче, всё ок. Но как только:
  • velocity начинают гнаться вверх,
  • команды сравнивают между собой,
  • “скорость в story points” попадает в отчёты,
    метрика становится косметической: картинка красивая, поведение системы хуже.
  1. Сюрпризы неизбежны.
    Любой план, построенный на точечных оценках, предполагает относительно спокойный мир. Но реальность – это баги, инциденты, параллельные инициативы, новые зависимости. Даже если каждая оценка отдельно “почти попала”, их сумма почти гарантированно нет.

Что вместо этого

  1. Считать не баллы, а поток.
    Собираем историю: сколько задач в неделю реально завершает команда, без оценки “по ощущениям”. Это throughput, а не мнение.
  2. Строить вероятностные прогнозы.
    На основе исторического потока запускаем простую Monte Carlo симуляцию и отвечаем на два взрослых вопроса:
  • “Когда с 80-90% вероятностью мы закончим вот эти N элементов?”
  • “Сколько элементов мы успеем сделать к вот этой дате с 80-90% вероятностью?”
  1. Укреплять систему, а не выкручивать оценки.
    Ограничивать WIP, убирать блокеры, уменьшать размеры задач, вычищать очереди. Чем стабильнее поток – тем уже становится ваш прогноз и тем меньше сюрпризов.
  2. Переучивать стейкхолдеров говорить языком вероятностей.
    Не “мы точно успеем 1 октября”, а “у нас 85% шанс уложиться до 1 октября, 95% – до 15-го, вот риски”. Это неприятно вначале, но через пару кварталов доверие к планам становится выше, а не ниже.

Да, всё это сложнее, чем “помыслили, пооценивали и поехали”. Но в мире, где изменения – единственная константа, жить по оценочным сказкам – слишком дорогая роскошь.

Немного факт-чекинга и альтернатив

  • Планирование “по ощущениям” и хронические опоздания хорошо описаны в работах по planning fallacy: люди стабильно недооценивают время, деньги и риски будущих задач и проектов, даже имея статистику прошлых провалов.Wikipedia+2ScienceDirect+2
  • Анализы крупных инфраструктурных проектов (аэропорты, дороги, ИТ-системы) показывают регулярные перерасходы бюджета и сроков – это не проблема только “айтишников”, а общечеловеческий паттерн.Wikipedia+2PMA Consultants+2
  • Monte Carlo в продуктовом и agile-контексте уже давно используется как стандартный способ вероятностного прогнозирования на основе исторического throughput, а не субъективных оценок.More Than Monkeys+4devoteam.com+4getnave.com+4
  • По story points нет единства: часть экспертов критикует их как источник путаницы и vanity-метрики, другие защищают как инструмент относительной оценки, если не использовать их для KPI и сравнения команд.Medium+4Scrum.org+4GBH 20 years | People • Purpose • Impact+4

Полезная оговорка: бывают команды и проекты, где жесткая оценка плюс буферы и зрелый риск-менеджмент работают приемлемо. Но это скорей результат сильной системы (лимиты, приоритизация, культура), а не сами по себе “правильные оценки”.

Vanity metrics – это метрики, которые красиво смотрятся в отчётах, но почти не помогают принимать решения и улучшать систему. Они больше гладят эго, чем дают понимание реальности.

Проще всего запомнить так:

  • Хорошая метрика: помогает изменить поведение.
    Если цифра выросла или упала – вы точно знаете, что делать по-другому.
  • Vanity metric: даже если цифра изменилась, вы не знаете, что именно менять и в процессе, и в продукте.

Примеры vanity metrics

Из мира продукта / маркетинга:

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

Из мира разработки:

  • строки кода;
  • story points, если ими меряют «скорость команды» и сравнивают команды;
  • количество задач, «заведённых» в системе (а не завершённых).

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

  • ценим ли мы продукт для пользователя;
  • улучшаем ли мы бизнес-результат;
  • стала ли система устойчивее и предсказуемее.

Как отличать vanity metric от полезной

Задай к метрике три вопроса:

  1. Можно ли по ней принять решение?
    Если число выросло – что конкретно вы сделаете иначе завтра? Если ответа нет – это тревожный знак.
  2. Влияет ли она на поведение команды/пользователя так, как вы хотите?
    Например, если разработчиков оценивают по строкам кода, они начнут писать более многословный код, а не более качественный.
  3. Связана ли она с результатом, а не с активностью?
    Активность – это «мы что-то делали» (созвоны, коммиты, фичи).
    Результат – это «стало лучше» (меньше багов, быстрее доставка, выше retention, больше доход).

Присоединяйся к общению с единомышленниками https://t.me/kanbanclub

Как вы сейчас планируете сроки в своих командах

  1. Стандартно – оценки в story points/часах и дедлайны.
  2. Комбинируем оценки с историческими данными.
  3. Почти без оценок – смотрим на throughput/lead time.
  4. У нас хаос – каждый раз по-новому.