Мы все привыкли к новым версиям, зачастую они меняются быстрее, чем в них успевают разобраться пользователи. Но этот подход устарел и имеет множество недостатков, далее лонгрид с аргументацией.
1) Пользователям нужно привыкать к новой версии
Люди со временем вырабатывают свою модель взаимодействия с продуктом, пути хождения по сайту, у них возникает привычка.
Когда продукт сильно меняется, эта схема рушится, возникает некий барьер, требуется время на изучение и перестройку. Часть пользователей могут просто отказаться от новой версии, часть будет думать «Зачем это было сделано? Ради чего меняли?». А с этим зачастую возникает проблема и об этом следующий пункт.
2) Изменения ради изменений
Когда затевается новая версия, в нее собирается некая группа улучшений и функций. Они могут быть на основе тестов, гипотез и обратной связи от пользователей. Но, если ее сделать похожей на старую, то это не устроит инициатора процесса и пиарщика. Обычно ими создаются завышенные ожидания, пользователям могут уже пообещать, что будет все круто.
И тогда в новую версию вносятся изменения ради того, чтобы она выглядела как новая: новый дизайн, ненужные функции и разные фичи. Такой подход может привести к отрицательному результату — когда полезные изменения будут перекрыты теми, что были сделаны просто ради изменений.
3) Понять эффективность практически невозможно
В новой версии обычно изменений такое количество, что понять эффективность отдельного не представляется возможным. Даже если как таковой новый функционал или улучшение хороши, то вместе с другими они могут работать не так. Невозможно провести чистый сплит-тест, который покажет почему новая версия лучше старой и что именно на это повлияло. Просто изменилось слишком много. Но эта ситуация не всех пугает, некоторые рады. Например, те, о ком речь в пункте 5.
4) Неизбежные потери при переходе
При запуске новой версии потери есть всегда. Это может быть трафик, страницы в индексе, контент. Может быть долгое переключение DNS между версиями, потери куков пользователей, залогиненных состояний. Список можно продолжать бесконечно, предусмотреть размер этих потерь нельзя, их списывают по факту.
5) Текущие важные изменения не делаются, откладывается до новой версии
Когда становится известно о том, что готовится новая версия, сложные и важные изменения разработчики с удовольствием откладывают до нее (читай до лучших времен). «Вот в новой версии мы все и сделаем по уму» (на самом деле нет). Если сроки новой версии откладываются, то эти изменения откладываются вместе с ней. Таким образом, из-за неготовности новой версии тормозится и сбивается весь процесс разработки. В таком, нервозном режиме возникает серия никому не нужных авралов.
6) Подключаются любители освоить бюджет
Новая версия — любимое детище разного рода начинающих маркетологов и новых сотрудников, отвечающих за сайт. Они с удовольствием этим занимаются, а зачастую начинают работу в новой должности именно с изменения сайта. На это есть простая причина — возможность подключить серьезный бюджет и освоить его. Вопросы эффективности таких любителей волнуют мало, важнее показать себя и сделать нечто выдающееся. Будет ли новая версия таковой — будет известно уже потом, когда бюджет будет уже потрачен и назад дороги нет.
Также, эту ситуацию любят IT-директоры. Самое время запросить обновление ПО, серверной инфраструктуры и добавить сотрудников. Ввиду сложности определения отдачи от таких мероприятий их обычно записывают в некие инвестиции на будущее. Стандартная и лукавая фраза «закладываемся на рост».
7) Велик риск потерять что-то важное
В больших компаниях и проектах взаимодействие с пользователями складывается годами, иногда десятилетиями. Это тонкий и очень сложный механизм. Почему какие-то вещи работают уже все забыли, просто работает и все. По факту старта новой версии может оказаться, что что-то потеряно и работать перестало. Технически все в порядке: кроссбраузерность, технологичность, дизайн — все на высоте. Но показатели продуктивности не те, вот незадача. Найти что именно пошло в ухудшение, а не улучшение в данной ситуации очень сложно, все смешалось.
8) Новая версия всегда запускается с недоработками
Ни один тест не позволит проверить продукт на наличие всех ошибок и глюков. Это можно сделать только на реальной работе и нагрузке. То есть, после запуска так или иначе пройдет процесс зачистки от разных недоработок. Привычный режим работы компании сбивается, возникают непредвиденные задачи. К чему это приводит? К потерям.
И с этими потерями все будут мириться, откатить всю версию назад большой и негативный шаг, на него вряд ли кто-то решится.
9) Двойные затраты — создание новой версии, поддержка текущей
На время создания новой версии идет двойная работа: и текущую надо поддерживать, и заниматься новой. Это сложный и напряженный режим для всей команды проекта и длится он может очень долго. Эти же усилия, направленные на улучшение текущей версии, могут дать значительно больший результат. Мы не говорим о рисках, связанных с неправильным проектированием новой версии, в результате которого она может оказаться просто неработоспособной. Опять же правильная работа с текущей версией этого риска лишена.
А как же концепты?
Все мы видели концепты новых автомобилей. Они красивы и привлекательны, но в серию обычно идут только детали, фрагменты. Именно такова роль концептов — дать новую мысль, идею и проверить ее на жизнеспособность. Поэтому концепты нужны и важны, но не как прямое указание на обновление.
А как же прототипы?
Прототип самая правильная схема работы и управления изменениями, особенно, когда он полный или UX-интерактивный. Я считаю, что прототип должен вестись параллельно любой версии продукта и именно на нем нужно обкатывать и тестировать большие и малые изменения. Те, что себя показали хорошо, можно ставить в план изменений.
Примеры проектов с постепенных изменений
Самый яркий пример, который я всегда привожу, — сайт Booking.com. Он существует больше 15 лет и меняется постоянно. Количество изменений насчитывается тысячами, но все они не сильно заметны пользователям. Однако, если мы сравним сайты 2007-года и 2017-го, то увидим, что они совсем разные.
При этом, никаких новых версий компания не анонсировала. Внутри компании есть даже специальный ролик, показывающий как медленно, но верно менялся сайт с годами. Это и есть концепция постепенных изменений в действии!
Итого
Вышеперечисленные минусы с лихвой покрывают все плюсы, которые есть у новой версии. А чего стоят выкатывания совершенно неузнаваемых версий без предупреждения, без возможности открыть старую, отключение в них привычного функционала и прочие коллизии? Примеров на нашем веку не перечесть.
Да, есть ситуации, когда подход с новыми версиями оправдан: ребрендинг, коллапс текущей системы по производительности, объединения и т.п. Но и в этом случае, в первую очередь стоит задуматься: А не можем ли мы обойтись без глобальных обновлений и сделать все постепенно?
Смотрите также: Как получить максимальный доход с рекламных систем на своем сайте
Комментарии (21)
Tiendil
01.05.2017 12:05+8У автора какое-то странное представление о версиях софта, где-то из 90-ых. Отличия между версиями софта могут быть минорными и так чаще всего и бывает. Не говоря уже о том, что мир софта сведён к разработке сайтов — хотя бы в заголовке отразили. Надо либо кокнретизировать понятие версии либо существенно расширить статью.
Но даже касательно сайтов и прочих порталов — уже давно в крупных проектах отсутствует такое явление, как «версия сайта» — всё разбито на компоненты и микросервисы, которые версионируются отдельно и часто совершенно независимо.
Плюс, нет никакого перечисления минусов предлагаемого подхода (а какой это подход, кстати?), идеальных вещей не бывает.
msts2017
01.05.2017 12:43+3как раз-то в 90х была развита культура версионирования продуктов, тогда и в голову никому не приходило менять версию без кардинальных, порой незаметных внутренних изменений (маркетинг, еще голову не поднял, не заменил столпов компаний), это в 2000х в силу расширения индустрии с наплывом людей понятия не имеющих что это за циферки пошла деградация, квинтэссенция которой подобные статьи.
izhanov
02.05.2017 05:42-11) Если бы не видели постоянных выкатывания больших обновлений большими игроками (особеннно в корпоративном сегменте), то не было бы этой статьи. Пресловутый Кинопоиск просто был самым громким, даже за последнее время таких примеров сотни.
2) О том, что речь в первую очередь о сайтах и приложениях написано в первом предложении статьи.
3) Подход так и называется Теория постепенных изменений, то есть постоянно, незаметно и каждый день. Про минусы согласен, подумаю.
nick_melnychuk
01.05.2017 13:17+1Хорошая публикация. Недавно наступил на эти грабли, и столкнулся c перечисленными минусами.
TimoshkinVlad
01.05.2017 13:17+5Хотелось бы добавить:
1. Постоянные изменения не видны ТОПам. Они через 1-2 года говорят — и за это мы заплатили NNN денег? Да за эти деньги мы бы ух… Поэтому нельзя называть изменения небольшими.
2. Это реально выматывает. У меня за год проходит от 50 ТЗ на одного заказчика. А понять взаимосвязи функционала очень и очень сложно. «Небольшое» изменение может привести к переписыванию очень и очень многого.
3. Незаметность для пользователей. Т.е. система в некоторых случаях начинает вести себя не так, как они привыкли. Тут поле, там кнопка, бизнес-процесс начал ветвиться не так как они привыкли… Да есть документация, и даже лог изменений. Но пользователи ее не читают… Приходится вводить индикаторы, сообщения, проводить презентации.
4. Очистка системы от старого функционала достаточно сложна и о ней нужно думать заранее. Например, логировать кто и что ннажимает и когда. А потом анализировать что не используется.izhanov
02.05.2017 05:49Самый толковый комментарий, спасибо. Добавить нечего и контраргументы не нужны. Коллега выше спрашивал про минусы, вот они, пожалуй, и есть.
WoWtchik
01.05.2017 13:17+1Мне кажется или тут потерялось тестирование?
В принципе все выше перечисленное можно получить и при постепенном изменении, если заменить «Новая версия» на «Новая фича».
1) Пользователям нужно привыкать к новой версии
Пользователям нужно привыкнуть к чему-то новому, что оновилось изменилось, а зачастую и узнать об этом.
Вы поменяли форму ввода, заменив/добавив/удалив поля — все это, то к чему нужно привыкать снова. Если изменения часты, то не у всех будет желание постоянно учиться чему-то новому
2) Изменения ради изменений
Фичи ради фич. «У вон тех есть, а у нас нету давайте добавим»
3) Понять эффективность практически невозможно
Вот тут сложно поспорить, если не будут накладываться сторонние воздействия (обновились браузеры у пользователей и все попломалось). Тут тогда будет большой соблазн сначала нагнать на фичу и ее создателей, откатить (а у нас есть такая возможность?) и только потом разбираться.
4) Неизбежные потери при переходе
При крупных и кардинальных изменениях, а они неизбежны, все то же самое. плюс неизвестно как поведут себя куки и прочие кеши если пользователь был несколько месяцев назад (если они не протухли например)
Новая версия все это компенсирует тем. что пользователь откроет что-то очень новое. А не открыл: там все то же самое, но кое-что не работает и кто знает, как быть.
5) Текущие важные изменения не делаются, откладывается до новой версии
В смысле баги не правятся или что? Если нужны какие-то новые фичи или кардинальная переделка, то тут да новая версия и под нее.
6) Подключаются любители освоить бюджет
Они всегда подключаются. А вот обновление ПО и железа когда закладывать, а в каких объемах, в вашем случае? Если у вас облако, то это не проблема. А если вам нужно добавить на новую фичу совсем чуть-чуть, а вам говорят, что нужно обновить сервер, а то и не один, и попросят на это денег вы «удивитесь и не дадите»?
9) Двойные затраты — создание новой версии, поддержка текущей
Исправление критического бага в текущем модуле, пока пилится заменяемый, тут наврядли можно уйти от этого
С версией есть возможность протестировать ее, в том числе провести A/B тестирование.
А в общем кидаться из одной крайности «1 версия раз в пятилетку» в изменения каждый день не стоит. Частые раз в несколько месяцев версии с возможностью отката, минорки вот это более-менее здравое решение
Если ваш проект это сайт, правильно построенный на микросервисах, с возможностью независимого апдейта с откатом любого микросервиса, под который требует своих мощностей и их пересчета под новую версию. Тогда да можнео постепенно пилить фичи и выкладывать их в безавральном режиме.
Если ваш продукт платформа, которая еще и завязана на пользовательское железо, его мощности, то подход постепенного апдейта применим слабо, так как пользователю будет сложно определить сделает ли новый апдейт невозможным работу или нет и как тогда быть. С версиями проще новая версия — новые требования.izhanov
02.05.2017 05:56Тестирование никуда не потерялось. На больших апдейтах сайтов его проводить практически невозможно, трафика нет. На разных B2B продуктах с тестовыми группами — может быть. И в этом случае оно будет некорректным т.к. непонятно какое именно изменение из ста на что повлияло.
На счет «новая фича». На то она и фича, что небольшая. Не пошла — откатили назад. Откатить большую новую версию — очень серьезный шаг, вероятность этого очень мала и влечет большие потери.
Все это написано в статье.
napa3um
02.05.2017 05:41+1Модель rolling release не лучше или хуже, она применяется для достижения конкретных целей. В каких-то проектах эти цели есть, в каких-то — нет (но есть совершенно другие цели), и потому «релизная» модель разработки может быть более предпочтительной.
Обычно rolling release применяется там, где невозможно (или дорого) синхронизировать процессы разработки всех подсистем разрабатываемой системы, но это требует, как правило, дополнительных соглашений и механизмов, их поддерживающих (разработки «метасистемы»), что в свою очередь требует гораздо больших (и, вероятно, лишних для большинства проектов) усилий, чем «нарезать релизы на спринты».izhanov
02.05.2017 05:58Давайте рассмотрим для каких именно проектов метод постепенных изменений не подходит.
napa3um
02.05.2017 06:06Для любых, живущих дольше своей платформы/архитектуры/парадигмы. Windows 1.0 «докатить» до Windows 10 ролинг релизами не получится, например.
napa3um
02.05.2017 06:20Есть ограничения и со стороны маркетинга/сертификации/дистрибьюции — например, банковское ПО или ПО ракетоносителя ролинг-релизом катить тоже не получится. Прошивки всяких специализированных автономных устройств тоже целесообразнее релизами выпускать, ибо плавно деплоить не получится чисто физически. Синглплеерные игры тоже, как правило, хочется видеть в готовом, законченном виде, а не в виде потока заплаток. В общем, ролинг-релиз — не серебряная пуля «для всех проектов», это просто интуитивное обобщение вашего опыта с несформулированными границами применения и вообще без исследования вопроса (вы не сравнили существующие модели разработки и степени их «плавности», не сформулировали суть вашего предложения относительно какого-то конкретной существующей методологии, которую вы хотели улучшить своими интуициями о ценности ролинг релизов).
izhanov
02.05.2017 17:18Да, вы правы. Много раз писал, что статьями своими не даю решений, а пишу личное мнение для подумать. Прощупываю тенденции, если хотите. Иногда получается даже толково обсудить. Как, например, в этой ветке. Правда, термин роллинг-релиз к моей идее не совсем подходит, тем не менее.
Pakos
02.05.2017 10:05Большой продукт обновлять у клиентов "по каждому чиху" сложно, определить на каком из сотен(тысяч?) точек какая версия невозможно, полное тестирование по каждому коммиту проводить накладно. Версия выпускается не по принципу "каждые 2 недели вынь да полож", а "накопили изменений, или добавили крупную функциональность, или исправили заметный баг" и сделали версию, потом полные тесты, потом выпуск с паспортом и сопутствующими материалами, потом опытная эксплуатация, потом установка. И поддержка не старой версии, а десятка "старых", потому как "нельзя просто взять и обновить версию у клиента", в некоторые места и попасть не просто, по разным причинам. И процесс накатки тоже не прост — надо остановить процесс, дабы провести обновление, а это не Win10, которая может сказать "Пошли вон, холопы, Мы обновляемся".
776166
Самое главное не указали: постепенные небольшие изменения – это то, как устроено в природе. Эволюция с постепенными улучшениями. Это и разработки касается, особенно, если вы не транснациональная корпорация и ваш обычно особо никому ненужный говнопродукт на самом дорогом софте не разрабатывается 100500 девелоперами под управлением over 8000 топ-менеджеров с MBA. В этом случае всё выше описанное получается автоматически. И разработка адекватная, и наследование, и клиенты довольны и косяков мало.
Хотя бывают ситуации, когда новая по-сути, версия де-факто имеет место. Например, если вы меняете технологию.
port443
Мне кажется, с природой не совсем корректно сравнивать ПО. У природы есть масса ограничений, которых нет в ПО. Естественный отбор требует, чтобы любое изменение всегда давало лучший результат; то есть если промежуточные стадии между текущим состоянием и новым, принципиально лучшим, не будут давать монотонно улучшающийся реультат, ничего не выйдет. Поэтому в природе что-то занимает миллионы лет, а что-то выглядит странно. В случае с ПО возможностей намного больше :)
776166
Здесь надо разделить:
1) естественный процесс эволюции ПО
2) изначальное проектирование ПО
3) существенные изменения в ПО
Естественный способ развития — маленькие шажки. Все выгоды очевидны и понятны.
Изначальное проектирование — тут можно сразу заложить некоторые моменты, которые перешагнут через постепенное развитие, например, высокую производительность, если она изначально не нужна. Т.е. вы back-end будете сразу делать на erlang, а не переписывать потом с php. Хотя иногда, имеет смысл начать с php, как с прототипа самой технологии.
А вот существенное изменение ПО — тут уж как получится. Смотря в чём заключается потребность в изменениях. В любом случае, скачкообразные изменения обычно это плохо. Проще сделать новый продукт рядом со старым, который будет поддерживаться какое-то время. В эволюции это тоже заложено, когда виды делятся, или возникают новые ро?ды :)
Одно из самых важных преимуществ перед естественных ходом вещей — осознанные изменения, которые обычно выражаются в глубокой оптимизации, которую можно делать сразу, а не постепенно, и которая сразу даёт преимущество.
izhanov
Эволюционный подход — хороший термин, да.