Привет, Хабр! Меня зовут Егор Толстой, я — ведущий подкаста Podlodka и автор Роадмапа Тимлида. Веду телеграм-канал Teamlead Good Reads, где каждый день делюсь идеями о работе с командами.
Сегодня — перевод и разбор классной статьи инженера, технического директора и основателя стартап-инкубатора Limbe Labs и лаборатории Red Hat Джереми Брауна. Он рассказывает о том, как эффект IKEA (тот самый эффект, когда мы особенно ценим то, что сделали сами) может работать, и как иногда он больно бьёт по управлению изменениями.
Статья будет полезна всем, кто работает с изменениями: в командах, продуктах, процессах. Разберём, почему хорошие идеи проваливаются, если не вовлечь людей, и какие практики помогают вовремя поймать баланс между инициативой и навязыванием.
Что будет в этой статье:
Эффект IKEA — идея в том, что людям больше нравятся вещи, которые они делают сами. Рассмотрим, как это может помочь с изменениями в рабочих процессах.
Фейл — история о том, как Джереми не применил эффект IKEA при внесении изменений, хотя стоило.
Полученные уроки: даём ответ на вопрос «зачем», составляем черновики вместо идеального документа, вовлекаем людей и разумно делегируем задачи, создаём общий контекст, даём обратную связь, выдерживаем разумный темп без спешки.
Эффект IKEA
Недавно я неудачно провёл изменения — не последовал собственному же совету. Обычно я считаю, что любые изменения нужно делать вместе с теми, кого они затрагивают. В недавней рассылке «Коллективная сила совместного создания общих принципов» я писал:
«Лучший способ сформулировать принципы — вовлечь всех через эффект IKEA. Когда каждый вносит вклад в создание, а не получает готовое сверху, растёт вовлечённость и приверженность».
Что такое эффект IKEA?
В Википедии есть отличное определение:
«Эффект IKEA — это когнитивное искажение, при котором потребители непропорционально высоко ценят продукты, которые они частично создали. Название отсылает к шведскому производителю и продавцу мебели и аксессуаров для дома IKEA, который продаёт изделия, требующие сборки.
Исследование 2011 года показало, что испытуемые были готовы заплатить на 63% больше за мебель, которую собрали сами, чем за эквивалентные уже предварительно собранные предметы.
Этот подход можно использовать при внесении организационных изменений: совместно создавать изменения с теми, кого они затрагивают. Ведь когда люди участвуют в определении, разработке и совершенствовании решений, они чувствуют свою причастность. Это повышает понимание, поддержку и принятие изменений».
Фейл
К сожалению, в порыве энтузиазма по поводу внедрения изменений я проигнорировал свой же совет, и ситуация закончилась провалом. Надеюсь, рассказ об этом поможет вам извлечь уроки.
Работая с клиентом, я анализировал процессы и искал точки роста. На уровне отдельных команд всё выглядело неплохо, но на уровне всей организации быстро стало ясно: Engineering воспринимается как «чёрный ящик». Бизнесу не хватало прозрачности — по крупным проектам и срокам их реализации. Параллельно я заметил и другие типичные проблемы в работе, характерные для их стадии развития и модели B2B SaaS.
Не вдаваясь в дальнейшие подробности работы компании, я попал во ВСЕ классические ловушки. Поэтому моя история ярко иллюстрирует, как НЕ НАДО вносить изменения.
Вскоре мои наблюдения подтвердились: разговоры с CPO и CTO показали, что проблемы действительно есть. Эти области для улучшений совпадали с тем, что было прописано в моём документе на проект, в котором кратко изложил свои мысли. Поэтому я без промедления начал действовать.
У меня было чёткое понимание, каким должен быть хороший результат в этой ситуации. Я собрал CPO и CTO на семинаре, где мы вместе набросали черновик моего предложения на доске. Мне нужно было сначала выстроить согласованность на уровне руководства, прежде чем идти к команде — тем более что моя роль была временной, и важно было, чтобы изменения получили поддержку в долгосрочной перспективе. То, что мы тогда собрали, казалось нам логичным и осмысленным.
Я взял наш предварительный план и начал оформлять его в официальный документ. Перенёс все наброски в структурированное предложение — основу для живого документа, который впоследствии можно было бы использовать в качестве описания, как устроены процессы в организации. Я рассчитывал, что вместе с развитием самой практики будет эволюционировать и этот документ.
Я проделал большую работу. Документ становился всё длиннее, потому что я пытался собрать все идеи в связное и понятное описание. Наше предложение не предполагало радикальных изменений для организации, но всё-таки включало новую терминологию, множество уточнений и несколько сдвигов на уровне структуры и принципов работы.
В пятницу, перед уходом в недельный отпуск, я сделал большой анонс. Написал, как мне казалось, хорошее сообщение в Slack: поделился предложением с командой, объяснил, что это не финальный вариант, а отправная точка для обсуждения. Подчеркнул, что изменения затрагивают их работу, а значит, им важно дать обратную связь — ведь именно им потом жить по этим новым правилам.
Но ответом стали несколько негативных комментариев и гробовая тишина. Да, предсказуемо. Но, поверьте, переживать это снова, рассказывая эту историю, сложнее, чем читать об этом.
Что же произошло? Ведь у меня были добрые намерения, я пытался решить проблему целых команд. Почему же реакция была негативной?
Давайте поговорим о том, что я сделал через призму того, как мне следовало бы поступить.
Полученные уроки
Вот что я на самом деле должен был сделать, чтобы получить другую реакцию.
Рассказать, что я делаю, и, что ещё важнее, почему. Причём как можно раньше!
Я работал в фоновом режиме. Люди знали, что эта работа — часть моей миссии в компании. Ведь я рассказывал об этом и на общих встречах, и в личных разговорах ещё во время онбординга.
Но до семинара с CTO и CPO я должен был рассказать сотрудникам компании, что начинаю делать и напомнить, зачем это нужно.
Установить общее «зачем» и совместно определить проблему
Нужно было вовлечь команду ещё на этапе определения проблемы. Когда люди решают проблему сообща, они сильнее вовлекаются в её решение. Если хочешь получить настоящий вклад, важно начинать с обсуждения первопричины, а не приходить с готовым решением. Обратную связь проще и естественнее получать, когда есть открытые вопросы, а не завершённый документ.
Меня всегда удивляло, насколько разные идеи могут предлагать люди. Часто это решения, о которых я сам бы даже не подумал. Всё потому, что мы смотрим на вещи через разные опыт и призму восприятия. Это не вопрос чьей-то «правильности» — мы просто видим задачи по-разному.
Если использовать эту разницу правильно, на этапе расхождения — когда собираются мнения и взгляды с разных сторон — можно гораздо лучше сформулировать проблему. А значит, и найти более сильное решение.
Кроме того, вовлечение людей в определение процессов и методов или разработку изменений помогает им лучше понимать свою собственную роль и видеть её в более широком контексте.
Предоставить черновик, готовый на 20%, а не законченный шедевр
Я начал с установки, что изменение входит в мою миссию, а значит, у меня есть на него мандат. Я был уверен, что понимаю, что именно нужно менять. Затем я вышел к команде с тщательно проработанным, отполированным документом — тем, над которым я сам много размышлял и который мне был действительно важен. Но именно из-за того, насколько «готовым» выглядел этот документ, у людей не возникло ощущения, что они могут что-то в него добавить или изменить. В нём просто не было места для их вклада или участия.
Когда людям показывают полностью готовое предложение, у них подсознательно не видят возможности внести в него свой вклад.
Это как прийти на ужин, где всё уже приготовлено хозяином заранее: можно только поесть, но повлиять на меню — уже никак. То же самое происходит и с изменениями в работе: если команда видит перед собой законченное решение, а не черновик, ей сложно почувствовать вовлечённость или ответственность за итог.
А теперь представьте другую ситуацию — не ужин, а кулинарную вечеринку. Вас не просто угощают готовым блюдом — вы вместе с другими выбираете ингредиенты, пробуете, предлагаете идеи прямо в процессе готовки.
Именно такое вовлечение создаёт ощущение причастности: финальный результат становится частично вашим. Это как раз тот эффект, которого стоит добиваться, если хотите, чтобы команда поддержала изменения — подключать людей на самых ранних этапах, а не в конце.
Это не значит, что на каждом этапе все должны быть на кухне и всё готовить вместе. Но приглашение к сотрудничеству на ранней стадии делает итог гораздо лучше — и насыщеннее, и понятнее для всех участников.
Я мог бы пойти другим путём: попросить нескольких волонтеров помочь мне проработать идею, вовлечь представителей от разных команд или собрать их обратную связь заранее. Даже небольшое участие дало бы людям ощущение, что они тоже приложили руку к изменениям.
Использовать своё положение с умом
Я не подумал о том, как воспринимается моя роль. Формально я находился на одном уровне с начальниками тех, кто должен был дать обратную связь. А на деле выглядело так: небольшая группа руководителей подготовила аккуратный, законченный документ и принесла его в команду.
Просить сотрудников критиковать предложения своих руководителей — всегда непросто. Даже если обратную связь искренне просят, люди естественно опасаются: вдруг их слова воспримут как критику? Вдруг это аукнется на карьерных перспективах?
Вот мои мысли на этот счёт:
Очевидно, что нам хочется, чтобы сотрудники чувствовали себя психологически безопасно. Без этого ни на какую честную обратную связь расчитывать не приходиться. Причём этого важно добиться ещё до того, как вы начнёте задействовать команды в изменениях.
То, как именно вы даёте обратную связь, имеет решающее значение. Технические специалисты иногда звучат жёстче, чем хотят, из-за особенностей коммуникации. Здесь важно помочь — и себе, и команде. Я оформил несколько мыслей по этому поводу в пост на LinkedIn , а мой друг Петер Сас написал статью для менеджеров о том, как справляться с негативным поведением, советую её прочитать.
В результате, молчание со стороны сотрудников в ответ на мой документ об изменениях было вполне предсказуемым. Даже если вовлекать команду с самого начала, нужно учитывать ещё одну важную вещь — влияние вашей позиции.
Вместо того чтобы брать всё на себя, правильнее было бы делегировать части задачи: передать отдельные куски определения или проектирования членам команды. Тогда люди почувствовали бы большую причастность, а процесс стал бы действительно совместным.
Привлекать людей и разумно делегировать
И вот мы незаметно подобрались к пятому шагу — делегированию. Если бы я делегировал часть работы команде, пришлось бы сразу дать очень подробное задание. Важно было бы объяснить не только, что именно нужно сделать, но и как будет использоваться результат их работы. Без этого сложно ожидать вовлечённости и осознанного участия.
Бессмысленно просто собрать людей и сказать: «Придумайте три варианта — потом выберем лучший». Нужно сразу договориться: как именно мы будем выбирать между вариантами? Кто принимает решение — я или мы вместе? Какие ограничения есть заранее: что выходит за рамки задачи и точно не будет принято?
Очень важно заранее проговорить рамки. Мы точно не хотим оказаться в ситуации, где команда вложит кучу сил в поиск решения — а мы потом его просто отвергнем. Такое сильно бьёт по мотивации и доверию: после этого снова вовлечь людей будет почти нереально. Это идеальный способ разрушить рабочие отношения.
Поэтому полезно заранее подумать: какое самое худшее развитие событий возможно? И сразу установить границы допустимых вариантов, чтобы не попасть в эту ловушку.
Использовать правильный тон
Ещё одна ошибка была в том, как я запрашивал фидбек. В тексте я писал: «Это процесс, над которым я работал. Я разработал...» — то есть использовал «я»-язык и прошедшее время. Это звучало как: «Процесс уже готов и принадлежит мне».
На самом деле мне стоило сформулировать иначе: «Мы работаем», «Мы разрабатываем», чтобы показать — работа идёт, процесс общий, и участие каждого ещё важно. Формулировка сильно влияет на восприятие.
Дать время на обратную связь
Анализируя ситуацию, я также понял, что рросто вывалил на очень занятых людей большой документ с расплывчатым запросом: «Дайте обратную связь». Они только что получили информацию и не успели её переварить.
Правильнее было бы пойти по-другому: начать с простого и узкого вопроса вроде «Каково ваше первое впечатление?» или «Что особенно бросается в глаза, если смотреть на это в целом?», а потом уже двигаться к более конкретным вопросам. Такой подход помог бы избежать перегрузки и дал бы людям точку входа в обсуждение.
Представьте, что вас попросили ответить: «Что вы любите есть?». Скорее всего, ответ будет скомканным — в голове всплывёт всего пара блюд.
Но если сначала задать более широкий вопрос — например, «Какая кухня вам нравится больше всего?», а потом уточнить: «А какое блюдо в этой кухне любимое?» или «Какие ингредиенты вам особенно нравятся?», — ответ получится более полным и вдумчивым.
То же самое работает и с обратной связью. Чтобы люди дали качественный фидбек, важно не просто «попросить высказать мнение», а направлять их вопросами от общего к частному.
Мне также следовало спросить:
Как это решит нашу проблему?
Что, по вашему мнению, необходимо добавить?
Что ещё стоит дополнить?
Какие важные аспекты мы могли упустить?
А дальше — задавать уточняющие вопросы в зависимости от ответов. Такой подход помог бы собрать более конкретную и полезную обратную связь, а не просто формальные отклики.
Замедлить темп, чтоб продвигаться быстрее
Вовлечение команды даёт много преимуществ: и в определении проблемы, и в выборе способа её решения.
Иногда кажется, что работать одному быстрее и легче — и это действительно так. Мне, например, удалось довольно быстро собрать неплохой документ. Комитет точно делал бы это дольше. Но скорость — не всегда главный критерий качества, когда речь о долгосрочных изменениях.
Если смотреть на процесс целиком — от идеи до внедрения, — становится очевидно: я недооценил важную часть работы. Изменения нужно не просто продумать, но и донести до людей, убедить их, чтобы они приняли новые правила осознанно, а не просто формально согласились.
Эти усилия всё равно придется потратить — либо в начале, либо в конце. И теперь я точно знаю, какой путь правильнее. В следующий раз я снова выберу вовлечение с самого начала.
В этой истории я особенно остро осознал реальную опасность: если работать над изменениями в одиночку, не вовлекая людей, легко неправильно интерпретировать их молчание. Кажется, что команда не хочет проявлять инициативу или брать на себя ответственность.
Когда всё держишь на себе, начинаешь чувствовать перегрузку и раздражение. Возникает соблазн перейти к директивному стилю управления — просто указывать, что и как делать. Это быстро убивает доверие в команде и рушит отношения.
А ведь у каждого есть достойные идеи. Если вовремя вовлекать людей в работу, можно сохранить доверие и вместе добиваться куда более сильных результатов.
Резюме
Подведу итоги:
Начинайте изменения с рассказа, что именно вы делаете и зачем.
Привлеките людей к решению проблемы. Это объединит вас и поможет найти лучшее решение.
Не показывайте готовый документ, лучше, оставьте его незавершённым, чтобы люди могли внести в него свои идеи и соображения.
Учитывайте, что ваша роль может влиять на восприятие предлагаемых вами изменений. Чем выше ваш статус, тем сложнее людям давать обратную связь. Продумывайте, как снизить этот барьер.
Вовлекайте и делегируйте — это умный подход. Укажите, что сотрудники могут менять, а что нет, где есть фиксированные рамки. Объясняйте, что именно будет принято и почему. Опишите ожидаемый результат и области, где вы ждёте изменений.
Используйте «мы» вместо «я» и оперируйте настоящим временем, чтобы подчеркнуть, что процесс изменений ещё идёт и что он — совместный.
Запрашивая фидбек, предлагайте черновик, а не законченный документ. Укажите, что документ ещё в процессе работы и что каждый может его изменить или внести предложения.
Дайте людям время на фидбек, задавайте конкретные вопросы и направляйте.
Потратьте время на вовлечение других людей в процесс изменений, чтобы добиться лучших результатов, сохранить доверие и отношения.
Вот так выглядит эффект IKEA на практике. В этом тексте подробно описаны «грабли», на которые лучше не наступать. И, конечно, best-practices по внедрению изменений.
Напоминаю, что это был адаптированный перевод статьи Джереми Брауна.
Больше интересного контента об управлении командами и процессами — в моём телеграм-канале Teamlead Good Reads
