Глава 4: Борхес считает story points

О чём эта глава. Парадокс Agile-измерений. Как метрики, призванные увеличить гибкость, становятся лотереей — системой настолько сложной, что никто не помнит, зачем она началась. От Spotify Model до SAFe, от OKR-театра до velocity gaming — анатомия измерительного безумия.

Переговорная №7, спринт-планирование

Продакт-менеджер мобильного банкинга смотрит на доску story points и понимает: система сожрала команду.

Начиналось просто. Два года назад velocity помогала планировать — 35 points в спринт, стабильно, предсказуемо. Теперь на стене висят четыре диаграммы: velocity by team, story point inflation, capacity planning, burndown by epic. Планирование съедает восемь часов в спринт. На разработку остаётся тридцать два.

— А что если 5 points? — спрашивает джуниор-разработчик. — Нет, это точно 8, — отвечает сеньор. — Помнишь ту задачу с API на прошлом спринте? — Какую именно? — Ну... сложную.

Продакт-менеджер перекладывает карточки planning poker и думает о Хорхе Луисе Борхесе.

Борхес, 1941: в рассказе «Лотерея в Вавилоне» общество погружается в игру, которая поглощает все его аспекты¹. Началось просто — денежные призы. Затем штрафы. Потом — должности, приговоры, браки. Каждый розыгрыш произвёл ответвления: побочные лотереи, лотереи для определения правил других лотерей, лотереи для отмены результатов.

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

Борхесовский рассказчик признаётся: он не знает, ни сколько этажей у лотереи, ни какой этаж ему доступен. Неведение здесь — не недостаток памяти, а симптом системы, которая выросла за пределы понимания собственных участников.

Он знает это чувство — не помнит, зачем команда начала считать story points. Помнит только, что теперь это обязательно — для отчётности, для прогнозирования, для KPI. За семьдесят лет до появления SAFe Борхес описал корпоративную методологию точнее любого современного консультанта.

Холмс (глава 3) дал нам метод — семь признаков болезни проекта, но при этом работает с уликами, не ставя принципиального вопроса: что если сам инструмент наблюдения искажает наблюдаемое?

Борхес ставит этот вопрос прямо, показывая Вавилон не как хаос, а как порядок, выросший до хаоса — где лотерея уже не случай, а измерение, полностью потерявшее связь с измеряемым.

Глава ставит конкретный вопрос: как Agile-метрики — velocity, story points, OKR, burndown charts — инструменты гибкости — превратились в вавилонскую лотерею? Систему, где команды тратят больше часов на её обслуживание, чем на создание продукта?

Тезис: измерение, призванное увеличить гибкость, неизбежно уменьшает её, коль скоро становится целью.

Чарльз Гудхарт (1975) сформулировал закон: любая наблюдаемая статистическая закономерность стремится разрушиться, как только на неё начинают давить в целях управления². Двадцать два года спустя Мэрилин Стрэтерн отчеканила ту же мысль в короткую формулу, которую с тех пор цитируют вместо Гудхарта: «Когда мера становится целью, она перестаёт быть хорошей мерой»³ — и показала, что это касается не только экономики, но образования, здравоохранения, управления.

Борхес за тридцать четыре года до Гудхарта показал ту же механику, только назвал её лотереей.

Лотерея метрик

Скорость работы команды (Velocity): первый тираж лотереи

Тимлид финтех-стартапа помнит, как всё начиналось. Лето 2022: команда из пяти человек, velocity 30 points — чистая арифметика как внутренний инструмент калибровки. Если спринт 30 points, то на три фичи уйдёт три спринта. Просто.

Проблема: лотерея в Вавилоне не остаётся простой, и velocity — не остаётся внутренним.

Осень 2022 — первая мутация. Директор по разработке видит дашборд: Команда Frontend: 40 points, Команда Backend: 25 points. Логика безупречна — Frontend эффективнее. Тимлид пытается объяснить: «Мы сравниваем Цельсий с Фаренгейтом и объявляем Америку жарче». Директор кивает и просит Backend «подтянуть показатели».

Зима 2023 — вторая мутация. Velocity становится частью KPI отдела. Тимлид наблюдает, как команда начинает играть систему: задача «Интеграция с банковским API» (3 points) превращается в «Настройка тестовой среды» (2 points) + «Написание клиента API» (2 points) + «Обработка ошибок» (1 point). Velocity растёт с 30 до 45, объём работы не изменился.

— Отличная динамика, — говорит директор на планёрке. — Мы ничего не ускорили, — отвечает тимлид. — Цифры говорят обратное.

Инфляция очков (story point inflation) — стандартная проблема, зафиксированная Scrum.org, Age of Product, LinearB и др.⁴ Лена читала об этом в блогах, но столкнуться лично — другой опыт.

Борхес уловил механику: «по мере расширения лотереи каждый свободный акт включался в её сферу»¹. Velocity выросла из инструмента в сферу, поглощающую каждый акт команды. Техническое решение стало политическим актом.

Story points: язык, утративший значение

— А что значит 5 points? — спрашивает новый разработчик на своём первом планировании. — Ну, больше 3, но меньше 8, — отвечает тимлид. — А что значит 8? — Сложная задача. Помнишь ту миграцию базы на прошлом спринте? — Я тогда ещё не работал.

Борхес в «Библиотеке Вавилона» описал бесконечную библиотеку, содержащую все возможные книги — каждую комбинацию букв. Поэтому библиотека бесполезна: когда существует всё, найти конкретное невозможно⁵.

Story points — та же вавилонская библиотека. Система, которая, означая всё, именно поэтому означает ничего.

В переговорной висит плакат «Definition of Done», но нет плаката «Definition of Points». Что такое 5 points? Для фронтенда — день, для бэкенда — неделя, для QA — «зависит от того, сколько багов найдём». Числа Фибоначчи (1, 2, 3, 5, 8, 13) выбраны не за отношение XIII века к оценке сложности, а за нелинейность — отражение неопределённости. Средневековая математика для измерения того, что не поддаётся измерению.

Каждую вторую среду — два часа на planning poker. Семь взрослых людей показывают карточки с числами (детская игра) для оценки задачи, которую никто ещё не начинал. Один показывает 5, другой — 8, третий — 3. Начинается «обсуждение» — каждый объясняет свою цифру через метафору из прошлого опыта, который остальные не помнят.

— Я ставлю 8, потому что это похоже на ту задачу с OAuth... — Какую именно? — Ну, сложную.

Борхес предвосхитил этот абсурд, но истинная стоимость подобного абсурда измеряется в часах команды. По подсчётам тимлида: 7 человек × 2 часа × 26 спринтов = 364 часа в год на гадание по карточкам. Два месяца разработки — на оценку разработки.

Spotify Model: модель, которая не работает даже в Spotify

HR-директор крупного банка летит в Стокгольм изучать «легендарную модель». 2019 год, делегация с бюджетом, за который потом не стыдно отчитаться. Цель — внедрить Spotify Model в российской корпорации.

В самолёте она перечитывает документ Книберга и Иварссона: Squads, Tribes, Chapters, Guilds⁶. План трансформации уже готов — HR нарисовал новую оргструктуру, IT заказал редизайн офиса под «племенную» модель, топ-менеджмент ждёт результата.

Первый день в Spotify. Экскурсовод (не Книберг — он ушёл три года назад) показывает офис: — Эта зона была для Tribe A, но сейчас здесь смешанные команды. — А где Chapter Lead из презентации? — Ах, эта роль трансформировалась. Сейчас у нас другая структура.

Она перечитывает первый абзац документа: «Эта статья — лишь снимок нашего текущего способа работы… к моменту, когда вы это читаете, всё уже изменилось»⁶. Предупреждение, которое все игнорируют.

Вечером в отеле она открывает разбор Иеремии Ли — бывшего PM Spotify: документ описывает идеализированное состояние, которого Spotify не достигла даже в момент публикации; сами squads реорганизовывались, tribes менялись, guilds теряли активность⁷. Сам Книберг в течение десяти лет после публикации многократно напоминал: это snapshot, а не blueprint.

Самое болезненное открытие: Spotify молча использовала документ как инструмент рекрутинга, хотя внутренняя реальность давно отличалась. Она понимает — они копируют рекламный буклет.

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

Конвей (глава 3): организация воспроизводит свою структуру в продукте. «Модель Spotify» — попытка обратного: скопировать структуру и получить чужой продукт. Это фундаментальная ошибка. Структура Spotify отражала культуру Spotify, шведский рынок, конкретных людей, конкретный момент. Копировать структуру без культуры — всё равно что копировать ресторан и ждать вкусной еды.

SAFe: государственная религия

Если «Модель Spotify» была наивной лотереей, то SAFe — её логическая эволюция: лотерея, получившая официальный государственный статус.

SAFe 6.0: четыре конфигурации (Essential, Large Solution, Portfolio, Full), десятки ролей и церемоний⁹. «Big Picture» похожа на схему метро города-призрака. Всё соединено, всё подписано — и бессмысленно без контекста.

Парадокс масштабирования: методология простоты и самоорганизации неизбежно порождает слои управления¹⁰.

Борхес о SAFe: «Лотерея подчиняется Компании; о внутренней структуре Компании ходят лишь домыслы»¹ — замените «Компания» на «Scaled Agile, Inc.» и получите портрет тысяч организаций, внедряющих коммерческий фреймворк; далее Борхес утверждает: «Лотерея — это интерполяция случая в порядок мира»¹.

Вопрос: создаёт SAFe подлинную ценность — или маркирует хаос под видом «управляемой сложности»?

Nokia (глава 2) потеряла рынок смартфонов из-за страха, а одновременно (2008–2010) внедряла масштабную Agile-трансформацию. Laanti, Salo, Abrahamsson (2011) описывают восприятие этой трансформации самими сотрудниками — общий позитивный отклик¹¹. Падение доли рынка тех же лет задокументировано в гл.2 (Vuori, Huy, 2016) — хотя это не причинность, такое совпадение подрывает обещание «Agile at scale спасает».

OKR: карго-культ

CPO e-commerce-компании сидит над квартальными OKR и чувствует себя меланезийским шаманом, строящим соломенный самолёт.

Q1 2024. CPO читает мануал Джона Дорра: OKR — инструмент фокуса (Intel, Google)¹², причём именно инструмент, а не религия. Но то, что происходит в компании, больше напоминает карго-культ.

Январь — квартальная церемония. CPO пишет в шаблоне Confluence:

• О1: «Стать лидером в сегменте fashion e-commerce»
• KR1: «Увеличить долю рынка до 15%»
• KR2: «Поднять NPS до 75»

Текст красивый, амбициозный, совершенно оторванный от реальности. CPO знает: документ откроют в марте (review) и июне (следующее планирование). Между этим — обычная работа по обычным задачам.

Февраль — каскадирование. Цепочка превращений: «лидерство в fashion» → «улучшение конверсии» → «оптимизация каталога» → «рефакторинг поиска» → тикет JIRA-15247 «Починить сортировку по цене». Разработчик смотрит на этот тикет и думает: какое отношение багфикс имеет к лидерству рынка?

— Это стратегически важная задача, — объясняет CPO. — Но это же обычный баг... — Всё связано с OKR.

Март — оценка. CPO ставит себе 0.4 из 1.0. По Дорру, хороший результат — 0.7, а 1.0 означает недостаток амбиций¹². Парадокс «успех = частичный провал». Как объяснить генеральному, что 40% выполнения цели — это нормально?

— У нас проблемы с исполнением, — говорит генеральный директор. — Нет, это специально заложенная амбициозность... — Звучит как оправдание провала.

Водтке (2016): OKR работает в культурах, принимающих провал¹³. Большинство корпораций такой культурой не обладает — и в подобной среде OKR превращается в лотерею со штрафами.

Борхес предупреждал: некоторые — с упорством, достойным лучшего применения — считают, что лотерея вовсе не существует.

Ретроспективный театр

Скрам-мастер геймдев-студии раскладывает стикеры и думает о театре абсурда. Пятница, 16:00, переговорная «Марио». Седьмая ретроспектива подряд с одним и тем же финалом.

Ретроспектива в теории — анализ успехов и неудач. Рефлексия, которую Этцель и Верн (1870, глава 1) знали как разговор о тираже за обедом. На практике — театр с неизменным репертуаром.

Акт I — Стикерная литургия. Скрам-мастер вычерчивает на флипчарте три колонки: 😊 / 😐 / 😞. Команда послушно заполняет:

• Зелёный стикер от сеньора: «Хорошо поработали над системой инвентаря»
• Красный стикер от разработчицы: «Слишком много встреч»
• Жёлтая колонка пуста (как всегда)

— Почему никто не пишет нейтральные моменты? — спрашивает новичок. — А что писать? — пожимает плечами сеньор. — Что нормально прошло, то нормально.

Акт II — Озвучивание. Разработчица читает свой красный стикер: — Опять слишком много встреч. Планирование, груминг, стендапы, ретроспективы... Кивки понимания. Такой же стикер был в сентябре, октябре, ноябре, декабре. — А какие конкретно встречи лишние? — уточняет скрам-мастер. — Ну... разные. В общем, много.

Акт III — Action items как лотерея. Скрам-мастер записывает на доске: «Сократить количество встреч». Ответственный: не назначен. Срок: не определён. Критерии успеха: размыты. — Договорились, будем более эффективно планировать время, — резюмирует скрам-мастер.

Через две недели на новой ретроспективе появляется знакомый красный стикер: «Слишком много встреч». Скрам-мастер смотрит в свои заметки — action item из прошлой ретро забыт всеми, включая её саму.

Так ретроспектива превращается в ритуал вместо рефлексии — не финальная, а бесконечная. Ничто не несёт ответственности, создавая замкнутый цикл: стикеры → action items → новые ретроспективы → свежие стикеры. Та лотерея, которую описал Борхес, тоже была устроена так, что никогда не была последней.

Вайнберг (глава 3) отмечает: когда разработчики теряют контакт с пользователями, они начинают проектировать систему для себя — точно так же ретроспективы, переставшие что-либо менять, проводятся для самоутешения.

Против измерений

Большинство метрик гибких методов причиняют больше вреда, чем пользы.

Мюллер, 2018: метрики производительности неизбежно приводят к манипуляциям показателями — больницы начинают отказывать тяжёлым пациентам, школы исключают слабых учеников, полиция переклассифицирует преступления¹⁴.

Дональд Кэмпбелл в 1979 году сформулировал закон, который позже стали называть его именем: чем шире количественный показатель используется для социальных решений, тем сильнее он подвержен давлению, искажающему сам процесс, который он должен был измерять¹⁵. Velocity gaming, story point inflation и OKR cascading — этот закон в действии.

Если Холмс (глава 3) видел в измерениях симптомы болезни, то Борхес идёт дальше — инструменты наблюдения сами становятся болезнью.

DORA (Google Cloud, 2023) избегает velocity, story points и OKR, предлагая вместо этого четыре метрики результата¹⁶ — частота деплоев, lead time (от коммита до продакшена), время восстановления после сбоя, процент неудачных изменений. Все четыре привязаны к объективной реальности (система либо развёрнута, либо нет) — гейминг затруднён.

DORA работает именно потому, что исключает побочные измерения, каскадирование и церемонии, оставляя четыре объективных, недвусмысленных числа — Брукс (глава 3) одобрил бы такое упрощение: n(n-1)/2 каналов коммуникации сводятся к четырём индикаторам.

Паттерн лотереи: инструмент → институт

Борхес описывает универсальный паттерн деградации через четыре фазы с незаметными переходами.

Фаза 1: Полезный инструмент. Velocity помогает, story points упрощают, OKR фокусируют — пока работает, всё ценно, но затем наступает институционализация, когда «используют velocity» превращается в «все обязаны отчитываться velocity», «нужна ретроспектива» — в «каждые две недели», то есть полезное становится обязательным.

Фаза 2: Метрика становится целью. Velocity превращается в KPI, OKR — в основу оценки, ретроспектива — в отчётность, подтверждая закон Гудхарта: инструменты начинают оптимизировать сами себя.

Фаза 3: Лотерея. Система метрик становится настолько сложной, что никто не помнит, зачем она началась. Тратятся часы на оценку, grooming, planning poker, выравнивание целей, построение диаграмм — а под стикером 😞 появляется знакомое «слишком много встреч».

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

От измерения к практике

Продакт-менеджер заканчивает очередное спринт-планирование в 19:15. Команда расходится по домам, на доске остаются цифры: 42 story points, планируемая velocity 38, confidence level 0.7.

Он выключает проектор и думает о Борхесе. Первый акт завершён: Верн показал созидание, Шелли — цену забвения, Холмс — диагностику, Борхес — как аппарат наблюдения сам становится болезнью. Когда измерение-цель разрушает измеряемое.

За окном погасли офисы конкурентов. Где-то есть команды, которые пишут код вместо оценки кода. Которые решают проблемы пользователей вместо оптимизации метрик. Которые не утонули в собственной лотерее.

Тимлид из финтеха в соседнем здании тоже думает об этом, запирая переговорную после ретроспективы. HR-директор летит домой из Стокгольма с пониманием: они копировали инструкцию к самолёту, которого больше нет. CPO дописывает OKR на следующий квартал и знает — это театр, но играть надо.

Ловушка: velocity превращается в оптимизацию velocity, OKR — в ритуал, story points — в философский спор. Результат — вавилонская лотерея, где инструмент пожирает цель.

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

Продолжение следует. В следующей главе: капитан, не проведший ни одного собеседования по регламенту — и собравший лучший экипаж мирового океана. Подводная лодка против авианосца ценой в два триллиона; отбор по способности против отбора по согласованию; и организация, которой не нужна Компания. Лотерея остаётся в Вавилоне. «Наутилус» уходит на глубину.

Footnotes:

¹ Borges, Jorge Luis. «La lotería en Babilonia» (1941). В сборнике Ficciones (1944). Editorial Sur, Buenos Aires (перевод автора).

² Goodhart, Charles A.E. «Problems of Monetary Management: The U.K. Experience.» Papers in Monetary Economics, Reserve Bank of Australia, 1975 (перевод автора).

³ Strathern, Marilyn. «Improving Ratings: Audit in the British University System.» European Review, Vol. 5, No. 3, 1997, pp. 305-321 (перевод автора).

⁴ Digital.ai. «17th Annual State of Agile Report» (2024) (перевод автора). 36% Agile-команд оцениваются по velocity — что создаёт структурный стимул для gaming. Практический анализ velocity gaming: Levison, Mark. «Misuse of Velocity in Agile Projects.» AgilePainRelief.com (перевод автора).

⁵ Borges, Jorge Luis. «La biblioteca de Babel» (1941). В сборнике Ficciones (1944) (перевод автора).

⁶ Kniberg, Henrik & Ivarsson, Anders. «Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds.» Spotify Labs whitepaper, October 2012 (перевод автора).

⁷ Lee, Jeremiah. «Failed #SquadGoals — Spotify doesn't use 'the Spotify model' and neither should you.» jeremiahlee.com, April 2020 (перевод автора). Ли — бывший PM Spotify.

⁸ Kniberg, Henrik. Многолетние публичные напоминания автора: whitepaper 2012 — snapshot конкретного момента, не blueprint. Наиболее известные тексты: интервью Agile Amsterdam 2015; блог crisp.se; повторы в презентациях 2016–2020. Первоисточники цитаты в теле — сам whitepaper (¹⁶) и интервью автора крупным Agile-конференциям.

⁹ Scaled Agile, Inc. SAFe 6.0 Framework. scaledagileframework.com (корпоративный псевдоним).

¹⁰ Rigby, Darrell K.; Sutherland, Jeff; Noble, Andy. «Agile at Scale.» Harvard Business Review, May-June 2018 (перевод автора).

¹¹ Laanti, Marko; Salo, Outi; Abrahamsson, Pekka. «Agile Methods Rapidly Replacing Traditional Methods at Nokia: A Survey of Opinions on Agile Transformation.» Information and Software Technology, Vol. 53, Issue 3, 2011, pp. 276-290 (перевод автора).

¹² Doerr, John. Measure What Matters (2018). Portfolio/Penguin (перевод автора).

¹³ Wodtke, Christina. Radical Focus (2016). Cucina Media (перевод автора).

¹⁴ Muller, Jerry Z. The Tyranny of Metrics (2018). Princeton University Press (перевод автора).

¹⁵ Campbell, Donald T. «Assessing the Impact of Planned Social Change.» Evaluation and Program Planning, Vol. 2, No. 1, 1979, pp. 67-90 (перевод автора).

¹⁶ Accelerate: State of DevOps Report. Google Cloud / DORA, 2023 (перевод автора).