Компания решила построить внутреннюю платформу аналитики. Продуктовые команды часто обращались к аналитикам за типовыми отчётами, а ответы приходилось ждать несколько дней. Новая платформа должна была дать командам самостоятельный доступ к данным.

Через девять месяцев готовы движок запросов, конструктор отчётов и система прав. Однако продуктовые команды по-прежнему идут к аналитикам. Они не уверены в значении показателей и боятся принять решение по неверным данным. Срок сдвигали дважды, а старая система всё ещё работает параллельно с новой.

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

Мы столько вложили в платформу, что теперь нельзя останавливаться. Нужен ещё один квартал.

Возможно, проект действительно стоит продолжить. Но девять прошедших месяцев ничего не говорят о том, будет ли следующий квартал хорошей инвестицией. Потраченное время уже не вернуть ни продолжением, ни остановкой.

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

Прототипы, проверки гипотез и короткая обратная связь уменьшают этот риск. Их задача не в том, чтобы команда чаще «ошибалась быстро». Они должны приносить важные данные до того, как гипотеза превратится в большой объём кода, бюджет и обещанную дату.

Что именно уже нельзя вернуть

Невозвратные затраты (sunk costs) - это время, деньги и усилия, которые уже потрачены и не изменятся от сегодняшнего решения.

У команды из примера есть как минимум три варианта:

  1. Ещё квартал развивать собственную платформу.
  2. Оставить только готовую инфраструктуру данных, а отчёты собирать в существующем инструменте.
  3. Сначала разобраться с определениями показателей и качеством данных.

Предыдущие девять месяцев одинаковы для всех вариантов. Решение должно зависеть от будущих затрат, вероятности результата, рисков и доступных альтернатив.

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

Разница проходит по времени:

  • «Мы уже потратили 12 человеко-месяцев» - невозвратные затраты.
  • «Готовая система прав сократит следующий этап на месяц» - будущая выгода.
  • «Замена инструмента потребует заново проверить доступ к персональным данным» - будущая стоимость переключения.

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

Почему IT-проекты затягивают решение

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

Проблема начинается, когда команда уже вложила заметные ресурсы, получила отрицательную обратную связь и должна выбрать между продолжением и изменением курса. Если из-за прошлых вложений команда склонна выделить новые ресурсы, исследователи говорят об эскалации обязательств (escalation of commitment).

Хэл Аркес и Кэтрин Блюмер показали этот эффект в серии полевых и сценарных исследований. В одном из них посетители, которые заплатили за театральный абонемент больше, чаще ходили на спектакли в первые месяцы. В других экспериментах прошлые вложения повышали оценку шансов проекта на успех. Авторы связывали это с желанием не выглядеть расточительным. The Psychology of Sunk Cost, 1985.

В разработке к этому желанию добавляются особенности самих проектов.

Код выглядит как прогресс

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

В нашем примере готовый конструктор отчётов не доказывает, что команды смогут принимать решения без аналитиков. Если главное препятствие - недоверие к данным, дополнительный код не приблизит проект к цели.

«Почти готово» скрывает оставшийся риск

Чем ближе проект кажется к завершению, тем привлекательнее ещё одна попытка. В опросе специалистов по аудиту и контролю информационных систем Марк Кейл, Джоан Манн и Арун Рай обнаружили, что близость к завершению лучше других рассмотренных факторов различала проекты с эскалацией и без неё. Авторы оценили, что признаки эскалации встречались в 30-40% описанных IT-проектов.

Это наблюдательное исследование 2000 года, основанное на оценках респондентов. Оно не доказывает, что сегодня ровно треть проектов сталкивается с той же проблемой. Но результат хорошо объясняет опасность фразы «осталось совсем немного»: процент готовности не показывает, снят ли главный риск. Why Software Projects Escalate.

Плохие новости проходят через фильтры

Разработчик говорит, что команды не доверяют отчётам. Руководитель проекта слышит, что нужно улучшить интерфейс. На уровне портфеля это превращается в небольшой риск для сроков.

Если человек, который сообщает о проблеме, становится виновником задержки, команда быстро учится приносить удобные новости. Поэтому sunk cost fallacy - не только личное когнитивное искажение. Его усиливает организация: кто собирает обратную связь, кому разрешено поставить решение под сомнение и что происходит после плохого результата.

Обратная связь должна менять решение

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

Полезный цикл выглядит так:

гипотеза -> дешёвая проверка -> наблюдение -> решение
    ^                                      |
    |________ изменить или уточнить _______|

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

Сначала сформулируйте гипотезу

Фраза «построить платформу аналитики» описывает работу, но не ожидаемый результат. Проверить её можно только бинарно: платформу построили или нет.

Гипотеза связывает изменение с наблюдаемым эффектом:

Если продуктовые команды получат проверенные шаблоны типовых отчётов, они будут реже обращаться к аналитикам и быстрее получать ответы без роста числа ошибочных выводов.

Теперь понятно, что измерять:

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

Собственный конструктор отчётов - лишь один способ проверить эту гипотезу, причём дорогой.

Стройте самый дешёвый источник знания

Прототип - не обязательно маленькая версия будущей системы. Его задача - проверить конкретную неопределённость.

Для платформы аналитики проверки можно провести в таком порядке:

Неопределённость Дешёвая проверка
Действительно ли запросы повторяются Разобрать историю обращений и выделить типовые вопросы
Смогут ли команды работать самостоятельно Вручную подготовить несколько шаблонов в существующем инструменте
Доверяют ли пользователи результату Наблюдать за работой двух команд и разбирать причины обращений за помощью
Выдержит ли технический подход нагрузку Провести изолированный тест на реалистичных данных
Даёт ли решение ожидаемый эффект Запустить ограниченный пилот и сравнить показатели с исходной точкой

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

Стефан Томке изучал эксперименты при проектировании интегральных схем. Подход с меньшим числом итераций потребовал в 2,2 раза больше человеко-месяцев, чем подход с частым созданием прототипов. 43% этой разницы автор связал со стратегией экспериментов. Это не исследование современной веб-разработки, но оно показывает общий механизм: дешёвая проверка помогает обнаружить ошибочное предположение до дорогой части проекта. Managing Experimentation in the Design of New Products.

Задайте критерии до получения результата

Для пилота команда может заранее договориться:

Две продуктовые команды четыре недели работают с пятью типовыми отчётами.

Продолжаем, если:
- команды самостоятельно решают согласованную долю типовых запросов;
- время получения ответа заметно сокращается;
- аналитики не стали чаще исправлять результаты.

Пересматриваем подход, если пользователям по-прежнему
нужна помощь из-за качества данных или неясных определений.

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

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

Как проводить пересмотр проекта

Обычный статус отвечает на вопрос: «Успеваем ли мы выполнить план?» Пересмотр решения спрашивает: «Остаётся ли этот план лучшим способом потратить следующие ресурсы?»

В нашем примере обсуждение должно сравнивать не платформу с пустотой, а несколько будущих вариантов:

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

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

Полезны ещё три организационных правила:

  1. Отделять решение от его автора. Владелец проекта сохраняет контекст, но в пересмотре участвует человек, который не защищает прежнее обещание.
  2. Финансировать следующий вопрос. Сначала проблема, затем опасный технический риск, ограниченный пилот и только после него масштабирование.
  3. Не наказывать за плохие новости. Если отрицательный результат эксперимента считается полезным знанием, у команды меньше причин прятать его за процентом готовности.

Когда продолжение разумно

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

Продолжение платформы разумно, если пилот подтвердил пользу, готовые компоненты заметно уменьшают оставшуюся работу, а альтернативы дороже или рискованнее. Решение должно опираться на эти будущие последствия, а не на желание оправдать девять прошедших месяцев.

Сам эффект тоже зависит от условий. В эксперименте с реальными денежными стимулами Микела Негрини, Арно Ридль и Маттиас Вибрал не обнаружили классического эффекта невозвратных затрат в инвестиционной задаче. Участники, напротив, реже продолжали после большего первоначального вложения, хотя в гипотетических сценариях показывали обычный эффект. Удобный психологический ярлык не заменяет сравнение вариантов. Sunk Cost in Investment Decisions, 2022.

Распознать искажение проще всего по аргументам.

Слабый аргумент:

Нужно закончить конструктор, иначе девять месяцев пропадут.

Сильный аргумент:

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

Во втором случае команда всё ещё может ошибиться в оценке. Но она обсуждает будущее, сравнивает альтернативу и называет условие пересмотра.

Практический вывод

На ближайшем проектном ревью достаточно ответить на пять вопросов:

  1. Какую проблему и для кого должен решить проект?
  2. Какие исходные предположения уже подтвердились или не подтвердились?
  3. Какие варианты доступны с текущего момента, что даст каждый из них и сколько он будет стоить?
  4. Какая дешёвая проверка снимет главную неопределённость?
  5. Какой результат заставит продолжить, изменить или остановить работу?

Отдельно перечислите готовые компоненты, которые пригодятся при любом варианте. Это помогает не путать смену курса с уничтожением всей проделанной работы.

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

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

Исследования и материалы

Комментарии в Telegram-группе!