Я немного устал от фразы “Выйдите из здания”.
Не поймите меня неправильно. Это безумно важная концепция. Если вы не знакомы со Стивом Бланком и Эриком Рисом и всей методологией бережливого стартапа, вы должны обязательно познакомиться. Это хороший материал.
Стив и Эрик много говорят о выходе из здания, и для этого есть отличная причина. Выход из здания - отличный способ создавать продукты, которые люди захотят покупать. К сожалению, иногда легче понять важность чего-либо, чем применить это на практике.
Конечно, цель выхода из здания - улучшить контакт с вашими пользователями. Если у вас есть вопрос о том, как должен работать ваш продукт или какую функцию вам следует создать следующей, ответ находится не в том безвоздушном конференц-зале, в котором вы оказались в ловушке. Этого нет на доске. Это не результат бесконечного мозгового штурма с другими сотрудниками вашей компании. Даже у вашего генерального директора нет ответа.
Ваш ответ находится где-то в мире за пределами здания, и ваши клиенты могут помочь вам найти его. Вам просто нужно знать, как учиться у них. Это одна из самых важных концепций бережливого стартапа. Вам нужно как можно раньше и почаще согласовывать что-то со своими клиентами, чтобы продолжать учиться. Если вы пропустили эту часть работы Эрика и Стива, вам следует взглянуть на нее еще раз. Это своего рода большое дело.
Если вы обратили внимание на остальную часть разговора о бережливом стартапе, то вы слышали, что пользовательский опыт также невероятно важен. Вы должны знать, как проектировать простые вещи, A / B тестировать их, а затем повторять.
О, и не забывайте о непрерывном развертывании, гибкой разработке и минимально жизнеспособных продуктах.
Конечно, если вы когда-либо пробовали делать что-либо из этого, вы, вероятно, поняли, что все это может быть до смешного сложно выполнить.
Возьмем в качестве примера “выход из здания”. Вы понимали, что вокруг этого построена целая индустрия? Есть огромное количество людей, которые изучали это в школе и которые занимаются этим профессионально. Этих людей часто называют “исследователями пользователей”, и они знают все о том, какие исследования проводить, когда и как получать от людей нужную информацию. Они выясняют, что не так с вашим продуктом, и объясняют, что вам нужно сделать, чтобы это исправить. И они берут с вас за это кучу денег.
То же самое касается дизайна взаимодействия с пользователем. Есть люди, которые разрабатывают продукты годами. Они изучали отличные дизайны и ужасные. Они потратили свою карьеру на то, чтобы создавать вещи, достаточно простые, чтобы люди могли их понять, и достаточно восхитительные, чтобы люди захотели ими пользоваться.
К сожалению, таких людей катастрофически не хватает, поэтому очень вероятно, что вы пытаетесь создать продукт без них. Или, может быть, вам посчастливилось найти дизайнера, но она в основном хороша в визуальном дизайне или никогда не работала ни в чем, кроме среды waterfall. Или вы даже можете быть дизайнером или исследователем пользователей, но вы никогда не работали в ужасно хаотичном и безумном мире, которым является новый стартап.
Как одному из вышеупомянутых типов людей, вам сейчас говорят, что вам нужно выйти из здания; и разработать адаптивный, элегантный, простой интерфейс; и делать все это ловко; и не могли бы вы также собрать несколько миллионов долларов и нанять группу инженеров rockstar и...твоя старая работа со стабильной зарплатой и выходными начинает казаться довольно привлекательной прямо сейчас, не так ли?
Итак, зачем я тебе все это рассказываю? Ты знаешь, как это тяжело. Тебе не нужно, чтобы я снова и снова говорил об этом.
Вот в чем дело. Я собираюсь предположить, что вы уже поняли, насколько все это может быть сложно. Я собираюсь облегчить вам задачу.
Вместо того чтобы разглагольствовать о том, насколько важен дизайн, или приводить малозначимые примеры того, как это делали другие компании, я просто дам вам несколько инструментов, которые помогут вам выйти из здания, спроектировать простой продукт и подтвердить все ваши предположения. Я не стану делать из вас эксперта, но я научу вас нескольким полезным трюкам, чтобы вы могли создавать более качественный продукт. Возможно, немного попрактиковавшись, вы сможете создать что-то, что люди действительно захотят использовать.
Я даже дам несколько советов о том, как оценивать свои успехи и неудачи, чтобы вы не продолжали делать одни и те же глупости снова и снова. Подумайте, сколько времени это сэкономит.
Итак, добро пожаловать в мир за пределами здания. Позвольте мне показать вам, куда двигаться дальше.
И вообще, что такое Lean UX?
Бережливый UX - это больше, чем модное словечко. В некотором смысле, это фундаментальное изменение в том, как мы разрабатываем продукты. С другой стороны, это куча вещей, которыми многие из нас занимаются уже долгое время.
На самом деле, многие люди, которые занимались дизайном, ориентированным на пользователя, или гибким дизайном, сбиты с толку тем, из-за чего весь сыр-бор вокруг Lean UX. Для этого есть причина. Многие аспекты бережливого UX покажутся очень знакомыми людям, привыкшим к гибкому дизайну и дизайну, ориентированному на пользователя.
Но Lean UX также привносит несколько новых вещей, которых нет в других методах проектирования. Он использует многие из лучших практик проектирования, которые были до него, и добавляет свою изюминку. Давайте посмотрим на то, что определяет бережливый дизайн взаимодействия с пользователем.
Lean UX основан на проверке гипотез
Как и все остальное в бережливом стартапе, Lean UX сосредоточен на проверке гипотез. Это довольно большой отход от традиционного дизайна, который часто вращается вокруг реализации “видения” дизайнера или владельца продукта.
Вместо того чтобы думать о продукте как о наборе функций, которые необходимо создать, Lean UX рассматривает продукт как набор гипотез, подлежащих проверке. Другими словами, мы не предполагаем, что знаем, чего хочет пользователь. Мы проводим собеседования с клиентами и исследования, чтобы разработать гипотезу о том, чего может хотеть клиент, а затем проверяем эту гипотезу различными способами, чтобы убедиться, что мы были правы. И мы продолжаем делать это каждый раз, когда вносим изменения в продукт.
Давайте рассмотрим пример до и после применения методов бережливого UX.
До появления Lean UX компания X могла бы сказать: “Нам нужно записывать комментарии пользователей к каждому продукту и отображать их на странице продукта”. Менеджер по продукту потратил бы время на написание спецификации для комментариев на страницах продукта. Дизайнер мог бы прийти и создать отличный интерфейс для комментариев. Затем инженеры написали бы код, соответствующий спецификации и дизайну. Весь процесс мог занять два или три месяца.
В конце процесса страницы продуктов позволят пользователям оставлять комментарии. Но что с того? Заставит ли это пользователей тратить больше денег на продукты? Будут ли они оставаться на сайте дольше? Будут ли пользователи вообще утруждать себя оставлением комментариев? Какова реальная выгода для компании от того, что она потратила эти три месяца на создание системы комментариев, а не на что-то другое?
Проблема этого подхода в том, что он начинается с характеристики, а не с гипотезы. Предполагается, что комментарии на страницах продукта необходимы, а не для выявления проблемы пользователя, выдвижения идеи, которая могла бы решить эту проблему пользователя, и разработки теста, чтобы проверить, верна ли идея.
Вот более простой способ подойти к решению проблемы.
Предположим, что вместо того, чтобы решить, что комментарии необходимы, компания X говорит: “Нам нужно найти способ увеличить наш доход. Основываясь на наших предварительных исследованиях, мы считаем, что разрешение пользователям оставлять комментарии на страницах продуктов приведет к тому, что клиенты станут более вовлеченными и купят больше товаров. Как мы можем выяснить, правда ли это?”
Теперь это было переформулировано таким образом, чтобы компания могла подтвердить гипотезу и легко изменить функцию, если окажется, что это неправильный способ улучшить показатель.
Как только у компании X появится гипотеза о том, что добавление комментариев увеличит доход, разработчик бережливого пользовательского опыта сможет найти наилучший способ подтвердить или опровергнуть эту гипотезу. Это может быть что-то столь же простое, как сбор некоторых комментариев пользователей о продуктах и добавление этих комментариев на страницу вручную, чтобы посмотреть, влияет ли наличие комментариев на странице на то, покупают ли пользователи больше продуктов.
Может ли результатом по-прежнему быть добавление функции, позволяющей пользователям оставлять комментарии на страницах продукта? Конечно! Разница в том, что вы будете знать, подходит ли эта функция для создания, задолго до того, как потратите много времени и денег на ее создание. Вы также сможете получить отличные отзывы клиентов о том, как именно должна работать эта функция, так что вам не придется возвращаться и исправлять ее позже.
Lean UX - это не добавление функций в продукт. Речь идет о том, чтобы выяснить, какие показатели управляют бизнесом, понять, какие проблемы клиентов мы можем решить, чтобы улучшить эти показатели, генерировать идеи для решения этих проблем клиентов, а затем проверить, были ли мы правы.
Если все это кажется вам довольно сложным, не волнуйтесь. Позже в книге я поделюсь некоторыми очень специфическими методами для достижения этой цели.
________________________________________________________________________
Но Дело Не Только В Проверке Гипотез...
Я разговаривал с одним стартапом, и они объяснили, что провели небольшой тест конкретной новой функции и измерили воронку конверсий. Около 3% людей перешли на использование этой функции. К сожалению, у них не было возможности определить, была ли конверсия в 3% фантастическим результатом или полным провалом, потому что никто раньше не создавал подобных функций.
Я вижу, что в эту ловушку попадают многие бережливые стартапы: неспособность интерпретировать, подтвердилась гипотеза или нет.
Конечно, когда это возможно, бережливый дизайн взаимодействия с пользователем поощряет разработчиков к A/B тестированию своих изменений, а A / B тесты, как правило, довольно легко интерпретировать - либо изменение приводит к статистически значимой разнице, либо нет.
Позже в книге я расскажу об этом подробнее. Однако существуют и другие типы тестов для выполнения, и их не всегда так легко интерпретировать, как обычный A / B-тест.
Иногда, когда вы пытаетесь проверить гипотезы в новых отраслях, бывает сложно понять, какие результаты являются залогом успеха. С помощью Lean UX вы должны научиться разрабатывать правильные типы тестов, чтобы знать, когда ваши гипотезы были подтверждены. И иногда вам просто приходится полагаться на старые добрые качественные исследования и здравый смысл. Мы рассмотрим это в последующих главах.
________________________________________________________________________
Бережливый UX ориентирован на пользователя
Я не могу вам передать, как часто я разговаривал с дизайнерами, прошедшими обучение в области дизайна, ориентированного на пользователя (UCD), и они говорили мне: “О, вы создаете прототипы и общаетесь с пользователями? Я делаю это! Я, должно быть, занимаюсь бережливым UX!”
И это отчасти верно. Lean UX в значительной степени заимствует UCD, в основном потому, что UCD потрясающий. Например, Lean Startup не придумал идею обучения у пользователей. Черт возьми, некоторые из нас занимались этим десятилетиями, и мы учились у людей, которые занимались этим еще дольше.
Это здорово, потому что это означает, что получение отзывов о продукте - не новая наука. Бережливым командам не нужно самостоятельно придумывать, как учиться у пользователей. Есть много людей, практикующих UCD и проводящих исследования пользователей, которые могут помочь им ориентироваться. На самом деле, если вы хотите научиться быть потрясающим дизайнером бережливого пользовательского опыта, вы могли бы сделать гораздо хуже, чем начать с получения хороших знаний в области дизайна, ориентированного на пользователя.
________________________________________________________________________
Но дело не только в Дизайне, ориентированном на Пользователя...
Всякий раз, когда мои друзья из UCD говорят, что они используют Lean UX, потому что создают интерактивные прототипы или проводят исследования юзабилити, мне приходится их поправлять.
Lean UX действительно очень сильно заимствует у UCD, но также добавляет много своих изысков. Например, у UCD на самом деле нет твердого мнения о таких вещах, как частые итерации, проверка гипотез или гибкие команды. У Lean есть. У UCD также нет концепции научного измерения результатов проектирования, в то время как это является центральным в методологии Lean.
Не думайте о Lean UX как о чем-то, что заменяет UCD или что лучше или хуже UCD. Это набор инструментов, который включает в себя многое из того, что так замечательно в дизайне, ориентированном на пользователя, - главным образом, его неустанную ориентацию на пользователя.
В этой книге я не собираюсь учить вас быть фантастическим дизайнером, ориентированным на пользователя, но, надеюсь, я покажу вам достаточно хитростей, чтобы ваш продукт сдвинулся с мертвой точки, и научу, как внедрить отличный дизайн, ориентированный на пользователя, в ваш процесс.
________________________________________________________________________
Бережливый UX отличается гибкостью
После того, как появился дизайн, ориентированный на пользователя, появился Agile-дизайн. И Lean UX также заимствует много отличного у Agile.
Например, Agile-дизайн включает в себя кросс-функциональные команды, где дизайнеры и разработчики работают непосредственно вместе над проектом, а не рассматривают отдел дизайна как внешнее агентство. Кросс-функциональная команда имеет решающее значение для бережливого UX. Вовлечение разработчиков, дизайнеров и владельцев продуктов в большинство решений ускоряет весь процесс проектирования и облегчает внесение изменений, когда что-то идет не так.
Agile избавляется от большого количества документации и спецификаций, чтобы быть более гибким...что ж, agile. Lean также избегает большого количества традиционной документации. Вместо того чтобы постоянно создавать PRD и идеальный по пикселям макет каждого экрана, как Lean, так и Agile концентрируются на предоставлении документации того типа, который наиболее полезен для доведения дизайна до команды. Зачем писать 300-страничный документ Word, если достаточно технологической схемы или эскиза?
Возможно, самое главное, что и Agile Design, и Lean UX избавляются от водопадной методологии прошлого, когда исследования и проектирование могли занимать месяцы или даже годы, прежде чем их передадут инженерам в качестве “окончательной спецификации”, что часто было неправильным.
Как и Agile, Lean фокусируется на быстрой работе и коротких циклах, чтобы сократить время до получения командой отзывов о продукте.
________________________________________________________________________
Но Дело Не Только В Том, Чтобы Быть Гибким...
Хотя Lean UX использует огромное количество лучших практик гибкого проектирования, это еще не вся история.
Lean заменяет традиционные пользовательские истории, которые могут быть объявлены “готовыми” владельцем продукта, пользовательскими гипотезами, которые могут быть подтверждены или аннулированы. Другими словами, функция не завершена, когда она отправляется пользователю. Функция часто является просто методом проверки того, является ли разрешение нового поведения клиента хорошим или плохим для бизнеса.
При работе в средах гибкого проектирования меня часто просили проверить ту или иную функцию в промежуточной среде, чтобы определить, завершена ли она и может ли быть принята. В Lean UX на этот вопрос нельзя ответить, пока функция не будет использована клиентами и не будут измерены результаты по ключевым показателям. И даже тогда функция на самом деле не “закончена”. Она просто готова к следующей итерации.
Это может показаться незначительным различием, но концепция измерения результатов проектирования - это то, что потенциально может кардинально изменить индустрию дизайна продуктов к лучшему. Неудивительно, что в последующих главах я расскажу об измерении дизайна гораздо более подробно.
________________________________________________________________________
Бережливый UX Основан на данных
Говоря о данных, Lean UX полностью основан на данных.
Одна из наиболее важных идей, лежащих в основе Lean UX, заключается в том, что мы не предполагаем, что новый дизайн или функция автоматически лучше, чем то, что было до него. Мы тестируем все. Когда мы отправляем новую функцию, мы тестируем, чтобы увидеть, оказала ли она существенное влияние на поведение важных пользователей. Когда мы меняем текст или время отправки электронного письма, мы тестируем, чтобы увидеть, какая версия работает лучше. Когда мы вносим изменения в пользовательский поток или структуру навигации, мы следим за тем, чтобы непреднамеренно не ухудшить ситуацию для пользователей.
Что еще более важно, мы используем этот процесс развертывания и тестирования в качестве обратной связи для разработчиков. Если мы внесли изменение, которое, как мы полностью ожидали, улучшит ситуацию, но на самом деле повредит ключевым показателям, мы используем это в качестве основы для расследования того, что пошло не так. Какие предположения были сделаны, которые оказались неверными? Какие гипотезы были признаны недействительными?
Тестируя каждую итерацию дизайна функции, мы помогаем дизайнеру узнать больше о реальном поведении пользователя. У нас также есть конкретные показатели, которые мы можем использовать, чтобы показать окупаемость инвестиций в дизайн-проекты.
По моему опыту, это то, что уникально для Lean UX. Конечно, дизайнеры и исследователи пользователей проводят качественные юзабилити-тесты своих продуктов в течение многих-многих лет, но такого рода количественное измерение фактического влияния конкретных изменений дизайна на поставляемые продукты до недавнего времени не было широко распространено, особенно в стартапах.
Некоторые члены дизайнерского сообщества также довольно энергично сопротивлялись этому, потому что они чувствуют, что “дизайн невозможно измерить” или что каким-то образом количественная оценка воздействия дизайна умаляет чистоту процесса. На мой взгляд, это полная чушь.
То, как что-то спроектировано, может либо улучшить удобство использования и привлекательность продукта, либо разрушить его. В наших интересах, как дизайнеров и владельцев продуктов, измерить реальное влияние, которое наша работа оказывает на прибыль наших продуктов и компаний. Но не волнуйся. Мы можем поспорить об этом позже в книге.
________________________________________________________________________
Но Дело не только В Данных...
Один довольно распространенный аргумент против бережливого UX заключается в том, что каким-то образом все эти данные лишают проект видения. Возможно, именно в этом кроется причина, по которой многие дизайнеры так сопротивляются идее дизайна, основанного на данных. Они слышали о тестировании Google 41 оттенка синего и думают, что все решения будут сведены к подобному подходу “просто протестируй все”.
Это не могло быть дальше от истины. Хотя верно, что такие вещи, как выбор наилучшего цвета для ссылок, легко решаются с помощью многомерного теста, также верно и то, что реальные изменения в дизайне, а не просто крошечные оптимизации, вносятся дизайнерами и людьми, обладающими видением и страстью к продукту.
То, что мы тестируем, как наши изменения влияют на конечный результат продукта, не означает, что мы не принимаем важных дизайнерских решений. Вместо того, чтобы думать о бережливом проектировании как о том, что оно основано на данных, вы можете думать о нем как о том, что оно основано на данных. Данные могут рассказать нам о таких вещах, как то, что делают люди и где они выпадают из воронки, но только хорошее исследование и дизайн скажут нам, почему это происходит и как это исправить.
Дизайн, основанный на данных, заключается не в том, чтобы просто попробовать все, что вы можете придумать, и выбрать то, что лучше всего преобразуется. Речь идет о сочетании хороших методов проектирования с хорошими методами тестирования для создания более успешного продукта. Если вы еще не уверены, я расскажу о правильных и неправильных способах тестирования проектов позже в книге.
________________________________________________________________________
Бережливый UX - это быстро и дешево (иногда)
Lean часто неправильно понимают как синоним “настолько дешевого, насколько это возможно”. Это просто неправда. Бережливый стартап, как и Lean UX, не имеет никакого отношения к тому, находится ли компания на начальной стадии развития или в списке Fortune 500. Бережливый стартап не означает дешевый стартап. Этого никогда не было.
Однако я обнаружил, что Lean UX часто быстрее и дешевле традиционного UX, почти исключительно потому, что Lean UX стремится исключить отходы.
Представьте на мгновение, сколько стоит провести полный цикл традиционного исследования пользователей, за которым следует месяц или два тестирования дизайна и юзабилити, прежде чем писать строку кода. На самом деле мне не нужно это представлять. Я работал в агентстве, которое выполняло подобную работу, и ответ легко можно найти в десятках тысяч долларов, а иногда и значительно больше. Помните, это еще до того, как вы вообще утвердите свою первоначальную идею продукта.
Теперь представьте, что вы выполняете всю эту работу, но после запуска вашего продукта его никто не покупает, потому что никому особенно не нравится ваша идея.
Например, возможно, вы слышали о компании под названием Webvan. Они потратили где-то около 400 миллионов долларов на создание автоматизированной складской системы только для того, чтобы понять, что люди еще не готовы покупать продукты онлайн.
Вместо того чтобы создавать до проверки, представьте, что вы начинаете с нескольких легких экспериментов, чтобы проверить гипотезу о вашем продукте, понимаете, что это абсолютно неверно и что никто за это не заплатит, и продолжаете повторять и разворачивать, пока не найдете что-то, что люди захотят купить.
Например, вместо создания целой инфраструктуры, способной доставлять продукты миллионам людей, Webvan могла бы поэкспериментировать со статичным веб-сайтом, ограниченным ассортиментом товаров и услугами консьержа. Или они могли бы начать с партнерства с магазинами, которые уже продают продукты. На самом деле, если бы они начинали таким образом, им, возможно, удалось бы накопить достаточно денег, чтобы продержаться до тех пор, пока люди не будут готовы получать все свои продукты с доставкой.
В любом случае, они бы избежали тратить много времени и денег на создание чего-то, что никому не было нужно, вместо того, чтобы потратить немного времени и денег на поиск чего-то, за что люди могли бы им заплатить.
Я не экономист, но я бы сказал, что вторая версия этой истории намного дешевле первой. И в этом суть, на самом деле. Бережливый UX экономит ваше время и деньги не потому, что вы отказываетесь инвестировать в хороший дизайн. Бережливый UX экономит ваши деньги, не позволяя тратить много времени и денег на то, что никому не нужно.
Бережливый UX по-прежнему требует серьезных инвестиций в инструменты и людей, необходимых для создания хорошего дизайна. Это просто удерживает их от разработки неправильных вещей.
________________________________________________________________________
Но дело не только в том, чтобы быть дешевым и быстрым...
Бережливый UX - это неплохой UX, и создание хорошего пользовательского опыта обходится недешево. Вы не можете отказаться потратить деньги на исследования и дизайн, а затем сказать, что вы бережливы. Это не так. Вы ведете себя глупо.
В этой книге я собираюсь дать вам множество советов, которые помогут вам двигаться быстрее и получать лучшие результаты с меньшими затратами. Но я не собираюсь рассказывать вам, как создать потрясающий продукт бесплатно, потому что это просто невозможно.
Для правильного проектирования и исследований по-прежнему требуются время и деньги. Но, тратя свое время и деньги разумно, вы, по крайней мере, получите отличный продукт, которым люди захотят пользоваться. Остальная часть этой книги научит вас, как проводить исследования и разрабатывать дизайн с меньшими затратами и как научиться нужным вещам в нужное время.
________________________________________________________________________
Бережливый UX является итеративным (всегда)
Огромная часть бережливого UX связана с так называемым минимально жизнеспособным продуктом (MVP), о котором я собираюсь подробно рассказать позже в книге. Этому посвящена отдельная глава! Краткая версия определения MVP заключается в том, что вы собираетесь создать как можно меньшую вещь, чтобы окончательно подтвердить или опровергнуть гипотезу.
Однако есть очень, очень важная концепция, которую многие люди, похоже, упускают из виду. Как только вы создали MVP, вам нужно продолжать работать над этим. Видите ли, если все является гипотезой, которую вам нужно подтвердить, то, как только вы подтвердите эту гипотезу, вам нужно действовать в соответствии с ней.
Бережливый UX - это сбор действенных показателей. Конечно, ключ к успеху с действенными показателями заключается в том, что вы должны что-то с ними делать. Это не то, что просто заставляет вас чувствовать себя хорошо. Это важные инструменты для принятия решения о том, что делать дальше.
Это создает невероятно повторяющийся процесс, в котором вы постоянно создаете небольшие вещи, учитесь на них, а затем продолжаете строить — или иногда разрушать — на основе того, что вы узнали.
Чтобы цикл продолжался, вы должны продолжать повторять и создавать. Я видел слишком много плохих бережливых стартапов с продуктами, которые изобилуют заброшенными или наполовину созданными функциями. Их намерения были благими. Они пробовали много разных вещей, но затем просто оставляли их гнить.
Постоянно пробовать что-то новое, а затем отказываться от этого без дальнейшего изучения или работы - это не повторение. Это сбивает с толку. И, что более важно, именно это приводит к дико усложненным продуктам со странным сочетанием заброшенных функций, используемых небольшим процентом пользователей.
У одного стартапа, с которым я работал, было не менее трех различных способов поиска по сайту одновременно. Вместо повторения первой версии, он продолжал создавать новые версии поиска с немного отличающимися функциями, что привело к одному из самых запутанных случаев, которые я когда-либо видел у пользователей, которые просто хотели выполнить поиск продукта. Я буду говорить о способах избежать подобных проблем на протяжении всей книги.
С помощью Lean UX вам нужно постоянно совершенствовать свой продукт, не только добавляя новые функции, но и улучшая взаимодействие с уже созданными функциями и устраняя неэффективные функции.
На самом деле ничто никогда не заканчивается. Он просто готов к следующей итерации.