Кому заниматься поддержкой бизнеса, а кому — развитием?
И чем отличаются эти люди.
Я в МИФе (примечание редакции: издательство «Манн, Иванов и Фербер») 4 года. В моей команде уже 21 человек, а коллеги из других отделов до сих пор не понимают, чем мы занимаемся.
— Маркетинг?
— Да, но не маркетинг книг.
— IT?
— Много, но не все наши проекты завязаны на IT.
— Аналитика? Дизайн?
— Почти всегда, но не всегда.
— Тексты?
— Нам нужны тексты, но 95% того, что делают копирайтеры МИФа — не касается нашего отдела.
— Так что вы делаете?
— Мы смотрим в цифры, ищем точки роста и создаем проекты, которые бы их закрывали.
— Ааа. Это вроде внутренней дизайн-студии?
— Нет.
— 
IT-конференция МТС True Tech Day 17 мая
Что будет:
- 5 тематических треков: Main, Development, AI/ML, Cloud, Science;
- 50 спикеров с докладами про архитектуру, облачные платформы, NLP4Code, вероятностное программирование, безопасность контейнеров и другое;
- 10 часов нетворкинга;
- Цифровые зоны и digital-интеграции;
- А ещё вечеринка со звездой.
Реклама. ПАО «МТС». ИНН 7740000076. ОГРН 1027700149124
Хакеры роста
Пару лет назад нам казалось, что мы разобрались, кто мы. Тогда стал популярным термин growth hacking, который появился еще в 2010 году. Мы думали, что это про нас.
Growth hacking — это тенденция в современном маркетинге, которая отвечает за рост (growth), расширение и продвижение компании, как правило, стартапов, за счет необычных решений и инновационных разработок (hack).
Источник: LP Generator
Тогда термин 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.
