Кому​ ​заниматься​ ​поддержкой бизнеса,​ а ​кому — развитием?

Я в МИФе (примечание редакции: издательство «Манн, Иванов и Фербер») 4 года. В моей команде уже 21 человек, а коллеги из других отделов до сих пор не понимают, чем мы занимаемся.

— Маркетинг?
— Да, но не маркетинг книг.
— IT?
— Много, но не все наши проекты завязаны на IT.
— Аналитика? Дизайн?
— Почти всегда, но не всегда.
— Тексты?
— Нам нужны тексты, но 95% того, что делают копирайтеры МИФа — не касается нашего отдела.
— Так что вы делаете?
— Мы смотрим в цифры, ищем точки роста и создаем проекты, которые бы их закрывали.
— Ааа. Это вроде внутренней дизайн-студии?
— Нет.
— 

Успейте купить корпоративный пакет COSSA-2025 со скидкой!

Cossa анонсирует главный рекламный формат на весь 2025 год: сразу 8 различных опций.

Пакет идеально подходит для онлайн-сервисов, стартапов, интернет-компаний и digital-агентств.

Успейте приобрести пакет до повышения цены!

Хакеры роста

Пару лет назад нам казалось, что мы разобрались, кто мы. Тогда стал популярным термин growth hacking, который появился еще в 2010 году. Мы думали, что это про нас.

Тогда термин growth hacking сильно колбасило — что только им не называли. Когда все более-менее устаканилось, оказалось, что в этом понятии больше копания в данных и меньше работы над проектами, чем у нас. Всё чаще стали писать, что ты не можешь называть себя гроус-хакером, если не владеешь хотя бы одним языком программирования, на котором удобно работать с данными, например Python или R. Большинство из нас не владеет.

Change-команда

Бимодальную модель придумали в 2014 году аналитики из Gartner. В 2016 о бимодальных организациях активно заговорил Греф. Он объяснил, в чём суть разделения функций run и change.

«В организации люди занимаются либо business run, либо business change. Первое — это поддержание текущего бизнеса, который даёт копеечку. Коровка должна быть ухожена, накормлена, почищена и вовремя подоена. А второе — это постоянные изменения, создание инноваций. Мы выделим две эти функции во всех подразделениях банка и решим, какие менеджеры будут их выполнять».
Герман Греф в интервью HBR.

В нашем отделе есть run-задачи. Но как только мы узнали о бимодальных организациях, поняли, что УТП нашего отдела в change, многое встало на свои места.

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

Цепочка change

Предположим команда change изобрела и запустила продукт. Ребята поставили «флажок» и делают селфи.

Амундсен, Хансен, Хассель и Вистинг перед палаткой на Южном полюсе под норвежским флагом

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

Придумал → Сделал → Настроил процесс → Вышел

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

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

В конце проекта у человека change всегда дилемма «тащить vs. бросить». Каждое из решений ужасно по-своему.

1. Тащить. Это решение плохо, потому что рано или поздно поддержка запущенных когда-то проектов начнет занимать всё ваше время. Вы не сможете заниматься тем, что у вас лучше всего получается, — придумывать и запускать новые проекты.

   

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

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

Всё ведет к тому, что правильное решение — кропотливо передать проект в правильные руки. Донести всё, что вы в проект заложили, понаблюдать, посаппортить, а потом выйти. Найти человека run, распознать, правильно мотивировать и передать задачу.

Люди run и люди change

Человеку change важно любить людей run. Хотя бы для того, чтобы всю жизнь не простоять на конвейере, который сам же и придумал. Научиться их видеть, понимать мотивацию, общаться — не так просто, потому что мы по-разном смотрим на работу.

Людям run нравится работать в настроенном процессе. По Адизесу, это люди с большим А (administrator) и маленькой P (producer). Людям change нравится создавать то, чего не было. Причем не по кайдзен, а большими шагами. По Адизесу у них все наоборот — большая P и маленькая А.

Людям свойственно мерить по себе. Поэтому люди change допускают как минимум две большие ошибки в понимании run.

1. Они считают, что у run скучные задачи. Иногда люди change стесняются нанимать людей на run-задачи. Чтобы компенсировать неудобства, они обещают «развитие» в виде change проектов или пытаются время от времени подбросить им change-задачку. От обоих видов «поощрения» мотивация человека run падает. Он попадает в слишком неопределенную для него среду.

   

   Отстаньте от людей run, им и так хорошо.

2. Люди change считают, что люди run не способны к переменам. Отчасти это правда, для них большие изменения = проблемы. На самом деле они тоже меняются, но их изменения другие. Часто они шлифуют до блеска камень, который вы им откололи. И в этом их ценность.

Команде change важно находить правильных run-людей, которые не законсервируют процессы, а будут развивать их медленно, по кайдзен.

Ошибки в change

Отношение к ошибкам в run такое: «Где мой кнут?». Это логично, потому что никакой пользы в ошибках run нет. Если ты проспал и не подоил корову, тебя надо наказать, чтобы это не повторялось.

«У каждой ошибки есть имя и фамилия».
Иосиф Сталин

В change к ошибкам важно применять другой подход.

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

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

Что не надо делать с ошибками.

1. Испытывать чувство вины.
2. Находить виновных и наказывать.
3. Чего бы то ни было ещё.

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

Итого

Мы ещё в самом начале пути change. Сейчас я готовлю пост про особенности change-проектов и change-процессов, как мы их сейчас видим.

Оригинал публикации — в блоге Натальи Бабаевой.

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