Прозрачность разработки без Story points: как показать бизнесу реальный прогресс
Когда команда разработки отказывается от Story points, демо и графиков сгорания под предлогом гибкости, бизнес часто теряет ориентиры. Руководство перестаёт понимать, работает ли разработка вообще, и начинает давить на людей, требуя привычных отчётов. В этой статье разберём, чем заменить театр оцено

Когда команда разработки отказывается от Story points, демо и графиков сгорания под предлогом гибкости, бизнес часто теряет ориентиры. Руководство перестаёт понимать, работает ли разработка вообще, и начинает давить на людей, требуя привычных отчётов. В этой статье разберём, чем заменить театр оценок, чтобы прозрачность доставки стала реальной, а не имитацией.
Убрали Story points: почему бизнес ослеп
Story points — это не самоцель, а инструмент прогнозирования. Когда их убирают без альтернативы, бизнес теряет возможность отвечать на простые вопросы: когда будет готово, что мы получим через месяц, не отстаём ли мы от графика. Команда, которая говорит «мы стали гибкими», на деле часто прячет отсутствие управляемости за красивыми словами.
Проблема не в самих оценках, а в том, что их превратили в фетиш. Графики сгорания, виртуальные доски с бесконечными задачами, демо, которые никто не смотрит, — всё это создаёт видимость работы, но не даёт бизнесу главного: понимания, что деньги и время потрачены не зря. Когда витрину разбирают, становится видно, что за ней ничего нет.
Вместо того чтобы цепляться за Story points, стоит пересмотреть саму систему прозрачности. Бизнесу не нужны цифры ради цифр — ему нужны ответы на практические вопросы. И эти ответы можно дать без единой оценки в story points.
Предыстория: как мы пришли к театру оценок
Scrum и другие фреймворки принесли в разработку идею итеративности и обратной связи. Но со временем ритуалы стали важнее результата. Покер планирования, спринты, ретроспективы — всё это превратилось в формальность, которая не влияет на реальную доставку. Бизнес привык видеть графики и цифры, но перестал видеть продукт.
Мой опыт работы с департаментами до восьми команд показывает: когда команды начинают работать над одним продуктом, проблема видимости обостряется. Каждая команда отчитывается по-своему, метрики разнятся, и в итоге бизнес получает кашу вместо ясной картины. Попытки унифицировать оценки часто приводят к ещё большему бюрократизму.
Ключевой момент — осознать, что прозрачность не равна количеству отчётов. Прозрачность — это когда любой стейкхолдер в любой момент может ответить на три вопроса: что сделано, что делается, что будет делаться. И для этого не нужны Story points.
Как это работает: три уровня прозрачности
Первый уровень — квартальные цели. Вместо того чтобы оценивать каждую задачу, команда формулирует конкретные измеримые цели на квартал. Например, «увеличить конверсию в регистрацию на 15%» или «запустить мобильное приложение для iOS». Такие цели понятны бизнесу и не требуют декомпозиции в story points.
Второй уровень — демонстрация работающего продукта. Вместо слайдов и отчётов показывайте реальный функционал. Раз в неделю или две проводите демо, где команда показывает, что уже можно пощупать. Это может быть сырой прототип, но он говорит больше, чем любой график.
Третий уровень — метрики потока. Это не оценки, а фактические данные: сколько задач закрыто за неделю, какое время цикла, сколько незавершённой работы. Эти метрики показывают динамику и позволяют прогнозировать без субъективных оценок.
Технические подробности: как внедрить метрики потока
Метрики потока — это не rocket science. Вам понадобится доска с колонками (To Do, In Progress, Done) и инструмент для трекинга времени. Например, Jira или Trello. Собирайте данные за несколько недель, чтобы получить базовую линию.
Время цикла — это время от начала работы над задачей до её завершения. Если оно стабильно, вы можете прогнозировать скорость доставки. Например, если в среднем вы закрываете 10 задач в неделю, а в бэклоге 50, то приоритеты можно расставить на пять недель вперёд.
Незавершённая работа (WIP) — это количество задач, которые находятся в работе одновременно. Чем меньше WIP, тем быстрее поток. Ограничьте WIP до трёх-пяти задач на команду, и вы увидите, как время цикла сократится.
Кого затронет и как
Для разработчиков это означает меньше времени на оценки и больше — на реальную работу. Вместо покера планирования — короткое обсуждение приоритетов. Вместо отчётов о сгорании — демо и метрики. Это снижает стресс и повышает удовлетворённость.
Для менеджеров — переход от контроля к доверию. Вам придётся научиться читать метрики и задавать правильные вопросы. Но в итоге вы получите более точную картину, чем с графиками сгорания, которые часто врут.
Для бизнеса — прозрачность без иллюзий. Вы будете видеть реальный прогресс, а не красивые отчёты. Это позволит быстрее принимать решения и корректировать курс.
В российских компаниях, где часто культура управления строится на отчётности, такой подход может встретить сопротивление. Но именно здесь он даст наибольший эффект, потому что снимет барьер недоверия между бизнесом и IT.
Что будет дальше
В ближайшие годы тренд на отказ от формальных оценок будет усиливаться. Инструменты вроде линейного планирования и метрик потока станут стандартом для продуктовых команд. Крупные компании уже внедряют OKR и связывают их с метриками доставки.
Наиболее вероятный сценарий — гибридный подход: команды используют квартальные цели и метрики потока, но сохраняют лёгкую оценку для долгосрочного планирования. Главное — чтобы бизнес видел результат, а не процесс.
Итог
Убрать Story points — не значит потерять прозрачность. Наоборот, это шанс сделать её настоящей. Используйте квартальные цели, демонстрируйте работающий продукт и считайте метрики потока. Тогда бизнес поверит вам, потому что вы будете показывать факты, а не обещания. Следите за темой — в следующих статьях разберём, как внедрить OKR в разработку без боли.