H Теория постепенных изменений или почему понятие «новая версия» должно уйти в прошлое в черновиках

Статья о том, почему множество мелких, последовательных улучшений сайта/приложения или другого IT-продукта лучше, чем одно большое в виде новой версии. Мы все привыкли к новым версиям, зачастую они меняются быстрее, чем в них успевают разобраться пользователи. Но этот подход устарел и имеет множество недостатков, далее лонгрид с аргументацией.

Люди со временем вырабатывают свою модель взаимодействия с продуктом, пути хождения по сайту, у них возникает привычка. Когда продукт сильно меняется, эта схема рушится, возникает некий барьер, требуется время на изучение и перестройку. Часть пользователей могут просто отказаться от новой версии, часть будет думать «Зачем это было сделано? Ради чего меняли?». А с этим зачастую возникает проблема и об этом следующий пункт.

Когда затевается новая версия, в нее собирается некая группа улучшений и функций. Они могут быть на основе тестов, гипотез и обратной связи от пользователей. Но, если ее сделать похожей на старую, то это не устроит инициатора процесса и пиарщика. Обычно ими создаются завышенные ожидания, пользователям могут уже пообещать, что будет все круто. И тогда в новую версию вносятся изменения ради того, чтобы она выглядела как новая: новый дизайн, ненужные функции и разные фичи. Такой подход может привести к отрицательному результату — когда полезные изменения будут перекрыты теми, что были сделаны просто ради изменений.

В новой версии обычно изменений такое количество, что понять эффективность отдельного не представляется возможным. Даже если как таковой новый функционал или улучшение хороши, то вместе с другими они могут работать не так. Невозможно провести чистый сплит-тест, который покажет почему новая версия лучше старой и что именно на это повлияло. Просто изменилось слишком много. Но эта ситуация не всех пугает, некоторые рады. Например, те, о ком речь в пункте 5.

При запуске новой версии потери есть всегда. Это может быть трафик, страницы в индексе, контент. Может быть долгое переключение DNS между версиями, потери куков пользователей, залогиненных состояний. Список можно продолжать бесконечно, предусмотреть размер этих потерь нельзя, их списывают по факту.

Когда становится известно о том, что готовится новая версия, сложные и важные изменения разработчики с удовольствием откладывают до нее (читай до лучших времен). «Вот в новой версии мы все и сделаем по уму» (на самом деле нет). Если сроки новой версии откладываются, то эти изменения откладываются вместе с ней. Таким образом, из-за неготовности новой версии тормозится и сбивается весь процесс разработки. В таком, нервозном режиме возникает серия никому не нужных авралов.

Новая версия — любимое детище разного рода начинающих маркетологов и новых сотрудников, отвечающих за сайт. Они с удовольствием этим занимаются, а зачастую начинают работу в новой должности именно с изменения сайта. На это есть простая причина — возможность подключить серьезный бюджет и освоить его. Вопросы эффективности таких любителей волнуют мало, важнее показать себя и сделать нечто выдающееся. Будет ли новая версия таковой — будет известно уже потом, когда бюджет будет уже потрачен и назад дороги нет. Также, эту ситуацию любят IT-директоры. Самое время запросить обновление ПО, серверной инфраструктуры и добавить сотрудников. Ввиду сложности определения отдачи от таких мероприятий их обычно записывают в некие инвестиции на будущее. Стандартная и лукавая фраза «закладываемся на рост».

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

Ни один тест не позволит проверить продукт на наличие всех ошибок и глюков. Это можно сделать только на реальной работе и нагрузке. То есть, после запуска так или иначе пройдет процесс зачистки от разных недоработок. Привычный режим работы компании сбивается, возникают непредвиденные задачи. К чему это приводит? К потерям. И с этими потерями все будут мириться, откатить всю версию назад большой и негативный шаг, на него вряд ли кто-то решится.

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

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

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

Самый яркий пример, который я всегда привожу, — сайт Booking.com. Он существует больше 15 лет и меняется постоянно. Количество изменений насчитывается тысячами, но все они не сильно заметны пользователям. Однако, если мы сравним сайты 2007-года и 2017-го, то увидим, что они совсем разные.

При этом, никаких новых версий компания не анонсировала. Внутри компании есть даже специальный ролик, показывающий как медленно, но верно менялся сайт с годами. Это и есть концепция постепенных изменений в действии!

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

комментарии ( 21 )

Здесь надо разделить: 1) естественный процесс эволюции ПО 2) изначальное проектирование ПО 3) существенные изменения в ПО

Естественный способ развития — маленькие шажки. Все выгоды очевидны и понятны. Изначальное проектирование — тут можно сразу заложить некоторые моменты, которые перешагнут через постепенное развитие, например, высокую производительность, если она изначально не нужна. Т.е. вы back-end будете сразу делать на erlang, а не переписывать потом с php. Хотя иногда, имеет смысл начать с php, как с прототипа самой технологии. А вот существенное изменение ПО — тут уж как получится. Смотря в чём заключается потребность в изменениях. В любом случае, скачкообразные изменения обычно это плохо. Проще сделать новый продукт рядом со старым, который будет поддерживаться какое-то время. В эволюции это тоже заложено, когда виды делятся, или возникают новые ро́ды :)

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

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

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

Плюс, нет никакого перечисления минусов предлагаемого подхода (а какой это подход, кстати?), идеальных вещей не бывает.

Мне кажется или тут потерялось тестирование? В принципе все выше перечисленное можно получить и при постепенном изменении, если заменить «Новая версия» на «Новая фича». 1) Пользователям нужно привыкать к новой версии Пользователям нужно привыкнуть к чему-то новому, что оновилось изменилось, а зачастую и узнать об этом. Вы поменяли форму ввода, заменив/добавив/удалив поля — все это, то к чему нужно привыкать снова. Если изменения часты, то не у всех будет желание постоянно учиться чему-то новому 2) Изменения ради изменений Фичи ради фич. «У вон тех есть, а у нас нету давайте добавим» 3) Понять эффективность практически невозможно Вот тут сложно поспорить, если не будут накладываться сторонние воздействия (обновились браузеры у пользователей и все попломалось). Тут тогда будет большой соблазн сначала нагнать на фичу и ее создателей, откатить (а у нас есть такая возможность?) и только потом разбираться. 4) Неизбежные потери при переходе При крупных и кардинальных изменениях, а они неизбежны, все то же самое. плюс неизвестно как поведут себя куки и прочие кеши если пользователь был несколько месяцев назад (если они не протухли например) Новая версия все это компенсирует тем. что пользователь откроет что-то очень новое. А не открыл: там все то же самое, но кое-что не работает и кто знает, как быть. 5) Текущие важные изменения не делаются, откладывается до новой версии В смысле баги не правятся или что? Если нужны какие-то новые фичи или кардинальная переделка, то тут да новая версия и под нее. 6) Подключаются любители освоить бюджет Они всегда подключаются. А вот обновление ПО и железа когда закладывать, а в каких объемах, в вашем случае? Если у вас облако, то это не проблема. А если вам нужно добавить на новую фичу совсем чуть-чуть, а вам говорят, что нужно обновить сервер, а то и не один, и попросят на это денег вы «удивитесь и не дадите»? 9) Двойные затраты — создание новой версии, поддержка текущей Исправление критического бага в текущем модуле, пока пилится заменяемый, тут наврядли можно уйти от этого

С версией есть возможность протестировать ее, в том числе провести A/B тестирование. А в общем кидаться из одной крайности «1 версия раз в пятилетку» в изменения каждый день не стоит. Частые раз в несколько месяцев версии с возможностью отката, минорки вот это более-менее здравое решение Если ваш проект это сайт, правильно построенный на микросервисах, с возможностью независимого апдейта с откатом любого микросервиса, под который требует своих мощностей и их пересчета под новую версию. Тогда да можнео постепенно пилить фичи и выкладывать их в безавральном режиме. Если ваш продукт платформа, которая еще и завязана на пользовательское железо, его мощности, то подход постепенного апдейта применим слабо, так как пользователю будет сложно определить сделает ли новый апдейт невозможным работу или нет и как тогда быть. С версиями проще новая версия — новые требования.

Тестирование никуда не потерялось. На больших апдейтах сайтов его проводить практически невозможно, трафика нет. На разных B2B продуктах с тестовыми группами — может быть. И в этом случае оно будет некорректным т.к. непонятно какое именно изменение из ста на что повлияло.

На счет «новая фича». На то она и фича, что небольшая. Не пошла — откатили назад. Откатить большую новую версию — очень серьезный шаг, вероятность этого очень мала и влечет большие потери.