Последнее время нам по работе приходится сталкиваться с разработчиками. Совершенно разного масштаба, но — разработчиками.
И вот они нас спрашивают. Мы, говорят, тоже вот исследуем, глубиним, рисуем CJM, но толку мало. Заказчику наплевать на эти карты, он их на пресейле требует, а потом ему нужен продукт и побыстрее. Зачем это все тогда?
А потому и наплевать, отвечаем, что это вы придумали, что для разработки продуктов нужны исследования и CJM. И бизнес в этом убедили. Бизнес поверил, но не понял. Поэтому, когда покупает — дайте две, все их делают, мы слышали. А как в качестве результата работ принять — покажите пользу и что это за рисунки, когда будет готов софт?
Ничего не поменялось. Вашим клиентам нужен софт. Точнее, не дрель а дырки, конечно же. Но СJM – не дырка. Разве что в бюджете.
Появление всех сервис-дизайнерских инструментов в разработке — это костыли, и попытки заодно с разработкой ПО починить и весь бизнес. Ну как починить? Макияж наложить. Синяк под глазом припудрить, если уж совсем честно. Некоторые вообще используют исследования на пресейле, чтобы оправдать продажу софта. Но это энтерпрайз, им простительно. Там и чеки выше, и база ниже. На низкой базе даже простые решения работают. Но вот то, что за гигантами и малыши подтягиваются – беда.
Но если посмотреть в корень, результат правильного CX-менеджмента — не новые продукты, не карты путешествия клиента. И даже не сервисные сценарии. И даже не бизнес-процессы на бумаге. А изменения внутри компании. Реальные, согласованные изменения на разных уровнях организации: от процессов до культуры. Потому что иначе не работает, компания или меняется структурно или не меняется вообще. Так уж она устроена. И вот тут ой.
Потому что во-первых, на изменение культуры нет явного запроса, но это полбеды. Главное — почти никто из разработчиков не умеетменять культуру внутри компании заказчика. Просто нет таких компетенций. Это довольно больно понимать, потому как разработчики в последнее время стали интеллектуальной элитой, но это понимать необходимо.
Разработка цифровых продуктов — это не помогающая профессия.
На всякий случай. Помогающие профессии — это те, в которых недостаточно хорошо разбираться в предмете, требуются ещё специальные знания по методологиям оказания помощи. И этих знаний у агентств просто нет. Да и зачем бы они нужны, если основная прибыль с продаж человекочасов разработчиков?
У помогающих профессий свои инструменты и приёмы. И поэтому то, что работает в маркетинге (а CX — это, безусловно, очень сложный маркетинг), не работает в агентском бизнесе.
При всей своей внешней схожести, CJM, созданная ради планирования фич будет отличаться от CJM, cозданной ради визуализации системной структуры барьеров и смены установок руководства. Вы не заметите эту разницу, если не умеете работать с ментальными моделями. Вам просто будет казаться, что одни карты работают, а другие нет. Но дело не в картах, дело в людях, которые их создают. И в причинах, ради которых они создаются.
А если ваша компания заточена под разработку, в вас не увидят способность поддержать трансформацию Бизнеса. А потому вы всегда будете в дилемме: то ли ввязаться в сложный и непонятный для вас консалтинг, то ли побыстрее закрыть бэклог. С точки зрения бизнеса выбор очевиден. Вот только обещание уже дано, а значит исследовательские работы надо как-то закрывать. Так и получаются всякие персоны с фотками из шаттерстоков, и CJM, которые никто не понимает до конца, как использовать. Но все кивают, потому что — уплочено.