Я в МИФе (примечание редакции: издательство «Манн, Иванов и Фербер») 4 года. В моей команде уже 21 человек, а коллеги из других отделов до сих пор не понимают, чем мы занимаемся.
— Маркетинг?
— IT?
— Аналитика? Дизайн?
— Тексты?
— Так что вы делаете?
— Ааа. Это вроде внутренней дизайн-студии?
—
Хакеры роста
Пару лет назад нам казалось, что мы разобрались, кто мы. Тогда стал популярным термин growth hacking, который появился еще в 2010 году. Мы думали, что это про нас.
Growth hacking — это тенденция в современном маркетинге, которая отвечает за рост (growth), расширение и продвижение компании, как правило, стартапов, за счет необычных решений и инновационных разработок (hack).
Источник: LP Generator
Продвижение медцентров и клиник: три кейса о SEO, TikTok и Instagram*
Как получить измеримые результаты в фарммаркетинге.
Показываем на примерах →
Спецпроект
Тогда термин growth hackingсильно колбасило — что только им не называли. Когда все более-менее устаканилось, оказалось, что в этом понятии больше копания в данных и меньше работы над проектами, чем у нас. Всё чаще стали писать, что ты не можешь называть себя гроус-хакером, если не владеешь хотя бы одним языком программирования, на котором удобно работать с данными, например Python или R. Большинство из нас не владеет.
Change-команда
Бимодальную модель придумали в 2014 году аналитики из Gartner. В 2016 о бимодальных организациях активно заговорил Греф. Он объяснил, в чём суть разделения функций run и change.
«В организации люди занимаются либо business run, либо business change. Первое — это поддержание текущего бизнеса, который даёт копеечку. Коровка должна быть ухожена, накормлена, почищена и вовремя подоена. А второе — это постоянные изменения, создание инноваций. Мы выделим две эти функции во всех подразделениях банка и решим, какие менеджеры будут их выполнять».
Герман Греф в интервью HBR.
В нашем отделе есть run-задачи. Но как только мы узнали о бимодальных организациях, поняли, что УТП нашего отдела в change, многое встало на свои места.
В этом посте мои наблюдения о том, как это работает, и выводы, которые удалось сделать за это время.
Цепочка change
Предположим команда change изобрела и запустила продукт. Ребята поставили «флажок» и делают селфи.
Амундсен, Хансен, Хассель и Вистинг перед палаткой на Южном полюсе под норвежским флагом
Плохая новость в том, что, запустив проект, мы проделали только половину работы. Чтобы change был эффективным, важно каждый проект довести до конца цепочки.
Придумал → Сделал → Настроил процесс → Вышел
Вокруг нового продукта важно настроить процессы и вписать его в работу команды run. Например, вы запустили новый сайт, молодцы. Но важно сделать так, чтобы предложения на нём обновлялись, фотки заливались по гайдам, на телефоны отвечали и так далее. Только тогда вы работали не зря.
Флаг поставлен — задача закрыта, но чтобы кто-то об этом узнал, надо еще добраться до дома. Оскар Вистинг из экспедиции Амундсена с собачьей упряжкой
В конце проекта у человека change всегда дилемма «тащить vs. бросить». Каждое из решений ужасно по-своему.
- Тащить. Это решение плохо, потому что рано или поздно поддержка запущенных когда-то проектов начнет занимать всё ваше время. Вы не сможете заниматься тем, что у вас лучше всего получается, — придумывать и запускать новые проекты.
Так чувствует себя человек change, когда ему нужно поддерживать собственный проект после запуска.
- Бросить. Это решение невыгодно для бизнеса — самые большие деньги зарыты в масштабировании и развитии. К тому же, если вы запустили необычный проект и просто бросите его, он умрёт. Никто, кроме вас, не знает, что с ним делать.
Всё ведет к тому, что правильное решение — кропотливо передать проект в правильные руки. Донести всё, что вы в проект заложили, понаблюдать, посаппортить, а потом выйти. Найти человека run, распознать, правильно мотивировать и передать задачу.
Люди run и люди change
Человеку change важно любить людей run. Хотя бы для того, чтобы всю жизнь не простоять на конвейере, который сам же и придумал. Научиться их видеть, понимать мотивацию, общаться — не так просто, потому что мы по-разном смотрим на работу.
Людям run нравится работать в настроенном процессе. По Адизесу, это люди с большим А (administrator) и маленькой P (producer). Людям change нравится создавать то, чего не было. Причем не по кайдзен, а большими шагами. По Адизесу у них все наоборот — большая P и маленькая А.
Людям свойственно мерить по себе. Поэтому люди change допускают как минимум две большие ошибки в понимании run.
- Они считают, что у run скучные задачи. Иногда люди change стесняются нанимать людей на run-задачи. Чтобы компенсировать неудобства, они обещают «развитие» в виде change проектов или пытаются время от времени подбросить им change-задачку. От обоих видов «поощрения» мотивация человека run падает. Он попадает в слишком неопределенную для него среду.
Отстаньте от людей run, им и так хорошо.
- Люди change считают, что люди run не способны к переменам. Отчасти это правда, для них большие изменения = проблемы. На самом деле они тоже меняются, но их изменения другие. Часто они шлифуют до блеска камень, который вы им откололи. И в этом их ценность.
Команде change важно находить правильных run-людей, которые не законсервируют процессы, а будут развивать их медленно, по кайдзен.
Ошибки в change
Отношение к ошибкам в run такое: «Где мой кнут?». Это логично, потому что никакой пользы в ошибках run нет. Если ты проспал и не подоил корову, тебя надо наказать, чтобы это не повторялось.
«У каждой ошибки есть имя и фамилия».
Иосиф Сталин
В change к ошибкам важно применять другой подход.
У вас есть портфель проектов. В нём важно соблюдать баланс — часть инвестиций должны быть низкорисковые и низкодоходные, а часть —высокорисковые и высокодоходные. Только тогда будет оптимальный доход по всему портфелю. Слишком низкий процент неудачных проектов скажет о том, то вы недостаточно смело экспериментируете.
В change никто не может подстелить соломки. Потому что никто не знает, как правильно. В change-проектах реакция на ошибки должна быть другой.
Видишь ошибку — сделай две вещи.
- Исправь. Срочно минимизируй негативные последствия.
- Выучи урок. Например, перестрой процесс так, чтобы в следующей подобной ситуации ее не повторять.
Что не надо делать с ошибками.
- Испытывать чувство вины.
- Находить виновных и наказывать.
- Чего бы то ни было ещё.
Когда в change неправильное отношение к ошибкам, команда осторожничает и шагает слишком мелкими шагами. Это уже не change. Настоящий смелый change выгоден бизнесу, потому что способен обеспечить рывки.
Итого
Мы ещё в самом начале пути change. Сейчас я готовлю пост про особенности change-проектов и change-процессов, как мы их сейчас видим.
Оригинал публикации — в блоге Натальи Бабаевой.
Мнение редакции может не совпадать с мнением автора. Если у вас есть, что дополнить — будем рады вашим комментариям. Если вы хотите написать статью с вашей точкой зрения — прочитайте правила публикации на Cossa.
Источник:
