Как внедрять новые функции, не нанося вреда лояльным пользователям

«Будь проворным; освободить досрочно; часто выпускать». Мы знаем дрель. Но целесообразно ли со стратегической точки зрения часто внедрять новые функции? Особенно после того, как продукт, который вы создаете, достигает определенного размера, вы, вероятно, не захотите рисковать целостностью своего приложения с каждым новым второстепенным выпуском.

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

Дополнительная литература на SmashingMag: ссылка

• Как мы начали выпускать функции в два раза быстрее
• Контрольный список запуска веб-сайта — 15 основных проверок перед запуском
• Ориентированный на пользователя подход к веб-дизайну для мобильных устройств
• Как запустить что угодно

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

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

Заблуждения о новых функциях

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

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

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

Проектирование выбросов: стек пользовательского интерфейса

Как именно мы можем спроектировать выбросы после того, как мы их идентифицировали? Хорошей стратегией является изучение различных состояний пользовательского интерфейса. «Стек пользовательского интерфейса», идея, представленная Скоттом Херффом, универсальна и сложна, и когда мы разрабатываем наши интерфейсы, обычно недостаточно создать макет с точностью до пикселя в Photoshop, Sketch или HTML и CSS — мы должны учитывать различные крайние случаи и состояния: пустое состояние, состояние загрузки, частичное состояние, состояние ошибки и идеальное состояние. Это не так просто, как мы могли бы подумать.

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

Идеальное состояние может значительно отличаться от наших макетов «идеальный результат» — из-за пользовательских предпочтений и выбора браузера пользователя; некоторый контент и веб-шрифты могут не отображаться, например, из-за настроек браузера.

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

Эффект бабочки в развертывании

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

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

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

Эти «молчаливые», едва заметные связи являются причиной того, что развертывание функций затруднено, и почему предсказание далеко идущих последствий изменения часто оказывается упражнением на острое зрение. Вот почему рекомендуется избегать ненужных зависимостей, насколько это возможно, будь то в CSS или JavaScript — они не помогут вам в обслуживании или отладке, особенно если вы полагаетесь на библиотеку, которую вы не полностью понимаете. .

К счастью, чтобы лучше понять влияние изменения, мы можем использовать такие ресурсы, как инструменты разработчика браузера. Мы можем измерить охват селектора или функции JavaScript, и иногда может быть хорошей идеей постоянно возвращаться к ним во время разработки, чтобы область изменения была как можно более локальной и минимальной.

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

Подумайте о дашбордах с карточками, которые можно настраивать (аналитическое ПО), почтовых клиентах с «компактным», «удобным» и «подробным» представлением (Gmail), интерфейсе бронирования, который меняется для вошедших в систему клиентов и гостей, удобстве чтения. для людей, использующих блокировщик рекламы или агрессивный антивирусный фильтр. Эффект бабочки влияет не только на базу кода; все эти внешние факторы также имеют значение, и тестирование на них — в отличие от модульных тестов или QA в целом — очень сложно, потому что мы часто даже не знаем, на что тестировать.

Проверка функции и локальный максимум

Мы можем использовать диагностику и метрики, чтобы определить, какие изменения необходимо внести, но, следуя только данным, вы можете застрять на том, что мы склонны называть «локальным максимумом», состоянием интерфейса с достаточно хорошим дизайном, но совершенно не хватает инноваций, потому что он всегда следует предсказуемым, логическим повторениям. При работе над проектом и изучении данных мы склонны группировать функции в следующие четыре сегмента:

• Сломанные черты. . Функции, которые кажутся сломанными или неэффективными — очевидно, нам нужно их исправить;
• Неиспользуемые функции. . Функции, которые работают по назначению, но редко используются — часто это признак того, что их либо нужно удалить, либо они остро нуждаются в инновациях;
• Неожиданные возможности использования. . Функции, которые используются способом, который сильно отличается от того, что изначально предполагали их создатели, — хороший кандидат на медленную, непрерывную доработку;
• Характеристики рабочей лошадки. . Функции, которые активно используются и, похоже, работают по плану — в этом случае мы спрашиваем себя, есть ли способ еще больше улучшить их UX, параллельно исследуя как медленный итеративный процесс, так и совершенно разные инновационные концепции.

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

Тем не менее, как только выбрана новая итерация или новая идея, может возникнуть соблазн сразу же приступить к разработке или созданию новой функции. Но прежде чем даже думать о том, как функция будет вписываться в существующий интерфейс, рекомендуется сначала проверить идею — с помощью быстрого прототипа и исследования пользователей. Обычный способ добиться этого — использовать быстрый итеративный процесс, такой как дизайн-спринт Google Ventures. Выполнив итерацию в течение пары дней, вы сможете определить, как должна быть реализована новая функция и/или полезна ли она в том виде, в каком вы ее себе представляли изначально.

С помощью дизайнерских спринтов мы заранее подвергаем идею юзабилити-исследованию. В методологии Google Ventures вы будете тестировать дизайн с пятью пользователями в день; затем вы повторяете и проходите еще один раунд тестирования нового дизайна. Причина, по которой задействованы все одни и те же пользователи, заключается в том, что если вы протестируете разный дизайн с каждым пользователем в тот же день, у вас не будет достоверных данных, чтобы узнать, какие элементы должны измениться. Вам нужно несколько пользователей для проверки одной итерации проекта.

Мы применяем немного другую модель в наших спринтах. Когда мы начинаем работать над новой функцией, как только создается ранний первый прототип, мы собираем дизайнеров, разработчиков и команду UX в одной комнате, приглашаем реальных пользователей для тестирования, а затем итерации в сжатые сроки. В первый день первые тестировщики (два-три человека) могут быть назначены на 30-минутное собеседование в 9:00, вторая группа — в 11:00, следующая — в 14:00, а последняя — в 14:00. один около 16:00. В промежутках между опросами пользователей у нас есть «открытые временные окна», когда мы фактически повторяем дизайн и прототип, пока в какой-то момент у нас не получится что-то жизнеспособное.

Причина этого в том, что вначале мы хотим быстро исследовать совершенно разные, иногда даже противоположные направления; как только мы соберем отзывы о разных интерфейсах, мы сможем прийти к тому, что кажется интерфейсом «абсолютного максимума» . Таким образом, мы можем быстрее получать самые разные отзывы об очень разных итерациях дизайна. Обратная связь в основном основана на трех факторах: тепловых картах, которые фиксируют клики пользователей, времени, необходимом пользователям для выполнения задачи, и том, насколько приятным для них является опыт. Позже на этой неделе мы продолжаем работать с большим количеством пользователей, как это делает Google, постоянно проверяя новый дизайн по ходу работы.

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

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

Восемь уровней тестирования

Итак, как же нам эффективно предотвратить проникновение ошибок и сбоев в реальную живую среду? Сколько проверок, обзоров и тестов мы проводим, прежде чем функция будет развернута? И в какой последовательности мы запускаем эти тесты? Другими словами, как будет выглядеть окончательная стратегия развертывания функций?

Одну из лучших стратегий для развертывания функций предложил Андрей Сумин, руководитель отдела разработки Mail.ru, крупного почтового провайдера в России. Стратегия применима не ко всем проектам, но это разумный и комплексный подход для компаний, предлагающих продукты среднего и крупного размера тысячам клиентов.

Давайте подробно рассмотрим стратегию и рассмотрим восемь шагов внедрения функции, охватывающих процесс разработки продукта Mail.ru:

1. тест с разработчиками,
2. тестирование с реальными пользователями в контролируемой среде,
3. тестирование с пользователями всей компании,
4. тестировать с бета-тестерами,
5. протестировать с пользователями, которые включились вручную,
6. сплит-тест и проверка удержания,
7. отпускайте медленно и постепенно,
8. измерить последствия.

В случае с Mail.ru самая важная функция, которую нужно сохранить независимо от того, из чего состоит сообщение (очевидно). Это наиболее часто используемая часть интерфейса, и о том, чтобы он был недоступен или работал некорректно даже в течение нескольких секунд, было бы абсолютно исключено. Итак, что, если бы мы захотели расширить функциональность текстовой области, возможно, добавив несколько интеллектуальных функций автозаполнения, или счетчик, или боковой предварительный просмотр?

1. Протестируйте с разработчиками

Чем больше времени проходит в разработке, тем дороже становится решение проблемы. Опять же, подумайте о том, как связаны все решения в разработке продукта; чем совершеннее продукт, тем больше решений приходится пересматривать, что требует времени и ресурсов. Таким образом, раннее выявление и решение проблем важно как с точки зрения бизнеса, так и с точки зрения проектирования и разработки.

Однако вы не можете отладить идею, поэтому первоначальное тестирование должно проводиться во время производства, на самых первых прототипах. Таким образом, первые тестировщики в Mail.ru — это разработчики, которые собственно и пишут код. Компания поощряет своих сотрудников использовать продукт для внутреннего общения (и даже для личного общения); таким образом, разработчики могут считаться ярыми пользователями продукта.

Первый шаг вполне очевиден: спроектируйте и создайте функцию, а затем локально протестируйте, просмотрите и разверните ее на промежуточном сервере. Именно здесь вступает в действие тестирование QA с комплексными инструментами и исполнителями задач, которые пытаются сломать функцию и интерфейс, потенциально автоматизированными с помощью инструментов тестирования обезьян, таких как Gremlins.js.

Результаты отслеживаются, а затем возвращаются в цикл обратной связи для следующей итерации функции. В какой-то момент разработчики будут чувствовать себя вполне уверенно со сборкой: вроде бы изменение работает, как и ожидалось, и требования соблюдены. Именно тогда начинается настоящее пользовательское тестирование.

2. Тестируйте с реальными пользователями в контролируемой среде

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

Однако тестируется не только новая функция; цель юзабилити-теста — убедиться, что новая функция не влияет на критические компоненты интерфейса, поэтому пользователи выполняют рутинные задачи, такие как составление сообщения и открытие, ответ и просмотр электронных писем в своем почтовом ящике. Если и новая, и старая функции хорошо изучены, процесс можно продолжить.

3. Протестируйте с пользователями всей компании

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

При тестировании нет особенно большой разницы между пользователями в «удаленных» отделах компании и пользователями в дикой природе. Даже внутренние пользователи не знают, каких изменений ожидать, или точно не знают, что делает функция или как она должна работать или выглядеть. Единственное основное отличие состоит в том, что коллегам может быть предложено быстро отправить отзыв или оставить комментарий. Именно тогда вводятся формы голосования. Тестировщики могут не только играть с этой функцией, но и добавлять комментарии, а также голосовать за или против. Голосование должно сопоставляться со стратегией продукта и бизнес-требованиями, но если пользователи явно находят функцию бесполезной или полезной, это простой и эффективный способ собрать отзывы и проверить, работает ли продукт так, как ожидалось.

4. Протестируйте с помощью бета-тестеров

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

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

Однако вам нужны критерии, чтобы определить, достаточно ли продвинут пользователь, чтобы быть бета-тестером. В случае с почтовым клиентом это может быть кто-то, кто использует Chrome или Firefox (т. е. знает, как изменить браузер по умолчанию), кто создал более трех папок в своем почтовом ящике, а также установил мобильное приложение.

5. Протестируйте пользователей, которые включились вручную

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

В случае с Mail.ru следующим шагом будет развертывание функции в живом интерфейсе с пометкой и отправка электронной почты этому более широкому сегменту активных пользователей с представлением новой функции и приглашением активировать ее на своих устройствах. собственный в интерфейсе, обычно с блестящей кнопкой «Обновить». Чтобы измерить ценность функции для реальных пользователей, команда снова использует систему голосования, с несколькими подсказками здесь и там, в основном спрашивая пользователей, считают ли они функцию полезной или полезной. Обратите внимание, что разница между этим уровнем и предыдущим уровнем заключается в том, что ручная подписка включает гораздо большую аудиторию, многие из которых вообще не разбираются в технических вопросах, в отличие от бета-тестеров.

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

6. Сплит-тест и проверка удержания

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

Чтобы убедиться, что вы не нарушаете привычки пассивных пользователей, вы можете провести сплит-тестирование с тремя небольшими сегментами пользователей и измерить удержание . В конце концов, вы хотите убедиться, что новая версия работает не хуже предыдущей. Определите наиболее важные действия в интерфейсе и измерьте не только то, сколько времени пользователи тратят на это до и после развертывания, но и сколько времени проходит до их возвращения. В случае с Mail.ru удержание предполагает, что пользователи проверяют свою электронную почту и составляют сообщение. Чем чаще пользователь возвращается, тем выше показатель удержания, что является показателем лучшего UX.

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

7. Отпускайте медленно и постепенно

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

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

8. Измерьте последствия

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

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

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

Заключение

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

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