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

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

HOOK: Переговорная №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): «Когда мера становится целью, она перестаёт быть хорошей мерой»². Мэрилин Стрэтерн двадцать два года спустя уточнила — это касается не только экономики, но образования, здравоохранения, управления³.

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

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

Скорость работы команды (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 год, делегация из восьми человек, бюджет командировки €47,000. Цель — внедрить Spotify Model в российском банке.

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

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

Марта перечитывает первый абзац документа: «Это не модель. Это снимок того, как мы работаем. Завтра может измениться»⁶. Предупреждение, которое все игнорируют.

Вечером в отеле она гуглит свежие исследования. Чалмерс, 2015 — диссертация Сундена и Сведенвала показала: реальная Spotify уже отходила от описанной структуры. Squads реорганизовывались, Tribes менялись, Guilds теряли активность⁷. Иеремия Ли (бывший PM Spotify, 2020): документ описывает идеализированное состояние, которого Spotify не достигла⁸.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Март — оценка. Александр ставит себе 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) отмечает: когда разработчики теряют контакт с пользователями, они начинают проектировать систему для себя — точно так же ретроспективы, переставшие что-либо менять, проводятся для самоутешения.

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

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

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

Кэмпбелл, 1979: «Чем больше индикатор используется для решений, тем больше коррупции»¹⁵ — и Agile-метрики представляют собой закон Кэмпбелла в действии, поскольку 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, выравнивание целей, построение диаграмм, а под стикером 😞 появляется знакомое «слишком много встреч».

Борхес: «Эта функционирующая лотерея есть часть реальности. Измеряет ли она что-то реальное — о том я знаю столько же, сколько о самых изощрённых системах»¹ — применительно к корпоративной действительности такой перевод оказывается точным.

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

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

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

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

Лена из финтеха в соседнем здании тоже думает об этом, запирая переговорную после ретроспективы. Марта из «Прогресса» летит домой из Стокгольма с пониманием: они копировали инструкцию к самолёту, которого больше нет. Александр дописывает 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 (перевод автора).

⁷ Sundén, Jeremiah & Svedenwall, Joakim. «Scaling Agile at Spotify: A Case Study.» Master’s thesis, Chalmers University of Technology, 2015 (перевод автора).

⁸ Lee, Jeremiah. «Failed #SquadGoals — Spotify doesn’t use ’the Spotify model’ and neither should you.» jeremiahlee.com, April 2020 (перевод автора).

⁹ 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 (перевод автора).