Про удобство (Михаил Греков)
17.6K subscribers
159 photos
17 videos
2 files
502 links
Про продуктоводство, UX, работу с b2b-продуктом, кейсы из жизни и пользование Озон.

Пишет Михаил Греков, Head of product BI Analytic Workspace aw-bi.ru

🔥 Второй канал: Продуктовошная @suda_smotri

Сотрудничество — @GrekovM
Download Telegram
Про навык коммуникации
"Весь день то с одним, то с другим общался, нет времени задачи поделать" — довольно частый итог дня для менеджеров.

И если спросить менеджеров: какой навык самый важный в повседневной работе?
То очень многие скажут, что навыки коммуникации.

Что же такое навыки коммуникации?
Если продакт или кто-то уверяет, что у него бОльшая часть дня проходит в коммуникациях, то хорошо ли это?

Может и хорошо, но а что если суперкоммуникатор имеет кучу коммуникаций потому что:
😳 не умеет фиксировать договорённости и из-за этого вынужден постоянно проговаривать одно и тоже?

😳 не умеет слушать и запоминать главное и из-за этого мучает всех постоянными вопросами?

😳 не умеет ёмко представлять информацию и вместо одного слайда делает и рассказывает 17?

😳 не умеет выбирать способ коммуникации и вместо 10 минут устного обсуждения полдня переписывается?

😳 не умеет писать в чат и вместо одного сообщения с парой предложений кидает 15 сообщений в виде словосочетаний?

😳 не умеет сказать нет и ходит по всем планёркам, даже на которых справятся без него?

😳 не умеет организовывать и искать информацию и всех дёргает вопросами, где то найти, где это?

😳 не умеет находить людей для решения вопроса и по цепочке добирается до нужного, пройдя через кучу коллег?

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

Навык коммуникации — это слушать и слышать, запоминать и фиксировать, выбирать правильный канал коммуникации, быть ёмким, а не расплывчатым.
Хорош тот, у кого коммуникации выстроены так, что бOльшая часть времени остаётся для другой работы.

Посты в канале по теме:
Запоминать и резюмировать
Навык резюмировать
Культура e-mail переписки (в картинках)

#softskills
Лайфхак для глубинок
Если вы проводили проблемные или глубинные интервью, то могли столкнуться с ситуацией, когда ваш собеседник закрыт. Не особо разговорчив, на открытые вопросы отвечает кратко, цифрами не делится. И в итоге, чтобы вытащить информацию может потребоваться не 30-40 минут, а 1.5-2 часа.

Собеседника можно понять: какие-то люди, которых зачастую ещё вчера и знать не знал, расстреливают тебя вопросами, факты хотят. Так себе откровение.

Узнал недавно два очень простых способа быстрого раскрытия собеседника — если их применять, то человек будет более лоялен и разговорчив:

1. Ненавязчиво похвалить. Необходимо отметить, какие-то приятные факты о собеседнике — чистая психология. “Когда я готовился к интервью, то обратил внимание, что вы занимаетесь этим бизнесом уже 15 лет. Не часто выдаётся возможность поговорить с экспертом такого уровня!
2. Не только спрашивать, но и делиться своими фактами. Люди любопытны от природы — им интересна новая информация. Если вы чем-то делитесь, то и с вами охотнее поделятся. Конечно, выдавать чужие секреты при таком дележе информацией не надо, иначе свои секреты вам доверить не захотят.
Мы побеседовали уже с 30 предпринимателями из вашей сферы — у большей части, как и у вас, остро стоит проблема с кадрами, особенно в сфере безопасности.

Вот и всё — хвалите и делитесь информацией, и с вами быстрее начнут говорить открыто.

#hardskills
Про User Story

В требованиях к Менеджерам продуктов/проектов и UX-ерам периодически пишут: умение писать User Story (US). Так вот, писать US — это не ахти какая грамота и не надо путать User Story и Use Case.

User Story — это ожидания пользователей, записанные в компактном твиттер-формате, понятном всем (моё вольное определение).

Обычно их пишут в таком виде: Как РОЛЬ я хочу ЧТО ИМЕННО ХОЧЕТ, чтобы ЗАЧЕМ Я ЭТО ХОЧУ.

Например, Как подписчик канала Про удобство, я хочу, чтобы автор делился знаниями полезными для меня здесь и сейчас, чтобы я мог применять эти знания на практике.

Вместо, "Я хочу" могут быть и другие варианты: Мне важно, От меня требуется, Я вынужден.

Я обычно пишу US в таблицу со столбцами:
▫️User Story
▫️Роль
▫️Как учесть

На более-менее масштабные требования (обычно в проектной работе) приходится не 1-2 US, а целая пачка: может быть и 100, и больше. Поэтому роль я выношу за пределы US в отдельный столбец, чтобы не было 20-30 записей подряд с одним и тем же началом, да к тому же сортировать по ролям удобно.

В столбец "Как учесть" одним предложением пишу, как можно удовлетворить этой US в продукте.

В чём прелесть US
Они всем понятны. Это не прямые требования к продукту, это способ зафиксировать ожидания пользователей. К US удобно возвращаться, чтобы проверить, а соответствуем ли мы этому ожиданию или нет.

Не надо

▪️Привязывать US к интерфейсу. "Я хочу нажать на кнопку "Поиск", чтобы найти всё что мне надо" — это не US, а фантазия того, кто сформулировал ожидание в таком виде :)

▪️Описывать ожидания пользователей, не общаясь с пользователями. Правильный порядок такой: Интервью → Фиксация User Story.

Вот и всё.

В общем, самое сложное "доставать" User Story — интервью вам в руки. На практике могут быть нюансы в работе с US: проектная/продуктовая деятельность, госуха или b2b/b2с, способ планирования работы команды и т.п. Но сам формат US одинаков.

#UX #Продакту
из давно опубликованного
Самый дельный совет в последние дни: надо продолжать работать, если есть такая возможность. Один мой друг так мне и сказал: “Надо работать просто больше”.

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

Я уже писал про состояние потока и книгу Михай Чиксентмихайи — Поток: психология оптимального переживания (кому тяжело — почитайте её в ближайшее время). Но напомню ещё раз.

Вы, наверняка, когда-нибудь ощущали состояние потока: когда чем-то занят и всё остальное отходит на второй план. Есть только ты и твоё занятие.

И вот, что важно, чтобы попасть в состояние потока (минимально необходимый набор):

1. Вы занимаетесь задачей, которая на границе ваших возможностей (вы можете её сделать, но не без труда).
2. У вас есть чёткая понятная цель.
3. Вы получаете мгновенную обратную связь от результата.

Вырывайтесь из новостного потока и работайте, работайте — займите себя делом.

Будет хуже? Возможно. Надо продолжать работать, если есть такая возможность.

Комментарии к постам временно отключу — не хочу, чтобы меня вовлекали в тот поток, который не я выбираю.
b2b и UX

А откуда у тебя экспертиза в UX? Судя по резюме, ты в основном b2b продуктами занимался”.

Я однажды офигел с такой реплики на собеседовании. У многих в b2c есть какой-то пунктик по поводу b2b: там сидят и делают что-то по чёткому ТЗ для безликих пользователей, которые будут работать с любым продуктом, который им дадут (ну или навяжут после откатов).

Камон! В b2b юикса ничуть не меньше (а то и больше), чем в любом b2c.

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

— Да, часто нет массовости пользователей — количественные методы исследования не всегда возможны, но зато качественные шикарно заходят.

— Пользователи невероятно важны: продажи часто строятся на виральности. Но виральность эта особая: надо чтобы пользователи при смене места работы хотели продолжать работать именно в твоём продукте и инициировали его внедрение. Это долгая петля, но она работает.

— В b2b-продуктах больше честной заботы о пользователях. Пользователям уже не надо продавать продукт: надо, чтобы они решали в нём свои рабочие задачи. В b2c же забота о пользователях постоянно на качелях с метриками (см. про агентская проблема менеджера продукта).

— Пользователи решают коллективно и жёстко: если решат байкотировать внедрение продукта, то найдут 100 причин почему он плохой. Психология взаимоотношений на совершенно ином уровне чем в массовых b2c.

В общем, в b2b продуктах ничуть не меньше юикса, чем в b2c. А вопрос, с которого я начал пост, говорит только о неграмотности собеседника. Ну и с учётом повестки дня: в российском сегменте b2b сейчас будет довольно жарко — бизнес будет рад отечественным решениям.

#UX
​​Дочитал книгу Константина Борисова “Герой и его команда: как собрать, зажечь и достичь больших результатов” (издательство Альпина PRO, у них хороший канал Полка наPROтив — @polkanaprotiv).

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

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

©️ Ты не должен брать себе “верхний кусок” задачи, а сотруднику отдавать “нижний кусок”. В итоге он будет много работать, а все итоги будут твои. Лучше провести вертикальную черту, чтобы каждый отвечал за свой кусок работы. Руководитель отвечает за общие результаты, а его подчинённые — за отдельные участки с понятными целями и результатами. (Илья Кретов, Отвечает за развитие EBAY на глобальных развивающихся рынках).

©️ Мне кажется, что один из главных факторов успеха в бизнесе — делать, когда весь рынок думает, что это невозможно. (Георгий Соловьёв, сооснователь Skyeng)

©️ Тот, кто не допускает ошибок двигается очень медленно. Это моё главное правило. Но ошибки не должны повторяться. За повтором ошибок надо следить очень жёстко. (Дмитрий Крутов, сооснователь Skillbox).

©️ Нужно понимать, когда ты устал. Если возникает ощущение, что я уже что-то не могу делать, если работаю в режиме самоуничтожения, то пора валить. Как минимум в отпуск. (Дмитрий Крутов, сооснователь Skillbox).

©️ Я никогда лично не буду ничего обещать, если не уверен на 100%, что я это выполню. А если пообещал, то буду выполнять, что бы ни случилось. В конце концов команда начинает это понимать, и это тоже помогает доверию. (Дэнни Перекальски, Дикси, Озон и Утконос).

©️ Большая идея выступает магнитом и источником энергии, особенно в сложных ситуациях. Для воплощения этой идеи мы подбираем людей. Если в человеке идея не находит отклика, то вероятность того, что он станет участником команды, очень мала. (Максим Спиридонов, сооснователь Нетология-Групп).

©️ В плохом коллективе вы обречены постоянно находиться в токсичной среде и мечтать поскорее свалить. А когда людям хорошо, комфортно, креативно, дружно, зачем им уходить? Что им дадут лишние 10-20% к зарплате, если они будут получать их в токсичной среде? Когда всё плохо, никаких денег не надо. (Ксения Рясова, президент, Finn Flare)

Хороших выходных ❤️!
Про задачи

Главная истина, которую должен познать любой человек, который ставит задачи (не важно какой уровень, не важно какая сфера): чем лучше ты зафиксируешь свои ожидания, тем больше им будет соответствовать реальность.

Вот несколько тезисов, которых я придерживаюсь при формировании бэклога и постановке задач:

1. Простых задач нет.

2. Никто никого с полуслова не понимает (и меня тоже не понимают).

3. Всё, что не зафиксировано, может быть сделано не так, как ожидалось.

4. Всё, что зафиксировано, может быть понято не так как ожидалось.

5. Если нет срока, то к нему и не успеют.

6. Много задач с одинаковым приоритетом — зло. Тратится время на выбор.

7. По-настоящему горящих задач меньше, чем кажется.

8. Любая важная задача, которую долго не делали, вероятно, не важная.

9. Список задач должен быть стабильным на короткой перспективе и гибким на длительной. Месяц — стабилен, год — гибок.

10. Надо быть готовым к тому, что в кризис всё придётся оперативно перепланировать.
​​Про воронку

— Я столько откликов делаю на вакансии, но пока не нашёл работу. Что не так с резюме?

— А сколько ты сделал откликов?

— Да много! Наверное, 15 или даже уже 20.

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

На пальцах: если вы в результате какого-то количества попыток ожидаете получить результат — вы работаете с воронкой и конверсией.

Примеры:

— поиск респондентов на интервью.

— поиск работы.

— проверка гипотез.

— поиск целевой аудитории.

Всё это про воронки: чем больше насыпать сверху, тем больше шансов получить снизу хотя бы что-то.

Например, примерная статистика поиска работы на HH: чтобы получить приглашение на 1 собеседование, надо отправить 10 откликов (половину или больше даже не прочитают). Чтобы получить оффер — надо пройти как минимум 5 собеседований. Итого: минимум 50 откликов надо сделать, чтобы получить оффер. Речь о релевантных откликах — где ваши навыки совпадают с искомыми.

Статистика может существенно отличаться в зависимости от сферы деятельности и опыта. Надо замерять по себе и корректировать свои планы насыпания в воронку.

В общем, если нужен результат — иногда достаточно просто делать больше попыток к нему добраться. А если начать анализировать и улучшать эти попытки (конверсия), то со временем добежать до того же результата будет проще.
Таск или таска :) Как скажете в отношении задачи: "Мне осталось сделать ..."
Anonymous Poll
36%
этот таск
50%
эту таску
13%
иначе
Про простые задачи

Я тут выше писал про тезисы, на которые опираюсь при постановке задач. Расшифрую сегодня тезис “Простых задач нет”.

Конечно, простые задачи есть и их не мало 🤫. Но смысл тезиса в том, чтобы ни к одной задаче не относиться как к простой. Простая задача — это потенциальная ловушка.

Например (упрощая реальность)

Менеджер: "Ребята, надо срочно добавить в анкету клиента адрес прописки. Это же быстро? Можем сразу в разработку забрать, аналитика же не нужна? "

Неопытный менеджер действительно может верить, что добавить адрес — это простая задача. Но нет, внутри задачи могут быть: интеграция с ФИАС (федеральная информационная адресная система), хранение структуры адреса, ситуации, когда адреса нет в ФИАС и т.д.

Представьте, что ребята говорят: “Да, вроде, просто. Давай сделаем”. И задача начинает разрастаться как снежный ком, ломая все ожидания и роадмап.

Простая задача — это задача, которую простой признали и менеджер, и аналитик, и разработчики. Т.е. любая задача должна пройти через стандартные предпрограммистские этапы: проработка постановки, дизайн (если актуально), оценка разработки. Да, это лишние транзакционные затраты для реально простых задач. Но экономия на “снежных комах” компенсирует с лихвой эти “лишние” транзакции.

Тезис “Простых задач нет” выстрадан практикой. Всякий раз, когда кто-то хочет побыстрее пропустить простую задачу в план работ, получает от меня стоп. “Возможно, задача и простая. Аналитика покажет, а после примем решение. ”
Боязнь облажаться
Знаю ребят, которым есть, что сказать, или могут что-то запустить, но боятся облажаться.
Они долго готовятся к старту, всё просчитывают — хотят обрести гарантию, что не облажаются.
Но в итоге всё равно не делают, так как гарантий нет.

Да что уж там — я и сам частенько боюсь облажаться. Всякий пост — это борьба с мыслью: "Сейчас облажаюсь и крутые ребята, подписанные на канал, плюнут и отпишутся."

А потом ты берёшь и делаешь.
Жмёшь кнопку "Опубликовать" и двигаешься дальше. В это время кто-то, конечно, плюёт и отписывается, но приходит больше.

В общем, это я к чему: бояться облажаться, но делать — это нормально. А бояться облажаться и не делать — это ходьба на месте или деградация.

#мотивация, опубликованная в мае 2020
​​Разомнёмся?
Как думаете, что рекламируется в этом объявлении?
Я, честно сказать, имел много версий, но только тыкнув в объявление понял что это 🤭

Объявление крутится в РСЯ, если что (рекламная сеть Яндекса).
Про удобство (Михаил Греков)
​​Разомнёмся? Как думаете, что рекламируется в этом объявлении? Я, честно сказать, имел много версий, но только тыкнув в объявление понял что это 🤭 Объявление крутится в РСЯ, если что (рекламная сеть Яндекса).
Не буду долго держать интригу. По этой рекламе скачивается pdf-ка с резюме женщины, которая на фото. Она тендерный специалист.
Это реклама резюме, Карл. Человек работу ищет.
​​Какая боль, какая боль ...

Наверняка вы слышали подобные тезисы:

— Продукт должен решать боль,

— Если нет боли, то продукт не нужен,

— Какую проблему решаем?

Так вот, вера в тезис “продукт должен закрывать боль” — это однобокая позиция, которая сужает продуктовый вижн.

А если у пользователя нет боли, то ему ничего не надо? Или “нет боли” — это боль скрытая и её надо достать из пользователя? Что болело у людей до инстаграма?

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

Закрытие боли проще продать, но и продавцов обычно больше — это очевидное пространство.

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

Представьте (условно), работает некий бизнес и на проходной стоит турникет: всем сотрудникам делают пропуска, по которым они проходят. Ничего не болит — система работает. А потом приходят стартаперы и говорят: "Мы повесим фэйсконтроль на основе ИИ, который будет автоматически распознавать входящих. Не надо делать пропуска, не нужен турникет со считывателем кодов, камеру будем использовать существующую. Стоит дешевле, чем сопровождение текущей системы."
Принесли новую возможность, а не искали боль, которой нет.

Возможность — это боль 2.0. Когда набрана масса пользователей, которым ты смог донести продукт с новыми для них возможностями, то для всех остальных становится болью не использование этой новой возможности.

В общем, если смотреть на продукт через призму “какие новые возможности мы даём пользователю”, то можно не сужать продуктовый вижн до очевидного “какую боль решаем”.
Компания TYPICAL выпустила познавательную статью про работу с консалтерами (их ещё называют консультантами 😉) .

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

В ИТ часто прибегают к консультантам и сами часто консультируют. Посмотрите, будет полезно.

От себя добавлю, что я работал и в компаниях, которые к консультантам никогда не обратятся, и в компаниях, которые с удовольствием прибегали к услугам консалтинга.
На моей практике вторые компании бежали быстрее и прямее, но выбор консультантов был серьёзный, а не абы как.

Ссылка на статью: https://go.typical.company/industriya-konsaltinga
Детские юзабилити-болезни b2b-систем. ТОП-5.

Я довольно много систем для бизнеса посмотрел, да и сам поделал. И на начальных этапах развития почти в каждой системе видел одни и те же юзабилити недостатки:

1. Разряды в числах. 100000 → 100 000

2. Склонения возле чисел. Найдено 21 результатов.

3. Сортировки списков. Разработчики обожают или сортировать рандомно, или по ID.

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

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

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

UPD. В комментариях дополнили (спасибо!):

Ой, можно дополнить) обожаю

1. Открывать модалку на редактирование каждого пука

2. Все настройки в формате True/False: Не запускать/Сохранять/You name it — Да/Нет

3. Не делать прелоадеры или какие-либо маркеры отправки запроса

4. Давать нажимать/редактировать всё подряд, даже если есть взаимоисключающая логика

5. Зато при сохранении тебя ждут ‘…Type must not be null’, ’Name cannot be…’ и тп

#UX
Adidar

Помню в школе (90е) у меня была спортивная сумка “ADIDAR”. В то время много было Nuke, Abidas, Reibok и т.п. То ли эти бренды из Китая приезжали, то ли где-то в подвалах шили.

Факт в том, что настоящих брендов не было или они были не доступны, а вместо них были коверканные. Конечно, серьёзно к такой клоунаде никто не относился.

Возможно, те кто коверкал брендовые названия думали, что схожесть с брендом приведёт покупателей (наверное, даже так и было). Явно, никто из создаталей “Адидаров” не собирался делать продукт и бренд на века. Тупо хайп.

Я это к чему. Когда я вижу новости о запуске отечественных аналогов мировых систем, то хайпофильтр работает чётко: если название нового сервиса — это искаверканное название мирового продукта, то это тупо хайп. РосГрамм, ГрустноГрамм, РоссТрелло ... всё это хайп, который не достоин внимания.

Продукт начинается с названия, а не с клоунады.
Снять ответственность

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

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

Часто не нужна задача, часто нужна только цель, а сотрудник сам определит как до неё добежать.

Попытка руководителя всё контролировать никогда не сможет привести к росту инициативы и ответственности сотрудников.
Коллеги, обратите внимание

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

Я не очень люблю обращаться через слово "коллеги". Не знаю почему, но это так. Наверное, это слово ассоциируется у меня с излишним формализмом. Использую его в особо серьёзных общениях. А в обычных чатах и переписка применяю: ребята, парни, ребята и девчата, милейшие, господа, дорогие, уважаемые, родненькие и т.п. (в зависимости, конечно, от состава чата).

Дело было так: Пишу я, значит, в чат: "Милейшие, давайте согласуем время созвона."
Ну написал и написал.

Ан нет, мой руководитель позвонила мне и сказала, что в организации не принято обращаться к коллегам "милейшие". Попросила так не делать.

Через месяц мы расстались и я вообще не жалею.
Коллеги, нельзя же всё время быть на серьёзных щах. Расслабьтесь, родненькие.
​​История про проактивность

Чуть больше месяца назад мне написал Всеволод — ему нужен был совет относительно получения образования менеджера продукта (у него был смежный опыт, но всё не то). Я посоветовал начать с симулятора Go-Practice.

Ну посоветовал и забыл.

А неделю назад Всеволод вернулся и сообщил, что прошёл симулятор и ищет работу продактом. Спросил, нет ли у меня вакансий.

Вот прям открытых вакансий пока не было, но мне понравилась проактивность новоиспечённого продакта. Посоветовался с CEO, решили пособеседовать.

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

А ведь его можно потратить на прогулку, на спорт, кофе, выпивку — каждому своё. Но нет, обсуждают задачи.

Не надо сразу обсуждать задачи.

Что обычно делают те, кто ставит задачу? Рассказывает (или описывает) и говорит: “Вопросы есть?”. А тот кто получил задачу, не успев её осмыслить, начинает задавать какие-то вопросы, которые первыми пришли в голову. Идёт обсуждение ерунды какой-то, а основные вопросы появятся позже.

Правильный путь такой:

Получить задачу → Осмыслить → Подождать (ещё говорят “Переспать с этой мыслью”) → Задать вопросы, если они будут.

В общем, если вы ставите задачу: дайте человеку время на осмысление и подготовку нормальных вопросов. Если вам ставят задачу: не торопитесь спрашивать всё подряд, возьмите паузу, подумайте.

Пауза — лучший ускоритель.