Как обучать клиентоцентричности на практике? Проблемы и решения

Привет! Я — Роман Симуков, руководитель обучающего направления humex. Мы помогаем компаниям внедрять клиентоцентричный подход в бизнес-процессы, чтобы делать востребованные продукты.

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

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

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

Проектное обучение — стандарт хороших программ. В них 10% теории и 90% практики. Вместо множества лекций — занятия с отработкой навыков и активным вовлечением в решение актуальной для команды задачи.

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

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

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

Мы обучаем на актуальных задачах каждой отдельно взятой команды — минимум теории, максимум практики. Но когда в одной из компаний (не можем раскрывать, какой, из-за NDA) мы разработали курс по созданию продукта, на выходе получили негативную обратную связь от участников, что программа не принесла им пользы.

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

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

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

Что мы сделали, чтобы подстелить соломки?

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

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

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

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

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

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

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

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

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

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

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

Мы нашли выход — сделали две вещи:

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

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

Самое опасное — если всезнайка настраивает свою команду против модератора, который, по его мнению, учит неправильным и ненужным вещам.

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

Мы в humex используем такой шаблон анкеты:

Если столкнулись со всезнайкой по ходу обучения, наш совет — назначьте его руководителем команды. В новой роли он будет помогать сотрудникам, которые не в теме и только учатся. Он может поучаствовать в интервью, поделиться советом, как построить CJM, объяснить команде, как устроены карты эмпатии. Принцип «обучайся, пока учишь других» всегда работает.

На одной из программ обучения по методу Jobs-To-Be-Done мы не выяснили уровень понимания командой инструментов дизайн-мышления.

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

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

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

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

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

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

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

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

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

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

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

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