- PVSM.RU - https://www.pvsm.ru -
Статья о том, почему множество мелких, последовательных улучшений сайта/приложения или другого IT-продукта лучше, чем одно большое в виде новой версии.
Мы все привыкли к новым версиям, зачастую они меняются быстрее, чем в них успевают разобраться пользователи. Но этот подход устарел и имеет множество недостатков, далее лонгрид с аргументацией.
Люди со временем вырабатывают свою модель взаимодействия с продуктом, пути хождения по сайту, у них возникает привычка.
Когда продукт сильно меняется, эта схема рушится, возникает некий барьер, требуется время на изучение и перестройку. Часть пользователей могут просто отказаться от новой версии, часть будет думать «Зачем это было сделано? Ради чего меняли?». А с этим зачастую возникает проблема и об этом следующий пункт.
Когда затевается новая версия, в нее собирается некая группа улучшений и функций. Они могут быть на основе тестов, гипотез и обратной связи от пользователей. Но, если ее сделать похожей на старую, то это не устроит инициатора процесса и пиарщика. Обычно ими создаются завышенные ожидания, пользователям могут уже пообещать, что будет все круто.
И тогда в новую версию вносятся изменения ради того, чтобы она выглядела как новая: новый дизайн, ненужные функции и разные фичи. Такой подход может привести к отрицательному результату — когда полезные изменения будут перекрыты теми, что были сделаны просто ради изменений.
В новой версии обычно изменений такое количество, что понять эффективность отдельного не представляется возможным. Даже если как таковой новый функционал или улучшение хороши, то вместе с другими они могут работать не так. Невозможно провести чистый сплит-тест, который покажет почему новая версия лучше старой и что именно на это повлияло. Просто изменилось слишком много. Но эта ситуация не всех пугает, некоторые рады. Например, те, о ком речь в пункте 5.
При запуске новой версии потери есть всегда. Это может быть трафик, страницы в индексе, контент. Может быть долгое переключение DNS между версиями, потери куков пользователей, залогиненных состояний. Список можно продолжать бесконечно, предусмотреть размер этих потерь нельзя, их списывают по факту.
Когда становится известно о том, что готовится новая версия, сложные и важные изменения разработчики с удовольствием откладывают до нее (читай до лучших времен). «Вот в новой версии мы все и сделаем по уму» (на самом деле нет). Если сроки новой версии откладываются, то эти изменения откладываются вместе с ней. Таким образом, из-за неготовности новой версии тормозится и сбивается весь процесс разработки. В таком, нервозном режиме возникает серия никому не нужных авралов.
Новая версия — любимое детище разного рода начинающих маркетологов и новых сотрудников, отвечающих за сайт. Они с удовольствием этим занимаются, а зачастую начинают работу в новой должности именно с изменения сайта. На это есть простая причина — возможность подключить серьезный бюджет и освоить его. Вопросы эффективности таких любителей волнуют мало, важнее показать себя и сделать нечто выдающееся. Будет ли новая версия таковой — будет известно уже потом, когда бюджет будет уже потрачен и назад дороги нет.
Также, эту ситуацию любят IT-директоры. Самое время запросить обновление ПО, серверной инфраструктуры и добавить сотрудников. Ввиду сложности определения отдачи от таких мероприятий их обычно записывают в некие инвестиции на будущее. Стандартная и лукавая фраза «закладываемся на рост».
В больших компаниях и проектах взаимодействие с пользователями складывается годами, иногда десятилетиями. Это тонкий и очень сложный механизм. Почему какие-то вещи работают уже все забыли, просто работает и все. По факту старта новой версии может оказаться, что что-то потеряно и работать перестало. Технически все в порядке: кроссбраузерность, технологичность, дизайн — все на высоте. Но показатели продуктивности не те, вот незадача. Найти что именно пошло в ухудшение, а не улучшение в данной ситуации очень сложно, все смешалось.
Ни один тест не позволит проверить продукт на наличие всех ошибок и глюков. Это можно сделать только на реальной работе и нагрузке. То есть, после запуска так или иначе пройдет процесс зачистки от разных недоработок. Привычный режим работы компании сбивается, возникают непредвиденные задачи. К чему это приводит? К потерям.
И с этими потерями все будут мириться, откатить всю версию назад большой и негативный шаг, на него вряд ли кто-то решится.
На время создания новой версии идет двойная работа: и текущую надо поддерживать, и заниматься новой. Это сложный и напряженный режим для всей команды проекта и длится он может очень долго. Эти же усилия, направленные на улучшение текущей версии, могут дать значительно больший результат. Мы не говорим о рисках, связанных с неправильным проектированием новой версии, в результате которого она может оказаться просто неработоспособной. Опять же правильная работа с текущей версией этого риска лишена.
Все мы видели концепты новых автомобилей. Они красивы и привлекательны, но в серию обычно идут только детали, фрагменты. Именно такова роль концептов — дать новую мысль, идею и проверить ее на жизнеспособность. Поэтому концепты нужны и важны, но не как прямое указание на обновление.
Прототип самая правильная схема работы и управления изменениями, особенно, когда он полный или UX-интерактивный [1]. Я считаю, что прототип должен вестись параллельно любой версии продукта и именно на нем нужно обкатывать и тестировать большие и малые изменения. Те, что себя показали хорошо, можно ставить в план изменений.
Самый яркий пример, который я всегда привожу, — сайт Booking.com. Он существует больше 15 лет и меняется постоянно. Количество изменений насчитывается тысячами, но все они не сильно заметны пользователям. Однако, если мы сравним сайты 2007-года [2] и 2017-го [3], то увидим, что они совсем разные.
При этом, никаких новых версий компания не анонсировала. Внутри компании есть даже специальный ролик, показывающий как медленно, но верно менялся сайт с годами. Это и есть концепция постепенных изменений в действии!
Вышеперечисленные минусы с лихвой покрывают все плюсы, которые есть у новой версии. А чего стоят выкатывания совершенно неузнаваемых версий без предупреждения, без возможности открыть старую, отключение в них привычного функционала и прочие коллизии? Примеров на нашем веку не перечесть.
Да, есть ситуации, когда подход с новыми версиями оправдан: ребрендинг, коллапс текущей системы по производительности, объединения и т.п. Но и в этом случае, в первую очередь стоит задуматься: А не можем ли мы обойтись без глобальных обновлений и сделать все постепенно?
Смотрите также: Как получить максимальный доход с рекламных систем на своем сайте
Автор: Марат Ижанов
Источник [4]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/novaya-versiya/254141
Ссылки в тексте:
[1] полный или UX-интерактивный: https://habrahabr.ru/post/323156/
[2] 2007-года: https://web.archive.org/web/20070423192741/booking.com
[3] 2017-го: https://www.booking.com
[4] Источник: https://habrahabr.ru/post/327672/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best
Нажмите здесь для печати.