Verschlimmbesserung: почему обновления делают продукт хуже
Автор поста отталкивается от немецкого слова Verschlimmbesserung, попытки улучшить что-то, которая только делает хуже. Знакомая ситуация: очередное обновление SaaS-продукта переносит кнопку, переименовывает пункт меню и ломает привычный рабочий процесс, команда выпустила «улучшенный опыт», который решил проблему, которой ни у кого не было.
Причину автор находит не в некомпетентности разработчиков, а в системе оценки труда. Он приводит слова Элияху Голдратта: «Скажи мне, как ты меня оцениваешь, и я скажу тебе, как буду себя вести. Если ты оцениваешь меня нелогично… не жалуйся на нелогичное поведение». Когда для компании важнее сам факт очередного точечного релиза, чем состояние продукта, она тем самым поощряет Verschlimmbesserung. Инженерные команды, по мнению автора, не проваливают работу, они просто оптимизируются под метрики, которые им задали: если метрика вознаграждает отток пользователей (churn), получаешь отток; если вознаграждает сам факт выпуска релиза, получаешь релизы, независимо от того, стали ли они кому-то лучше.
Автор ставит под сомнение установку «новое всегда лучше»: Office 2003 остаётся полезным именно потому, что его не заставляли бесконечно переизобретать себя. Вывод поста: стабильность, тоже функция продукта, а умение вовремя не выпустить релиз, отдельная инженерная дисциплина. У немецкого языка есть для этого явления отдельное слово, и автор предлагает начать использовать его и в остальном мире.
Ключевые факты
- Немецкое слово Verschlimmbesserung означает попытку улучшения, которая только ухудшает вещь, автор применяет его к софтверным обновлениям.
- Пример из текста: обновление SaaS переносит кнопку, переименовывает меню и ломает привычный рабочий процесс, то есть решает проблему, которой не было.
- Причина, по мнению автора, не в командах, а в метриках: если систему поощрений строят вокруг частоты релизов или оттока, команды и оптимизируются именно под это, а не под пользу для продукта.
- Приводится цитата Элияху Голдратта о том, что способ измерения определяет поведение того, кого измеряют.
- Office 2003 назван примером продукта, который остаётся полезным именно потому, что его не заставляли постоянно меняться; вывод, стабильность тоже функция, а решение не выпускать релиз, инженерная дисциплина.
Почему это важно
Пост формулирует претензию, знакомую почти каждому пользователю софта: регулярные обновления не всегда делают продукт лучше, а иногда прямо портят привычный опыт. Автор предлагает не списывать это на неудачные решения дизайнеров, а искать причину в том, как компания оценивает инженерные команды: если метрика поощряет сам факт релиза или отток пользователей, а не реальную пользу для пользователя, обновления ради обновлений становятся рациональным поведением команды, а не сбоем.
Кому это важно
Материал адресован руководителям продукта и инженерии, которые задают метрики для команд, количество релизов, частоту обновлений, показатели вовлечённости. Он также важен для инженерных команд, которые выполняют KPI по числу изменений, даже когда с их профессиональной точки зрения продукт в устойчивом состоянии и не нуждается в правках.
Как это применить
Практический вывод из текста, пересматривать метрики так, чтобы стабильность и отсутствие ненужных изменений засчитывались как валидный результат работы команды, а не как простой. Автор явно указывает на риск: если единственная измеряемая величина, это факт выпуска релиза, команда будет выпускать релизы вне зависимости от того, улучшают ли они продукт.
Можно ли доверять
Это авторская колонка, а не исследование: в тексте нет ни одного конкретного примера компании или продукта, ни цифр о частоте подобных случаев или их стоимости, идея иллюстрируется общим сценарием «перенесли кнопку, переименовали меню» и цитатой Элияху Голдратта, известного по теории ограничений. Аргумент опирается на наблюдение и логику, а не на данные, поэтому стоит воспринимать его как тезис для обсуждения, а не как доказанный факт.
Риски и подводные камни
Автор не называет, кто именно в компании задаёт метрики частоты релизов, формулировка обращена к обобщённому «вы» (подразумеваются руководители продукта и инженерии), что оставляет тезис довольно абстрактным. Есть и обратный риск, о котором пост не говорит: если довести идею до крайности и вовсе отказаться от частых обновлений, можно упустить реальные улучшения или отстать от нужд пользователей, грань между полезной стабильностью и застоем сам текст не проводит.
«Скажи мне, как ты меня оцениваешь, и я скажу тебе, как буду себя вести. Если ты оцениваешь меня нелогично… не жалуйся на нелогичное поведение…»
— Элияху Голдратт