Отличие сильного руководителя от слабого

Доброе утро!

Не любишь понедельники? Вот тебе инсайт вместо кофе:

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

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

– Когда я впервые шел спорить с директором по поводу курса компании, я не спал всю ночь. Встреча прошла безрезультатно, но меня не уволили и я дважды повторил – результат появился.

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

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

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

А теперь – делай то, что правильно. Удачной недели!

Экспериментируем с форматами

Сегодня – играем в сарказм!
Инвертируем содержимое и идём к успеху :)

https://habr.com/ru/articles/815923/

Ваши лайки на хабре – согревают и помогают)

#ОтветыНаВопросы

Как поддерживать отношения в распределённой команде?

Удалёнка – вызов для менеджера и отношений в команде.
Заменить коммуникации и отношения, возникающие между людьми, по 8 часов в день проводящих рядом, тяжело, но побороться за них – можно 🙂

Вот, что помогало мне:

Пятничное пиво

Я раньше думал, что выпить и пообщаться можно только лично в баре или в офисе. По зуму – странно.

А потом наступил ковид и..знаете – не так и плохо. Я потестировал на себе и друзьях, потом на команде – и сработало. Начало пережить непросто, но, если не дать разговорам провиснуть и взять с собой любимые напитки, всё будет в порядке. Через 30-60 минут расстояние ощущается не так остро и барьеры частично растворяются. А ещё – в конце не нужно ехать домой на такси 🙂

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


Онлайн-игры

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

Некоторые ребята могут бодро и весело порубиться в CS или доту после работы.
Кому-то заходят аналоги классических настолок вроде codenames, шпиона или мафии.
Можно выбрать игру исходя из знаний об участниках команды или банально – устроить голосование.


Пространство для неформального общения

Если в команде ещё нет чатика, в который по средам кидают жаб, по вторникам – обмениваются лучшими событиями за прошедшую неделю (я не шучу, практика называется «happy tuesday»), а каждый второй понедельник – постят своих домашних животных – стоит попробовать

В нём же можно делиться впечатлениями про кино/книги/whatever

Если чатик стабильно живёт – можно прицепить к нему зум/дискорд/whatever-комнату, в которую можно зайти, например, каждый день во время обеда/ужина и поболтать с теми, кто на связи


Локальные хабы

Если в одном городе у тебя несколько человек (например, треть команды), будет классно организовать ребят встречаться хотя бы пару раз в неделю. Например, понедельник – день планирования и брейншторма, пятница – день, перетекающий в очную тусовку

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


Быть ближе к дезинтегрированным людям

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

Иногда в команду приходят новички
Иногда – старички дистанцируются

Если кто-то «откалывается», лучшее, что можно сделать – начать лично больше общаться с человеком: говорить о происходящем вокруг, делиться проблемами команды и компании, рассказывать личные истории и интересоваться, как у него идут дела. В идеале – созваниваться, чтобы это обсудить

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

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

Общение лучше начинать руководителю или ментору, а позже – постепенно включать сотрудника в более широкие круги коммуникаций

А какие практики работают у вас?

Вечерний пост для больших руководителей, которые давно не удивлялись

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

Когда в моей команде было уже более 50 человек (в среднем – 5-7 на тимлида), я поймал себя на мысли, что давненько в код многих команд не заглядывал. Не в формате ежедневного ревью, разумеется, а хоть иногда, чтобы контакт с реальностью не потерять. И заглянул…

1. Стартапная команда

Стейкхолдеры переживают, что мы не очень быстро наращиваем функционал продукта. А в команде – вроде не бездельники.
Открываю репозиторий. И, к своему ужасу, вижу очень хороший и расширяемый код! Модульные тесты. Функциональные тесты. Интерфейсы. Фабрики. Документация.

Проект – в стадии прототипа, мы буквально не знаем при этом, будут ли у него пользователи! Мы, возможно, всё это выбросим через месяц 🙂

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

2. Команда большого продукта

Стейкхолдеры переживают, что мы подолгу тестируем фичи, а в итоге – и медленно, и с кучей багов получается. А в команде – опять же, не дураки.

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

– Пишем код
– Пишем тесты (ну не TDD и не TDD, подумаешь)
– Начинаем сборку в CI и выкатываем в тестовое окружение
– Отдаем на ревью
…

– Стоп! Сразу в CI и тестинг? А локальная сборка? А модульные/функциональные тесты – их же годами писали, сервис старый, нифига ты это не проверишь сам руками сейчас, и твой QA не проверит.
– Ну да. Половина тестов не работает локально, но запускается в CI, а другая половина – вообще не работает у сервиса
– И ты всё время так живешь? Это ж безумно медленно и опасно
– Ну..да
– А чего не жалуешься?
– А у нас давно так и было, я думал, это нормально (контекст: в команде за год по разным причинам сменилось множество людей + она выросла)

Пошли разбираться с тестами и сборкой. Снова вспоминаем, что очевидное тебе – не обязательно очевидно всем

Ну как, появилась мотивация ещё раз заглянуть под капот своей команды?

#Пятничное

По традиции – развлекательный контент в пятницу вечером.

1. Old but gold, «Теория Жоп»

https://habr.com/ru/articles/593173/

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

––

2. Как VK ускоряли работу приложения

https://www.youtube.com/watch?v=KDcOa_QbSQ0

Это – не реклама VK.
Это – история, которая может замотивировать работать над целью до тех пор, пока тебе не покажется, что стало «достаточно хорошо», а не до тех пор, пока у тебя не закончатся очевидные решения

Ребята начинают с пагинации и картинок, но позднее доходят до..алгоритмов сжатия, протоколов передачи данных и изменения сетевого стэка приложения

Если тебе было страшно внедрять новый фреймворк – посмотри это видео и больше не бойся 🙂

––

3. Как снимали «Матрицу»

https://habr.com/ru/companies/first/articles/724300/

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

– Подбор команды
– Костыли
– Бюджет
– Неочевидные решения

А можно – просто как развлекательный текст про продакшен крутого кино в 90-е/2000-е годы. В любом случае – по-моему, интересно!

О важном

Если у тебя за прошедшую неделю прочитаны все чатики, вылизаны все тикеты, сделано 10 коммитов в любимый опенсорс проект, то..возможно, у тебя проблемы с приоритетами.

Один из простых, как палка, но очень ценных инструментов менеджмента – матрица Эйзенхауэра.
Суть – на картинке. Почитать – что угодно из гугла или хабры.

Как приоритизировать:

1. Важное и срочное – сразу делать.
2. Важное и несрочное – делать или, как минимум, сразу планировать.
3. Неважное и срочное – делегировать или, хотя бы, фиксировать время, которое ты этому уделяешь.
4. Неважное и несрочное – честно признаться себе, что такие задачи – не более, чем развлечение. Выполнять только для собственного удовольствия или не выполнять совсем.

Мне – помогает, а тебе?

Давно нас не было на хабре!

Сегодня – про эффективный менеджмент! Или не очень эффективный..

https://habr.com/ru/articles/817617/

Лайки, репосты и комментарии – помогают 🙂

Loaded Question

Loaded question / нагруженный вопрос – вопрос, в который заложено твоё отношение к ситуации.

––

«Как дела у Васи?» – обычный вопрос
«Дела у Васи так себе, да?» – нагруженный вопрос

«Какой статус по проекту?» – обычный вопрос
«Проезжаем по срокам, да?» – нагруженный вопрос

––

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

1. Один раз на встрече хедов человек высокого уровня спросил:

– А что, Петю мы увольняем? (имя изменено)

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

2. В другой раз прозвучало

– Запуска без багов нам не ждать, верно?

Думаю, можно не комментировать, как это отразилось на отношении команды к QA и на уверенности QA в своей работе.
Запуск, кстати, всё равно случился с кучей багов – к тестированию особо серьёзно никто не отнёсся :)

––

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

Если, копаясь в деталях, ты обнаруживаешь настоящую, стопроцентную проблему, но команда этого не понимает – уже можно задать нагруженный вопрос или прямо сказать: «это – плохо!»

#ЧтоПочитать

Вечер пятницы и развлекательный контент:

1. «Стив Джобс», Уолтер Айзексон

Захватывающая история с пачкой инсайтов:

– Мировоззрение творческого человека vs профессионального менеджера
– Менеджмент мирного vs военного времени
– Как выглядит work-life balance топ-менеджера и существует ли он вообще?
– Насколько сильно переговоры влияют на карьеру, бизнес и жизнь людей?

А какие ты найдешь для себя?

2. «The Hard Thing About Hard Things», Ben Horowitz

Десять кругов менеджерского ада из десяти.
Если тебе надоели чрезвычайно мотивирующие книги, упускающие многие сложности управленческой карьеры – попробуй эту!

3. «Чапаев и Пустота», Виктор Пелевин

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

Если ты, вдруг, не любишь Пелевина – это нормально. Просто надо читать его старые книги, а не новые :)

Про найм

Совет для лидов, нанимающих в бигтех.
Или в другие компании, у которых есть стабильный процесс собеседований:

Нанимай за уникальные плюсы, а не за отсутствие стандартных минусов.

Классическая цепочка собеседований в бигтех проверяет отсутствие минусов, а не наличие плюсов.
К примеру, кандидат:

– Адекватен, умеет говорить (hr-скрин)
– Умеет писать код (секция с кодом)
– Не думает три дня над простой задачей (все секции)
– Не предлагает трешовых архитектурных решений (архитектурная секция)

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

Всё, что ты знаешь после проведения стандартных секций: «передо мной – человек +- уровня X».

––

Если хочешь найти не просто «сотрудника +- уровня X», а человека, который:

– Супер-ориентирован на бизнес-результат ИЛИ
– Очень крут в выстраивании процессов ИЛИ
– Умеет быстро разбираться в сложных плоходокументированных технологиях ИЛИ
– Может за ночь из говна и палок построить космолёт,

Стандартные секции тебе не помогут.

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

––

Как это сделать?

1. Выписать для себя набор желаемых качеств
2. Попытаться за время беседы проверить их наличие

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

Да, за мэтч по уникальным компетенциям можно простить промах на стандартной секции!

Getting Shit Done

Есть выражение (и даже методология) «getting things done» – про доведение дел до конца, управление задачами, проектами, и тд.

Сегодня мы про него говорить не будем.

Сегодня – про ключевой навык, отличающий крутого менеджера от обычного. Я называю его Getting Shit Done.

––

Почему не «Things?».

Раскидать и решить обычные «дела» (или «вещи») может любой менеджер, более-менее компетентный в предметной области и вооруженный ежедневником.

Самые большие неприятности, при возникновении которых зовут крутого менеджера – это никакие не things. Это именно Shit, в котором ты ничего не понимаешь, к которому не готов и готовым быть не можешь:

– На машину сотрудника упало дерево
– Ключевые разработчики проекта подрались на корпоративе, один остался без зубов и не хочет помогать второму
– У тебя горит дедлайн по сделке с иностранными партнёрами, а единственный человек из их команды, нормально говорящий по-английски, заболел
– Ты готовился к важному запуску, но вышел подышать воздухом в обед и сломал две руки в пяти местах (не шутка, история из жизни)
– Ты запускаешь новый сервис, а на следующий день узнаешь о готовящемся законопроекте, который ставит под вопрос его существование

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

Крутой менеджер – ищет решение с учетом новых вводных, даже если эскалировать некуда. Что удивительно – проекты при этом часто выживают (хоть и сильно меняются).

––

Будь крутым менеджером! Как минимум, это весело :)

Тестирование в продакшене!

В больших компаниях обычно есть «тестовое окружение» – среда, в которой разворачивается приложение и в него тыкают разрабы и QA.

Лиды порой приобретают привычку говорить (и, что страшнее – думать!), что код работает как надо, если в тестовой среде не нашлось багов, прошли модульные и интеграционные тесты и тд. В идеальном мире – так оно и есть, но в реальном..если ты работаешь над большим приложением, которому много лет: этот подход не работает!

––

Почти всегда найдется:

– 10 конфигов, расходящихся в проде и в тестинге
– Паттерны использования приложения, до которых дошли странные юзеры и не дошли qa
– Блоки кода твоих коллег, которые включены в проде и выключены в тестовой среде
– Разница по нагрузке и данным, проходящих через разные окружения (моё уважение людям, которые льют в тестинг часть данных и нагрузки из прода! К сожалению, этот подход не устраняет остальные обозначенные проблемы).
– Банально невнимательный участник команды, который забыл проверить какой-нибудь сценарий на себе

Как следствие – вместо ожидаемого запуска на пользователей («всё ведь протестировано и работает – выкатим да включим») в день X происходит..получение 10 баг-репортов из прода и изменение графика поставки.

Решение: относиться к любому крупному изменению как к эксперименту

Даже если продуктовые метрики не должны прокраситься. Даже если это – «просто большой рефакторинг» (или оптимизация времени ответов бэкенда на 20%). Во многих случаях, выкатив сделанное на процент пользователей (или на всех сотрудников компании; или на город) ты, внезапно, соберешь пачку багрепортов, а иногда – увидишь прокрасившуюся в неожиданную сторону метрику :)

После эксперимента в проде – функционал и правда протестирован и готов к включению 🙂

#Пятничное

Время контента в пятницу вечером!

1. https://hbr.org/2008/02/getting-the-best-employee-idea

Old but gold: про ценность «маленьких» идей по улучшению продукта, приходящих от команды, а не от менеджмента.

И про то, что успех продукта и компании – не только в стратегических проектах :)

2. https://kinzhal.media/la-chaise/

Подписчики канала не узнают ничего нового для себя из этой статьи. Но она – не для вас!
Это – бесплатная инструкция, которую можно дать джуну или миддлу в своей команде и понадеяться на изменение подхода к работе :)

––

Третьего пункта сегодня не будет, поздно ведь уже, а спать – тоже нужно:)
Зато вместо одного мема будет сразу два, запомнившихся мне за эту неделю.

Поделись своими в комментариях!

––

upd: к своему ужасу узнал, что пост при добавлении двух картинок разрезается на три последовательных сообщения! Вот это я понимаю – пользовательский опыт. Удалять я их, конечно же, не буду :(

Не забудь подумать

Когда моя команда стала большой, у меня регулярно стали возникать недели, на 80-90% состоящие из встреч:

– Статусы по проектам
– 1х1-ы
– Встречи со стейкхолдерами
– Встречи с разборами проблем
– Обеды со смежниками
– ….

Всё, вроде, по делу.

Но есть две проблемы:

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

b. Качественно проводимые встречи сжигают энергию

Получается, если в день у тебя 10+ встреч – ты и на синках не можешь серьезно поразмышлять, и после них – тоже (энергии недостаточно!).

––

Осознав эту проблему, я пришел к практике, которой пользуюсь до сих пор:

Каждую неделю бронирую в календаре несколько часов времени для самостоятельной работы

Я использую их так:

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

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

––

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

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

Важно, чтобы это время было зарезервировано как полноценная встреча в рабочем календаре (можно сделать её закрытой). Иначе кто-нибудь его отберёт 🙂

О консервах в собственном соку

Рано или поздно растущий управленец оказывается в интересной позиции: руководитель перестаёт быть более экспертным в его домене.

Иногда это происходит на должности CTO/CPO/C*O.
Иногда – раньше.

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

Если тебе доводилось встречать компанию, в которой практики разработки/дизайна/etc устроены «как 10 лет назад», надежно законсервированы – скорее всего, C*O как раз наступил на эти грабли.

––

Что с этим делать?

1. Общаться с людьми из других компаний.

Если фидбека в компании получить негде – поищи снаружи :) Теперь это – часть твоей работы.

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

Я сам, хоть и с усилием, но не реже раза в полугодие заставляю себя выбираться из берлоги и смотреть: «а чего там во внешнем мире?».

––

2. Хотя бы понемногу нанимать подчинённых-лидов извне

Практика «промоутить на управленческие позиции ребят из компании» – хорошая и имеет множество плюсов.

Но если все руководящие должности оказываются заняты «своими ребятами», повышаются риски застрять в локальном максимуме компетенций.
Чтобы не застаиваться, полезно иногда приглашать в коллектив экспертов с другим опытом и давать им право голоса (в том числе – право с тобой спорить).

––

А что ещё ты делаешь, чтобы не консервировать себя и компанию?

Советы для M1. Планирование

Возвращаемся к ответам на вопросы.

Что бы ты сейчас посоветовал себе, когда только начинал быть лидом М1?

Полноценный ответ требует статьи на хабр, она выйдет позже 🙂
А пока – про одну из частых проблем M1: планирование.

––

У начинающих лидов часто возникает один из двух интуитивных подходов к планированию:

1. Прикину, за какое время я сам бы сделал задачу. Отнормирую на уровень сотрудника

Например:
a. Синьор – сделает с такой же скоростью, как я.
b. Миддл – в два раза медленнее.
И т.д.

Внезапно, такие предсказания ломаются.

2. Спрошу у сотрудника, сколько времени у него уйдет на задачу. Если уровень невысокий – умножу на менеджерский коэффициент.

a. Синьор оценил задачу в три дня – добавлю денек на баги
b. Миддл оценил в три дня – умножу на два
c. Джун оценил в три дня – помоги мне бог, чтобы сошлось до конца месяца

И..такие предсказания тоже ломаются!

Люди слишком сложны, чтобы надёжно предсказывать их производительность по уровню или должности.

––

А что тогда делать с прогнозами?

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

Во время планирования абстрагируйся от должности/внешней уверенности человека. Смотри на историю его работы с завершенными задачами:

– Если в предыдущих двух спринтах он закрывал задач на «5 сторипоинтов», не стоит ожидать, что в этом спринте он закроет 10, потому что «заказчикам очень нужно» или «ну я соберусь и затащу, честное слово!»

– Если в прошлый и позапрошлый раз у разработчика ушло по неделе на написание http-хэндлера, пишущего в базу, не стоит ожидать, что в этот раз он сделает то же самое за два дня

Тот же подход применим для ответа на вопрос: «сколько за итерацию сможет сделать команда?»

––

А как же рост эффективности? Люди что, не могут развиваться и учиться?

Могут. И в развитие команды нужно вкладывать своё время. Но:

Человек обучился и прокачался, если ты на данных видишь, что он стал делать больше / выше / лучше и т.д.

Планировать больше можно начинать только тогда, когда человек уже и так делает больше. Не наоборот!

О дедлайнах

Если кто-то должен что-то для тебя сделать, обязательно нужен дедлайн и ответственный.

– Запилите новый пуш? А когда? А кто лично сделает и проследит? Спасибо, записываем: Саша, до 19 июня

– Проведёте воспитательную беседу с андерперформером? А кто и когда? Спасибо, записываем: Андрей, завтра

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

Зачем это нужно?

Во-первых, приоритизировать умеют не все. Твою «важную» задачу без дедлайна запросто могут задвинуть в пользу менее важных, но имеющих дедлайн. Ну а что – договорённость-то не нарушена :)

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

––

Когда в следующий раз договоришься о чём-то – обязательно проговори вслух и запиши ответственного и дедлайн. Иначе – можно было и не договариваться :)

Продуктивного понедельника и успешных переговоров!