Как мы запустили 46 команд внутренних инноваторов и чему научились

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

Перед новым годом мы выпустили восемь команд из внутренней инновационной программы в одной из компаний Big 4, а за неделю до этого закончился третий поток обучения agile-команд, scrum-мастеров и внутренних инноваторов в крупном металлургическом холдинге. Большая часть команд уже поменяли внутренние производственные процессы, либо запустили внутренние IT продукты, внешние сервисы и HR-проекты.

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

Некорректно сказать «Я запустил 46 команд». Работа всегда сопровождался сильным проектным менеджером со стороны Заказчика, с которым работаем рука об руку.

Вне зависимости от задачи, мы всегда используем agile-манифест и принципы клиентоцентричности как базу работы команд. И почти всегда мы используем scrum-ритуалы для организации командной работы, хотя в разных проектах у нас по разному распределяются роли. Так что когда я пишу «agile-команда» это касается почти всех проектов, с которыми мы работаем.

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

Почти всегда запрос идет не от конкретного проекта (нам нужно ускорить запуск на рынок вот этого конкретного продукта), а от «Нам нужно внедрить Agile» или «У нас начинается Agile-трансформация / работа с внутренними инновационными проектами» и так далее.

Почему именно Agile? Или почему Lean Startup? Или почему внутреннее предпринимательство? Мы проводим экскурс по скоупу принципов, методологий, инструментов чтобы вместе с заказчиком разобраться, что понимается под всей этой кашей терминов. Выбираются проекты, под которые будем собирать команды и учиться использовать и адаптировать набор инструментов и подходов.

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

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

Четыре этапа подготовки к запуску команд:

Вызовом мы называем любой проект, инициативу, идею или проблему, над которыми будут работать команды. Вызов может быть на производстве («Как нам ускорить процесс погрузки специфичных материалов в два раза?»), в продажах («Как нам поднять продажи через такой-то канал?»), в бекофисе («Как нам сократить время согласования кандидата или увеличить конверсию заявок от кандидатов такого-то профиля на конкретную вакансию?») и в чем угодно еще.

Вызовы обычно мы разделяем на две категории: с высоким и низким уровнем определенности. Во втором случае используются классические подходы к управлению проектами, в случае высокой неопределенности – agile-принципы, Lean Startup и Design Thinking исследования, быстрые эксперименты. Вот в этом случае мы и работаем.

Для выбора вызовов для инновационных команд у нас следующие критерии:

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

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

Обычно наша карта включает следующие блоки:

Подробное описание каждого блока карты в исходнике вот тут.

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

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

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

Чтобы не забивать шурупы молотком (см. не применять Lean Startup в формате «окропим да помолимся» — обучение ради обучения), вызовы должны соответствовать требованию «высокий уровень неопределённости» и «большое количество рисков». Во всех остальных случаях есть Бережливое производство, навыки регулярного менеджмента и иже с ними.

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

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

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

Найдите внутри сильного Заказчика

Об этом говорилось ранее. Это не HR, которому делегировали найти провайдера для обучения. Это реальный внутренний заказчик конкретного изменения: руководитель службы, директор департамента, партнер. Заранее встретьтесь, дайте ему критерии выбора проектов, описанных выше.

Только те, кто этого хочет или, по крайней мере, не против.

Обычно все привыкли команду собирать директивно: Вася, Петя, Маша – вы работаете над этим вызовом. А нужно им это, готовы ли они морально к новым подходам и экспериментам, достаточно ли они смелы и открыты к экспериментам – не понятно.

Только те, у кого есть хотя бы 20% времени на работу над проектом.

И кому это время реально готовы освободить в его основной команде (если решаемый вызов кросс-функциональный, а не функциональный). Иначе на каждой ретроспективе будете обсуждать вопрос «Как нам работать, у нас операционка и у меня только 2-3 часа в неделю на проект». Вообще я не согласен, что команда всегда должна быть full time, и об этом я напишу в конце.

Два подхода к подбору членов команды.

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

Дальше делим участников на команды, можно даже устроить искусственную конкуренцию: сделать так, что бы команды работали над одним и тем же вызовом, но с разными идеями по решениям. Например «Как мы можем увеличить продажи через такой-то клиентский сегмент и вообще возможно ли это?». И разные команды предлагают разные идеи, проводят разные эксперименты и, соответственно, получают разные результаты и данные по проведенным исследованиям и экспериментам. Как показывает практика одна-две команды из шести находят работоспособное решение.

Второй вариант (более системный) – определять ключевые задачи бизнеса (всего или конкретного департамента), собирать команду изначально по компетенциям (как это обычно и делается в проектном менеджменте). Здесь все как обычно, но есть нюанс: если допустить в команду излишне самоуверенного человека с высоким уровнем авторитета, то, скорее всего, он будет исполнять роль ZEBRA/HIPPO (Zero evidence but really arrogant / highest paid person opinion). Первое – ноль доказательств, но очень уверенный в своей правоте, а второе – мнение самого высокооплачиваемого сотрудника, которое не подвергается критике. Наличие в первых командах таких людей приведет к тому, что команда вместо проведения исследований и экспериментов будет топтаться на месте и опирать не на данные, а на интуицию и эмоции HIPPO.

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

Для меня важнее делить команды не по вызовам, а по их способностям и компетенциям в том или ином блоке вопросов. То есть портфель инструментов может отличаться от команды к команде, но основные Agile, CX, Lean Startup и CustDev принципы используются всегда и всеми командами вне зависимости от сути вызова.

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

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

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

Продуктовым навыкам, навыкам agile-коучей и трекеров нужно обучить проектных менеджеров. Важно, чтобы руководители проектов могли вовлекать каждого участникам core team в работу, помогать команде самоорганизовываться. Да, первые 2-3 месяца с ними будет трекер / agile-коуч, но наша задача сделать так, чтобы руководители могли сами развивать команды. Хотя я убежден, что это просто здоровые навыки регулярного менеджмента, но да ладно.

Когда я искал на разные проекты скрам-мастеров и трекеров (понятно, что это разные люди с разными задачами) было трудно найти людей по трем факторам:

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

Есть команды, где нашелся педантичный человек, который любит до мельчайших подробностей прописывать беклог, но вот договориться в команде об их выполнении не может. Или бывает может, но вместо того, чтобы пойти пообщаться с клиентами или хотя бы заказчиками внутри компании, они начинают пилить решение. Бывают ситуации, когда у команды вызов очень неопределенный («Мы хотим запустить продукт на владельцев котят, но что это может быть?») и тогда команде важнее использовать принципы дизайн-мышления. Но классический скрам-мастер вообще не в курсе про дизайн-мышление (или не погружен, по крайней мере), поэтому команда остается наедине со своей некомпетентностью, но зато у них есть доска в трелло =)

Поэтому вначале проекта мы не обучаем сами команды, а обучаем «каталистов» — это человек с пониманием всего описанного выше.

Я пока не придумал как называть смесь agile-коуча, трекера, продуктового ментора и scrum-мастера в одном флаконе, так что пока буду называть его «Каталистом». Задача каталистов — удерживать ритм команды, развивать дисциплину и самоорганизацию, включать каждого члена команды в обсуждения и работу, передавать инструменты из портфеля дизайн-мышления, Lean Startup, Agile и иже с ними.

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

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

Очень дорого обойдется сопровождение каждой команды в компании, в которой команды сотни. Поэтому сначала мы обучаем каталистов, но не просто как модераторов процессов и амбассадоров agile-ценностей, но и как «трекеров» и носителей методологий. Первые недели они дают обратную связь командам, помогают разбирать гайды интервью, выбрать корректную форму эксперимента, определиться с метрикаами и помогает понять, почему в этой ситуации важно что-то проверять (если это правда важно, эксперименты ради экспериментов никому не нужны).

Как проходит обучение каталистов: мы бьем программы на 4-5 модулей, между которыми каталисты объединяются в небольшие команды и пытаются прожить весь основной цикл, который в дальнейшем будут проживать их команды. Мы так же проводим первые чекины и дейли-скрамы, ретроспективы, демонстрации и помогаем наладить процесс проверки гипотез (если есть что проверять). Все это каталисты проходят в своих небольших командах на реальных и актуальных для них проектах.

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

Вся суть работы с командами внутри обучения. Для меня важно, чтобы каждая команда чувствовала, что:

а) их поддерживают даже если они делают ошибки,

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

Но у каждой команды своя ситуация: она может быть самоорганизованной, но двигаться не в том направлении, куда хотели бы двигаться клиенты. У нас есть команда, которая очень уверенно месяц пилила внутреннюю базу знаний не слушая ничьи мнения, а через месяц, показав результаты внутреннему Заказчику, напоролись на конструктивный, но очень негативный фидбек. Вот вроде сейчас позвали каталиста в помощь, ждем что там с ними получится =)

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

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

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

Но есть нюанс: люди боятся обращаться за помощью. Поэтому первое время эту помощь нужно давать практически директивно, но очень вежливо. Не раздавать прямых советов, а спрашивать. Не рассказывать как должно быть, а показывать спектр вариантов и идеи, которые команда не рассматривала, а дальше спрашивать «Что об этом думаете? Насколько это возможно? Что сделать, что бы это проверить?». Не стесняйтесь ждать, пока люди подумают и ответят на вопрос. Обязательно появится кто-то смелый, кому эта неловкая пауза надоест =) Еще можно проблематизировать: обычно люди уверены, что они нормально проводят интервью. Но стоит разобрать одно из них записанное через зум, как оказывается, что есть куда расти. Так создается спрос на поддержку каталиста.

И еще: команды должны понимать, что постоянно есть презентация результатов и помнить, что через условные 2 недели им нужно показать трекшн перед другими командами (об этом ниже в следующем блоке). Это очень сильно мотивирует.

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

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

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

И в этом году это реализовать не успел, но в следующем очень хочу сделать открытые демо-дни и клубы команд-инноваторов для обмена опытом, на которые приглашать разных спикеров делиться опытом. В конце года был полный цейтнот, а вот вначале февраля начнем =) Кто делал – пишите мне, очень хочу послушать про ваш опыт.

У нас всегда есть два уровня метрик:

Результаты команд.

В комментариях к одному из постов в FB написал один из коллег – «Запустить можно сколько угодно команд, а сколько из них выживет?». Конечно репрезентативные метрики по запущенным командам смогу показать через полгода, но мой текущий опыт показывает, что обычно из 7 команд 2-3 показывают результат в виде готового и работоспособного решения, над развитием которого компания дальше продолжает работать.

В этом году выглядит, что в среднем 6 команд из 10 продолжают работать над проектом / идеей (если в этом есть смысл и это не было разовым вызовом).

Все ли получалось? Конечно нет. В некоторых случаях команды за два месяца просто смогли нормально сформулировать сам вызов, стоящий перед компанией. Но как сказал Альберт Эйнштейн «Если бы у меня был всего один час на то, чтобы спасти мир, я провел бы 55 минут, определяя проблему, и пять минут потратил на ее решение». Так что не уверен, что это плохой результат.

Теперь просто рандомно инсайты и полезные мысли, которые не стал помещать в каждый описываемый этап.

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

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

Портфель инструментов может отличаться от команды к команде, но основные Agile и Lean Startup принципы используются всегда и всеми командами вне зависимости от сути вызова (в проектах с высоким уровнем неопределенности). Как вы могли заметить, проекты команд очень отличаются друг от друга, но тот алгоритм, который мы используем подходит (с адаптацией, конечно) под каждый из видов вызовов.

Каргокульт. Приходишь в команду, а они говорят «Мы эджайл и работаем спринтами». Просишь показать беклог. Показывают диаграмму Ганта, где слова «Проектный этап» заменены на «Спринт». Говоришь «Коллеги, извините, если прозвучу как будто я наезжаю, но я просто хочу показать некоторые риски. Это – не эджайл» =) Команда реагирует спокойно и пытается разобраться почему. Обычно потому что соблюдение ритуалов скрам не достаточно, чтобы это был настоящий эджайл, важно давать ценность к концу спринта, а вот как это сделать большинству людей либо не известно, либо они не видят в этом смысла. А если не видят смысл, то значит недостаточно понимают риски проекта (опять же, если риски есть). А если рисков нет, то зачем вам этот эджайл – не понятно.

Про «Нехватку времени». На каждой ретроспективе участники говорят «У нас не хватает времени», но при этом все равно почти все успевают. Да и вообще когда на ретро кто-то говорит «не хватает времени», то это не проблема. Надо спрашивать «А на что именно не хватает? Что не успеваешь? В чем на самом деле проблема? Ок, что ты реально можешь успевать?». Проблема не в том, что у нас абстрактная «Бюрократия», а в том, что «Служба рисков не согласовывает проект». Тогда становится понятнее что с этим делать.

Еще про время: я не верю тем, кто говорит, что настоящая agile-команда должна работать над одним проектом full time (да как и вообще не верю в крайности). Это не правда, я видел сотни кейсов, когда команда справлялась с поставленной задачей и без полной вовлеченности. Есть категория задач, касающаяся внутренних изменений и процессных инноваций, когда команда уделяет решению проблемы всего 15% времени и они получают на выходе результат (положительный или отрицательный другой вопрос, но как минимум свои идеи проверяют). Просто есть два этапа: когда мы отвечаем на вопрос «А не страдаем ли мы фигней? Действительно ли на эту идею нужно тратить деньги компании и время наших людей?», а уже на втором этапе «Как мы это будем делать?». И уже на втором этапе реально можно и нужно собрать полноценную кросс-функциональную команду на 50%их времени, а может даже и на 100%. Но зачем это делать на фазе концепта – не понятно.

80% проблем лежат в плоскости подготовки к проекту, дисциплины команды и поддержки основного стейкхолдера.

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

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

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

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

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

Благо прошлый год нас всех хорошо научил учиться и меняться.

Успехов вам.