“Что делать, когда кардинальные изменения в процессах демотивируют команду”. Опыт бэкенд-инженера, ставшего тимлидом

Я 7 лет работал бэкенд-инженером в Miro, затем стал тимлидом. За последние годы наша инженерная команда выросла вдвое, стала распределённой и международной, что повлекло за собой множество изменений.

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



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

В итоге мы справились со штормом, вдвое уменьшили Lead Time и существенно продвинулись в эффективности кросс-функциональных команд. Этому во многом помогло изменение нашего отношения к происходящим переменам, переход от Fixed mindset к Growth mindset.

Ниже — видео и расшифровка моего выступления на Saint TeamLead Conf 2019, где на примере своей команды я рассказываю про процессы и инструменты, которые сделали эти изменения возможными.


История №1. Изменение процесса разработки для уменьшения Lead Time


В 2016 году наша разработка состояла из 20 человек и 5 команд. Команды эффективно взаимодействовали друг с другом, быстро обменивались информацией и опытом. По мере роста сотрудников и команд, внедрения процессов CI/CD и код-ревью количество взаимозависимостей между командами увеличивалось.

Например, для вывода на прод большой фичи команде нужно было работать с ещё 6 инженерными командами:

  • Отдать код на сode review.
  • Отдать фичу на тест QA. При необходимости QA подключит команду DevOps для создания специального тестового окружения.
  • Зарелизить фичу с помощью релиз-менеджера, который отвечает за все релизы в компании.
  • Подключить дополнительные команды, если во время релиза что-то пойдёт не так.

И это без учёта зависимостей с командами маркетинга, дизайна и технической поддержки, которые тоже активно участвуют в запуске фичей.

Чем больше зависимостей, тем больше Lead Time, то есть время от старта разработки до релиза. Чем выше Lead Time, тем меньше ценности мы доставляем до пользователей.

Большое количество коммуникаций и низкая скорость доставки демотивируют команду. Что делать? Уменьшить количество зависимостей и сократить Lead Time.

Пробуем построить конвейер в разработке


Для решения этой задачи мы первым делом попробовали построить конвейер:

  • описать все этапы и процессы;
  • ввести SLA (Service Level Agreement, уровень необходимого качества), чтобы определить время, за которое задача должна проходить каждый этап;
  • выпрямить потоки, чтобы не допускать повторного ухода задачи на предыдущие этапы для доработок.

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

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

Пробуем построить кросс-функциональные команды


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

Мы решили провести эксперимент на нескольких командах, прежде чем раскатывать изменения на всю компанию. В эксперимент попала и моя команда, которая занимается в основном низкоуровневыми задачами (я писал про один из примеров нашей работы — внедрении ActiveMQ и Hazelcast). Команда состояла из 3 бэкенд-разработчиков, part-time QA-инженера и меня в роли тимлида.

Определяем взаимозависимости


Первым делом мы определили текущие зависимости, от которых хотим избавиться:

  • Нет своего full-time QA-инженера, в результате чего можем ждать тестирование от нескольких дней до недели.
  • Не можем самостоятельно релизить фичи, потому что за вывод на прод отвечает релиз-менеджер.
  • Нет своего full-time скрам-мастера, поэтому иногда пропускаем груминги или ретроспективы, что приводит к снижению эффективности.

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

Учимся тестировать самостоятельно
Раньше инженеры самостоятельно писали unit-тесты и тестировали базовый функционал, остальное проверял QA. Теперь мы учились самостоятельно тестировать пограничные ситуации и писать end-to-end тесты, чтобы проверять взаимодействие между клиентом и сервером.

Учимся релизить самостоятельно
Мы договорились, что хотим релизить как минимум раз в неделю. Для этого нам нужен релиз-менеджер внутри команды. Им по собственному желанию стал один из бэкенд-разработчиков.

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

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

Первые провалы


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

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

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

История № 2. Новая роль и страх ошибки


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

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

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

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

В ситуации с Андреем оказалось, что он протестировал самостоятельно свой код и был уверен, что всё хорошо. Однако на всякий случай отдал на проверку QA, а тот нашёл в коде 5 багов. Это повторялось несколько раз, что демотивировало Андрея, и он решил больше не заниматься тестированием.

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

Установка на рост и установка на данность


Когда я стал тимлидом, мне посоветовали прочитать книгу «Гибкое сознание» профессора Стэнфордского университета Кэрол Дуэк (Carol Dweck). Если кратко, то в ней рассказывается о двух типах мышления:

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

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


Вся схема — на сайте Кэрол Дуэк

Этот подход хорошо описывает отношение человека к происходящим изменениям.

Люди с преобладанием Fixed mindset (установка на данность)
  • Жертва изменений: «Я так хорошо работал, а тут пришли вы и начали всё менять».
  • Не разбираются в истинных причинах, а просто возмущаются. Если процесс идёт не по плану, они говорят, что всё плохо и нужно возвращать всё как было раньше.

Люди с преобладанием Growth mindset (установка на рост)

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

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

Дополнительно я рассказывал каждому в команде о собственном примере работы с установками в момент смены роли с инженера на тимлида. Это добавляло остальным уверенности в себе («не я один с этим столкнулся», «эту ситуацию реально изменить»).

Продолжение истории № 2


Эксперимент снижает уровень ожиданий и стресса. После обсуждения подхода с Growth & Fixed mindset мы договорились с Максом запустить эксперимент в рамках которого он попробует новую для себя роль скрам-мастера. Слово «эксперимент» хорошо снижает градус напряжения. В эксперименте не страшно ошибаться, но важно делать работу над ошибками и выносить полезный опыт. В этом же ключе мы рассказали о новой роли Макса команде, что снизило ожидания у команды.

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

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

На уровне всей компании у нас работает система OKRs, поэтому мы решили применить её для уровня личного обучения. Условия были такие:

  • Добавляем в личные OKRs только то, что помогает в текущей работе;
  • Key Results должны быть измеримы в любой момент времени и помогать отвечать на вопрос «Насколько я продвинулся в сравнении с прошлой неделей?;
  • У каждого ключевого результата есть список инициатив, которые позволяют его достичь;
  • Можно добавлять внерабочие активности (спортивные, творческие), они помогают отдыхать и переключать контекст, а это повышает эффективность на работе;
  • Трекаем прогресс по OKRs на регулярных встречах 1:1.

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

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

Пример OKRs Андрея



Бонусом мы договорились поделиться личными OKRs внутри команды. Это помогает учиться друг у друга и работает как публичный коммит.

Продолжение истории № 1


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

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

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

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



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

Моей команде помог справиться с изменениями и отношением к ошибкам Growth & Fixed mindset. Мы относимся к нему как к рабочему инструменту, который решает конкретные задачи. Разумеется, изменение установки не произошло за несколько недель и месяцев. Но меняя отношение к конкретным ситуациям, мы смогли за квартал сильно продвинуться вперёд в отношении к ежедневным рабочим задачам и сложностям.
Miro
Online collaborative whiteboard platform

Комментарии 16

    +1

    С "Я не хочу этого делать" как-то слишком просто. Банальное "не интересно" или "надоело" куда отнести? Вот лежат интересные задачи на разработку в бэклоге, а тут 100500 кейсов тестировать надо, или схемы рисовать или встречи организовывать. "Кроме тебя больше некому","мы в одной лодке" (ценность донесли и выбор объяснили) какое-то время может работать, но недолго, если для себя лично (не для проекта, не для команды, а для себя) интереса человек не видит. Освоил, может даже до автоматмизма основные вещи, а расти дальше не собирается.

      0
      Мне кажется, любое «неинтересно» можно раскрутить дальше.

      Почему задачи в эклоге кажутся интересными, а рисование схем — нет? Возможных ответов много и каждый что-то большее, чем «мне просто неинтересно», значит к каждому можно найти решение:
      1. Рисование схем — глупая задача для джунов, а я хочу лютого хардкора.
      2. Схемы я рисую каждую неделю, хочется чего-то нового.
      3. Я просто не умею хорошо рисовать схемы и т.д.

      С одной стороны, понятно, что всем нам хочется делать только то, что «интересно». С другой стороны, в любой работе всегда есть рутина и задачи, которые надо сделать через не хочу. Поэтому нужно учить себя находить новый интерес в рутине. У Людвига Быстроновского про это есть много рассуждений, на банальных примерах: чистить зубы 3 минуты каждый день неинтересно, но если начать их чистить другой рукой или под музыку или приседая одновременно, то на какое-то время это снова вернёт интерес.
        0

        Ну вот, допустим первый вариант (хотя скорее "рисование схем — нудная задача для архитектора, а я хочу лютого хардкора"). Предложить ему рисовать схемы, приседая? Вряд ли поможет.


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

        +2
        Самое главное — начать диалог и понять внутреннюю мотивацию сотрудника.

        Как мне кажется, если человеку не интересно, то он не видит ценность именно для себя. Например, он не понимает как в этом направлении можно расти дальше или он видит направление где он может быть более полезным. Может быть задача в текущем виде и правда наскучила, но ведь тогда ее можно изменить чтобы она стала сложнее и интереснее:
        1. Запрашивать оценку проведенной встречи от участников, чтобы мерить ее эффективность (по типу NPS) и стремиться к росту этой оценки
        2. Описать фреймворк рисования схем, упростить его и научить ему людей, которым это интересно.

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

          По-моему, с этого нужно начинать. Хоть табличку завести "сотрудник — интересы/ценности" хоть по результатам опроса "кем себя видите через 5 лет" и задачи соответственно декомпозировать

            0
            > если человеку не интересно, то он не видит ценность именно для себя

            спасибо за эту простую, но возможно очень полезную мысль, надо попробовать.
          +1
          Спасибо за статью, тема близка и есть несколько вопросов.
          1. Кросс-функциональность. Как мотивируете сотрудников? Что если человек не хочет развиваться туда, куда нужно команде, как мотивируете?
          2. OKR для роста каждого сотрудника. Как измеряете, как мотивируете выполнять или даже вообще заниматься постановкой?
          3. Кросс-функциональные команды это интересно, но как быть, если сотрудник хочет расти вверх, а не вширь? В LeSS и Scrum об этом как-то не упоминается.
          4. Какая роль тимлида в кросс-функциональной команде, в которой все должны быть самостоятельны и разбираться в нескольких компетенциях? И команд как правило несколько, в каждой свой тимлид?
          5. Почему у вас в кросс-функциональной команде только бэкендеры, QA и релиз-инженер (devops?)? Кто делает фронтэнд?
            +1
            Спасибо за вопросы! Отвечу по порядку:

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

            2. У нас есть грейды с описанием, плюс в каждой команде у Team Lead есть конкретные ожидания от каждого участника(так же прописанные в документе), плюс есть большой бэклог задач, некоторые из которых действительно сложные, плюс раз в пол года проходит Performance Review. В общем мы стараемся показать где человек сейчас, проговариваем куда бы они хотел расти, даем фидбек по тому, чего для этого не хватает и совместно придумываем план роста.

            3. Вверх — менеджерская позиция? Или имелось ввиду вглубь?

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

            5. Это специфика моей команды. Мы занимаемся высокими нагрузками, отказоустойчивостью и масштабированием в части бэкенда. Экспертиза во фронте бывает нужна редко, но даже для этого случая у нас есть человек, который в этом разбирается.
              0
              Так а кто у вас в компании/проекте занимается фронтендом? Это какая-то отдельная команда? А как тогда построено взаимодействие с ними? Как происходят совместные релизы?
                0
                У каждой команды есть область, за которую они отвечают и в которой пилят функционал.
                Например, команда Canvas отвечает за базовое поведение канвы на клиенте и основные виджеты в ней. Для того, чтобы команда эффективно делала свою работу, им нужен бэкенд и фронтэнд инженеры.
                Для команды Canvas-UX бэкенд инженеры практически не нужны, потому что цель команды — улучшать пользовательский опыт имеющегося функционала. В редких случаях, когда что-то нужно сделать на сервере, команда справляется своими силами.
                  0
                  Я правильно понял, что у команды Canvas есть необходимость как в бэкенд-разработчиках, так и во фронтенд-разработчиках, и поэтому данная команда не является кросс-функциональной? Или внутри все же есть разделение на две подкоманды?

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

                    Как раз команда Canvas является кросс-функциональной, так как в ней пересекаются несколько необходимых ей функций: бэкенд и фронтенд инженеры, QA, дизайнер, тим лид, product owner. В сумме команда состоит из 6 человек и внутри нет никаких подразделений.
                    Все участники команды направлены на решение одной конкретной цели. Например, если нам нужно реализовать новый виджет, то:


                    • Product owner прорабатывает постановку и пользовательские сценарии
                    • Дизайнер создает макеты и чистовой дизайн
                    • QA подготавливает тестовые сценарии на основе пользовательских
                    • Бэкенд инженер определяет схему данных и интерфейсы взаимодействия с клиентом, пишет логику на сервере
                    • Фронтэнд инженер пишет логику на клиенте, ориентируясь на интерфейсы взаимодействия с сервером; внедряет дизайн.

                    У каждого своя роль в процессе достижения цели. Благодаря тому, что эти роли находятся внутри команды мы снижаем время на коммуникации и ускоряем процесс поставки ценности.

                0
                Спасибо за ответ!
                По 3 вопросу — да, я имел в виду рост вверх, в управленцы :) Обычно в scrum и less об этом как-то вскользь упоминается.
                0
                Почему у вас в кросс-функциональной команде только бэкендеры, QA и релиз-инженер (devops?)? Кто делает фронтэнд?

                Частое заблуждение, по-моему, что кроссфункциональная команда — это end-to-end, fullstack команда. Если говорить о Scrum-like подходах, то кроссфункциональная команда — это команда, способная реализовать какую-то user story без зависимостей от других команд. Но User Story вполне может быть записана наподобие "Я, как фронтенд разработчик, для реализации UI такого-то хочу иметь API endpoint..."

                  0
                  Но user story бывают разные :) не всегда же команда будет делать только API? Кроме того, такой подход (сначала 1 команда делает API, потом другая команда делает фронтэнд) увеличивает time-to-market, за который все беспощадно борются.
                    0

                    Бывают разные, да. Но там, где фронт и бэк строго разделены, бизнес-сторя как-то бьётся на части, вернее из неё выделяется техническая для бэка. А для TTM делают параллельно: согласовали API, фронт сделал моки и пилит. В конце какое-то время резервируется на интеграцию.

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

              Самое читаемое