На этих выходных посмотрела интервью Лены Герасимовой для Вики Молдавской.

Я знаю Лену лично, Лена предприниматель, создатель магазина и бренда Skin Probiotic, профессионал с сильным маркетинговым бэкграундом.

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

Когда-то давно я, будучи стажером в PR Яндекс Маркета, занималась отбором блогеров для бартерных коллабораций и договаривалась с ними о публикациях. Процесса у нас не было, и на то, чтобы вышел пост у одного блогера, уходило очень много сил, времени, нервов и эмоций. У нас не получилось построить процесс, и поэтому ROI от инфлюенс-маркетинга был очень низкий.

У ребят из Skin Probiotic это получилось, и что им это даёт?

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

Как только вы убираете субъективное, экспертное принятие решений из процесса, процесс становится лёгким и доступным, и ROI от него начинают расти. Это и получилось сделать у ребят. А применять этот хак можно не только в маркетинге, а в любой сфере;)

Друзья, сегодня в моём канале невиданная акция — "приведи друга"! Условия акции в прикреплённом видео.

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

Если не хотите, можете никого не подписывать и никому ничего не пересылать. У нас с вами здесь всё добровольно.

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

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

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

Чтобы этого избежать, я сажусь и выписываю все-все ограничения, которые неявно, но есть в проекте. Примеры:
• Я хочу получить высокую оценку на следующем ревью, проект надо сделать так, чтобы его можно было продать на эту оценку, значит, он должен привносить масштабнеы изменения, а не подорожники;
• Я хочу ходить на вокал и танцы, мне нужно загрузить себя так, чтобы освобождаться не позже 18 часов каждый день;
• Я хочу в будущем претендовать на руководящую позицию, значит, проект надо реализовать так, чтобы я в процессе кем-то руководила;
• Для того, чтобы в будущем получить высокую оценку или повышение, мне нужно будет иметь хорошие отношения с руководителем смежной команды — значит, проект должен помогать ему выполнить его цели тоже, а не противоречить им;
• Я хочу в будущем перейти на другую работу с более высокой зп, значит, в этом проекте должны быть вещи, которые я смогу положить себе в портфолио и за счёт них хорошо себя продать. В примерах вакансий, которые мне нравится, есть опыт, которого мне не хватает: ведение диаграмм Ганта, внедрение изменений в текущие операционные процессы и т.д.

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

Вот есть, будем называть его, “data-driven” подход к работе в корпорациях — принимаем решения на основе объективных данных, регулярно задаём себе вопрос “зачем мы это делаем” и пьём смузи всегда оцениваем цифрами результаты наших запусков.

Звучит классно, но я пока не видела, чтобы этот подход нормально применялся. Как обычно это выглядит:
1. Аналитиков слишком мало, у них плотный бэклог, в который хрен встанешь. В какой-то момент капасити аналитики схлопывается до микроразмера, потому что они сначала нахерачили кучу инструментов, а теперь их надо обновлять и чинить, и весь ресурс уходит на это.
2. Решения о запусках принимаются в результате пихания пузом, для убедительности показываются какие-то цифры, вырванные из контекста (очень напоминает мне защиту дипломов в универе). Либо находится человек, который так хорошо понимает взаимосвязь метрик, что может на коленке прикидывать эффекты и в 95% случаев попадает. На прошлом месте работы, например, я была именно таким человеком.
3. Если что-то при запуске пошло не так, то всегда можно доебаться до ответственного из п2., потому что при проработке запуска что-то не просчитали. Генерируем лишние стрессы в команде.

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

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

Мои дорогие уже 14 (между прочим!!) читателей, видели ли вы успешные кейсы, когда в компании была так построена работа аналитики, что её хватало на тру дата-драйвен запуски? Как это было выстроено? Хочу узнать такой опыт, как это построить?

Дорогие соискатели, будьте осторожны с формулировками…

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

Как вам такой формат? Текст всё-таки привычнее, или будем разбавлять его кружочками и голосовыми?)

Привет! У меня есть свой бэклог тем, про которые я хочу здесь поговорить, но вдруг есть что-то, что вам было бы интереснее всего)
Напишите, пожалуйста, в комментарии, о чём сделать пост/подкаст❤️

Уважаемые читатели прислали в редакцию нашего канала такой вопрос:

Насущное: руководство генерит фичи без привязки к метрикам и смыслам. Пипец как жалко тратить ресурс разработки на это. Как жить в такой ситуации?…

Заставить компанию сделать стратегию, спустить её сверху вниз и идти по ней можно, только если вы СЕО или имеете на него прямой и простой выход. Простите, если кого расстроила, можем поспорить в комментариях:) Если доступа к телу нет, то огораживаем свою поляну и держим порядок хотя бы на ней.

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

У меня есть похожий, достаточно холиварный, рабочий проект, в который кто-то всё время пытается вкинуть что-то новое, от фичи до контента, а ещё по дороге поменять требования. Это происходит и со стороны топов aka заказчиков, и со стороны смежников и других стейкхолдеров. В этой ситуации лучше, что можно сделать — уволиться определить основных принимающих решение, зафиксировать с ними требования, потом зафиксировать это письменно, и отправлять в этот документ всех, кто пытается накинуть что-то новое. “Да, это хорошая идея, я согласна. У нас уже есть зафиксированный список требований — вот он. Если ты хочешь внести в него изменения, то давай соберём встречу в том же составе, который указан согласующих у этих договорённостях”. Спойлер: до встречи дойдёт примерно в 1% случаев:)

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

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

Джентельменский набор проджекта

Я сейчас консультирую в Эйч, и очень часто ко мне приходят ребята с вопросом: "Какую теорию должен знать менеджер проектов?". По моему мнению, любая практика тут будет лучше теории, но всё равно можно составить какой-то список, с которым кандидат на вакансию проджекта должен быть хорошо знаком. Вот такой список даю я. А что бы вы добавили в него?

1. Диаграмма Ганта
2. Стадии проекта
3. Стандарт PMBOK (он на самом деле в чистом виде нигде не используется, но его понимание помогает уложить в голове, что такое управление проектами)
4. Карта рисков, митигация рисков
5. Типы стейкхолдеров, матрица RACI
6. Нотации описания процессов (блок-схемы, BPMN)
7. Метрики успешности проекта
8. Ретро по проекту
9. Трекеры задач (jira, asana, Яндекс трекер и т.д.)
10. SQL (понять для себя логику, мне нравится этот тренажер https://sql-academy.org/ru/guide)

На этой неделе была на тусовке менторов getmentor.dev.

Кстати, ссылка на мой профиль, всегда рада, если рекомендуете:)

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

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

Не скажу даже, что это только новому поколению интересно, но не суть.

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