Содержание

    Менеджер в треугольнике. Как экономить человеческие ресурсы для маркетинговых задач

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

    Ольга Бурикова за годы работы продуктовым маркетологом в «МегаФоне» часто сталкивалась с такими ситуациями. Как выходить из них с готовыми проектами и спокойными нервами, она поделилась на нашем вебинаре «Докрутите». Ниже — конспект выступления.

    Менеджерский треугольник и принцип достаточности

    Как все мы знаем из школьного курса геометрии, сумма углов любого треугольника равна 180 градусам. Если один угол уменьшить, другие увеличатся — и наоборот.

    Менеджерский треугольник

    Это правило работает и в бизнесе: здесь тоже есть треугольник — менеджерский. Его вершины — качество, скорость и стоимость работы.

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

    Примеры взаимного влияния параметров объекта

    Если хотим сохранить качество и уложиться в срок, то не впишемся в бюджет

    Примеры взаимного влияния параметров объекта

    Если нужно дешёво, придётся жертвовать качеством — а если важно сохранить и скорость, то качество пострадает ещё сильнее

    Примеры взаимного влияния параметров объекта

    Если главное — любой ценой уложиться в дедлайн, то «любая цена» — это как раз качество и стоимость

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

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

    Как это работает на практике

    Покажу работу треугольника на реальном примере.

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

    Найти: выход из безвыходной ситуации.

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

    Начнём с вопросов самим себе. Зачем нужен лендинг? Чтобы было как перенаправлять трафик из рекламных объявлений в приложение и отслеживать поведение пользователей. А обязательно ли для этого использовать именно лендинг или есть другие инструменты, на которые хватит ресурсов сейчас? Есть другие — например, сториз в приложении и на сайте.

    Теперь выбираем:

    • Лендинг. Обеспечивает полную аналитику по поведению пользователей. Делается в лучшем случае за две недели — если все разработчики побросают ради него все остальные задачи. Качественно, но долго и дорого.
    • Сториз. Можно сделать за пару дней без необходимости двигать другие проекты, да и дорабатывать после запуска намного проще. Аналитика немного смазывается, но есть возможность добрать её на другом участке пользовательского пути. Быстро, дешёво, достаточно качественно.

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

    Ещё три способа сберечь себя и коллег

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

    Искать альтернативные решения

    История о лендинге учит не только принимать достаточность, но и искать альтернативу. Оптимальные идеи обычно не приходят в голову сразу. Да, можно с первого раза придумать что-то приемлемое, но если продолжить размышлять, то обнаружатся более качественные, быстрые и дешёвые аналоги.

    Посмотрите на карту коммуникаций для одной из игр:

    Пример карты коммуникаций для спецпроекта

    Здесь много каналов продвижения и, что важнее, много развилок и посадочных страниц

    Человек с приложением попадёт сразу в игру. Человек без приложения:

    • со смартфона попадёт на страницу приложения в магазине;
    • с десктопа — на лендинг сториз с рассказом об игре и QR-кодом для установки.

    Если он попытается поиграть с десктопа, то попадёт на старый лендинг о приложении с тем же кодом.

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

    В таких случаях кто-нибудь обязательно говорит: «Мы так никогда не делали, не хочется рисковать на важном проекте». И как показывает практика, суперважный проект, на котором ни в коем случае нельзя экспериментировать, — это примерно каждый первый.

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

    Вникать в работу специалистов

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

    Я убедилась в этом на практике, когда нам понадобилось обновить внутреннюю программу для отправки пушей.

    Это была задача сразу для двух IT-команд: разработчиков приложения и тех, кто занимается архитектурой коммуникаций в масштабе всей компании. Мы писали и согласовывали ТЗ целый год, но всё равно оплошали: не учли планы самих разработчиков внедрить одну маленькую фичу. Когда нашу программу наконец обновили, эта неучтённая фича (её успели добавить раньше) нарушила её работу, потребовалась большая доработка.

    Возник риск, что команда большого IT завернёт задачу по доработке. На этот раз мы посоветовались со специалистами, чтобы в ТЗ доказать важность и срочность задачи, а также описать её точно и понятно. Последнее важно, чтобы исполнитель отреагировал так, как нужно нам:

    Реакция разработчиков на новые задачи

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

    Советоваться с коллегами

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

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

    Снова история из «МегаФона». Команда, которая занимается наружкой, готовила кампанию с упоминанием приложения. Мы предложили добавить QR-код: прохожий сможет легко установить приложение, если реклама его вдохновит. Это оказалось несложно. За 15 минут разговора мы нашли способ поднять эффективность рекламной кампании и, соответственно, лучше распределить трудовые ресурсы на её создание.

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

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

    Как быстро погрузить новичка в работу?
    Делимся своими шаблонами оффера и велком-тренинга
    Имя
    Email *
    Array
    (
        [0] => WP_Term Object
            (
                [term_id] => 1425
                [name] => Статьи
                [slug] => articles
                [term_group] => 0
                [term_taxonomy_id] => 1907
                [taxonomy] => category
                [description] => 
                [parent] => 0
                [count] => 663
                [filter] => raw
                [cat_ID] => 1425
                [category_count] => 663
                [category_description] => 
                [cat_name] => Статьи
                [category_nicename] => articles
                [category_parent] => 0
            )
    
    )
    
    Поделиться статьёй
    Подписаться на рассылку