Статья о том, почему множество мелких, последовательных улучшений сайта/приложения или другого IT-продукта лучше, чем одно большое в виде новой версии.
Мы все привыкли к новым версиям, зачастую они меняются быстрее, чем в них успевают разобраться пользователи. Но этот подход устарел и имеет множество недостатков, далее лонгрид с аргументацией.
1) Пользователям нужно привыкать к новой версии
Люди со временем вырабатывают свою модель взаимодействия с продуктом, пути хождения по сайту, у них возникает привычка.
Когда продукт сильно меняется, эта схема рушится, возникает некий барьер, требуется время на изучение и перестройку. Часть пользователей могут просто отказаться от новой версии, часть будет думать «Зачем это было сделано? Ради чего меняли?». А с этим зачастую возникает проблема и об этом следующий пункт.
2) Изменения ради изменений
Когда затевается новая версия, в нее собирается некая группа улучшений и функций. Они могут быть на основе тестов, гипотез и обратной связи от пользователей. Но, если ее сделать похожей на старую, то это не устроит инициатора процесса и пиарщика. Обычно ими создаются завышенные ожидания, пользователям могут уже пообещать, что будет все круто.
И тогда в новую версию вносятся изменения ради того, чтобы она выглядела как новая: новый дизайн, ненужные функции и разные фичи. Такой подход может привести к отрицательному результату — когда полезные изменения будут перекрыты теми, что были сделаны просто ради изменений.
3) Понять эффективность практически невозможно
В новой версии обычно изменений такое количество, что понять эффективность отдельного не представляется возможным. Даже если как таковой новый функционал или улучшение хороши, то вместе с другими они могут работать не так. Невозможно провести чистый сплит-тест, который покажет почему новая версия лучше старой и что именно на это повлияло. Просто изменилось слишком много. Но эта ситуация не всех пугает, некоторые рады. Например, те, о ком речь в пункте 5.
4) Неизбежные потери при переходе
При запуске новой версии потери есть всегда. Это может быть трафик, страницы в индексе, контент. Может быть долгое переключение DNS между версиями, потери куков пользователей, залогиненных состояний. Список можно продолжать бесконечно, предусмотреть размер этих потерь нельзя, их списывают по факту.
5) Текущие важные изменения не делаются, откладывается до новой версии
Когда становится известно о том, что готовится новая версия, сложные и важные изменения разработчики с удовольствием откладывают до нее (читай до лучших времен). «Вот в новой версии мы все и сделаем по уму» (на самом деле нет). Если сроки новой версии откладываются, то эти изменения откладываются вместе с ней. Таким образом, из-за неготовности новой версии тормозится и сбивается весь процесс разработки. В таком, нервозном режиме возникает серия никому не нужных авралов.
6) Подключаются любители освоить бюджет
Новая версия — любимое детище разного рода начинающих маркетологов и новых сотрудников, отвечающих за сайт. Они с удовольствием этим занимаются, а зачастую начинают работу в новой должности именно с изменения сайта. На это есть простая причина — возможность подключить серьезный бюджет и освоить его. Вопросы эффективности таких любителей волнуют мало, важнее показать себя и сделать нечто выдающееся. Будет ли новая версия таковой — будет известно уже потом, когда бюджет будет уже потрачен и назад дороги нет.
Также, эту ситуацию любят IT-директоры. Самое время запросить обновление ПО, серверной инфраструктуры и добавить сотрудников. Ввиду сложности определения отдачи от таких мероприятий их обычно записывают в некие инвестиции на будущее. Стандартная и лукавая фраза «закладываемся на рост».
7) Велик риск потерять что-то важное
В больших компаниях и проектах взаимодействие с пользователями складывается годами, иногда десятилетиями. Это тонкий и очень сложный механизм. Почему какие-то вещи работают уже все забыли, просто работает и все. По факту старта новой версии может оказаться, что что-то потеряно и работать перестало. Технически все в порядке: кроссбраузерность, технологичность, дизайн — все на высоте. Но показатели продуктивности не те, вот незадача. Найти что именно пошло в ухудшение, а не улучшение в данной ситуации очень сложно, все смешалось.
8) Новая версия всегда запускается с недоработками
Ни один тест не позволит проверить продукт на наличие всех ошибок и глюков. Это можно сделать только на реальной работе и нагрузке. То есть, после запуска так или иначе пройдет процесс зачистки от разных недоработок. Привычный режим работы компании сбивается, возникают непредвиденные задачи. К чему это приводит? К потерям.
И с этими потерями все будут мириться, откатить всю версию назад большой и негативный шаг, на него вряд ли кто-то решится.
9) Двойные затраты — создание новой версии, поддержка текущей
На время создания новой версии идет двойная работа: и текущую надо поддерживать, и заниматься новой. Это сложный и напряженный режим для всей команды проекта и длится он может очень долго. Эти же усилия, направленные на улучшение текущей версии, могут дать значительно больший результат. Мы не говорим о рисках, связанных с неправильным проектированием новой версии, в результате которого она может оказаться просто неработоспособной. Опять же правильная работа с текущей версией этого риска лишена.
А как же концепты?
Все мы видели концепты новых автомобилей. Они красивы и привлекательны, но в серию обычно идут только детали, фрагменты. Именно такова роль концептов — дать новую мысль, идею и проверить ее на жизнеспособность. Поэтому концепты нужны и важны, но не как прямое указание на обновление.
А как же прототипы?
Прототип самая правильная схема работы и управления изменениями, особенно, когда он полный или UX-интерактивный. Я считаю, что прототип должен вестись параллельно любой версии продукта и именно на нем нужно обкатывать и тестировать большие и малые изменения. Те, что себя показали хорошо, можно ставить в план изменений.
Примеры проектов с постепенных изменений
Самый яркий пример, который я всегда привожу, — сайт Booking.com. Он существует больше 15 лет и меняется постоянно. Количество изменений насчитывается тысячами, но все они не сильно заметны пользователям. Однако, если мы сравним сайты 2007-года и 2017-го, то увидим, что они совсем разные.
При этом, никаких новых версий компания не анонсировала. Внутри компании есть даже специальный ролик, показывающий как медленно, но верно менялся сайт с годами. Это и есть концепция постепенных изменений в действии!
Итого
Вышеперечисленные минусы с лихвой покрывают все плюсы, которые есть у новой версии. А чего стоят выкатывания совершенно неузнаваемых версий без предупреждения, без возможности открыть старую, отключение в них привычного функционала и прочие коллизии? Примеров на нашем веку не перечесть.
Да, есть ситуации, когда подход с новыми версиями оправдан: ребрендинг, коллапс текущей системы по производительности, объединения и т.п. Но и в этом случае, в первую очередь стоит задуматься: А не можем ли мы обойтись без глобальных обновлений и сделать все постепенно?
Смотрите также: Как получить максимальный доход с рекламных систем на своем сайте
Автор: Марат Ижанов
