Привет, Хабр! Меня зовут Егор Толстой, я — ведущий подкаста 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
