Продуктивный Роман #127
9 правил эффективного проектного менеджмента
Мы в агентстве performance-маркетинга Roman.ua поработали более чем c 250 клиентами.
Как результат, выработали 9 правил проектного менеджмента, которые будут полезны абсолютно всем, кто делает проекты в интернет-маркетинге или разработке.
Подпишись и слушай подкаст
«Продуктивный Роман»
Тайм-коды
00:00:00 — Вступление
00:00:22 — 9 правил проектного менеджмента в Roman.ua
00:00:51 — Правило #1. Используем каналы коммуникации под задачи
00:01:26 — Крутой сервис маркетинг-автоматизации
00:02:12 — Еще про эффективное использование каналов коммуникаций
00:06:50 — Правило #2. Называем файлы так, чтобы их легко было найти
00:09:00 — Правило #3. Уменьшаем человеческий фактор и вероятность ошибок
00:10:18 — Правило #4. Храним данные безопасно
00:12:17 — Правило #5. Держим команду в тонусе за счет регулярного менеджмента
00:14:06 — Правило #6. Следим за динамикой ключевых показателей и влияем на нее
00:15:07 — Правило #7. Проводим ретроспективу с Клиентом и определяем планы на будущее
00:15:49 — Правило #8. Оставляем самое важное для живого или онлайн общения
00:16:56 — Правило # 9. Делаем больше, чем просто рекламу
Конкурс
О спонсоре
Переходи по ссылке 👉 https://sendpulse.ua/ru и строй маркетинговую коммуникацию с пользователями в правильных каналах.
Расшифровка подкаста

Привет. Это спецвыпуск подкаста «ПРОДУКТИВНЫЙ РОМАН». И сегодня мы поговорим о том, как правильно и с удовольствием вести проекты в диджитал в целом и в интернет-рекламе в частности. Мы в агентстве performance-маркетинга Roman.ua завели и сделали более 200 проектов в нашей системе постановки задач и поработали в итоге более чем c 250 клиентами. Почему клиентов больше, чем проектов? Некоторых мы консультировали и не заводили проект в системе под разовый консалтинг.
Как результат, мы выработали 9 правил проектного менеджмента, которые будут полезны абсолютно всем, кто делает проекты в интернет-маркетинге или разработке. Поехали.
Правило #1. Используем каналы коммуникации под задачи
Первое: используем каналы коммуникации под задачи. Мы используем чаты для оперативного общения; Worksection — для постановки и отслеживания прогресса по задачам; email-переписку — для фиксирования ключевых моментов, договоренностей, отчетов — то, что должно остаться навсегда у обоих сторон и что нельзя изменить, удалить, исказить; файлы в Google Docs и Google Spreadsheets с комментариями — для постановки технических заданий, обсуждений и совместной работы над какими-то документами.
О спонсоре
Современные потребители требуют современных инструментов коммуникации. Они все чаще держат в руках мобильный телефон: в очереди, в лифте, за завтраком. И даже на совещаниях. Наши маркетинговые сообщения они тоже читают с телефона. Не только в почте, поэтому сервисы емейл-маркетинга тоже эволюционируют, чтобы быть там, где их потребитель.
Хочу посоветовать тебе сервис маркетинг автоматизации SendPulse, который позволяет работать с потребителем во множестве каналов:
- sms
- push
- чат-боты в соцсетях и мессенджерах
Ребята постоянно улучшают функционал, чтобы ты мог получить максимум от своей базы клиентов. Регистрируйся в SendPulse по ссылке в описании к выпуску и сделай свой маркетинг по-настоящему многоканальным.
Будь там, где твой потребитель.
В какой системе вести задачи
Я против проектного менеджмента в чатах. Очень многие пытаются в чате вести проект, это нереально, потому что чат — это лента. Единственный чат, где более-менее можно структурировано общаться не в формате ленты, — оно утекло вверх, непонятно кто на что отвечает, люди используют reply, не используют, тегируют людей, не тегируют, — это Slack с их функционалом Thread или веток обсуждения, но и то, чат — это не очень подходящий инструмент для того, чтобы вести сложные проекты, где есть ответственные, где есть задачи, подзадачи, сроки, дедлайны и обсуждения в рамках конкретной задачи.

Для правильного ведения проекта нужна система, где можно завести задачи, подзадачи, повторяющиеся задачи. Мы активно используем для регулярных оптимизаций, для регулярных отчетов повторяющиеся задачи, — которые не дают человеку что-то не делать, — дедлайны, — для того, чтобы мы понимали, какие задачи друг с другом связаны, что мы ждем от кого и где дедлайн уже прошел и надо там пинговать человека, чтобы в итоге проект двигался к своему завершению или к промежуточным этапам.
Также в системе постановки задач мы выделяем, что заблокировано или какая задача висит на клиенте, что он должен сделать.
Иногда мы используем приоритеты по задачам для того, чтобы поднимать их выше, ниже, но не прям очень активно, и используем хабовые задачи — это задача, где в описании указаны полезные ссылки, которые могут пригодиться. Например, хабовая задача — реклама в Google, да, и там ссылки на отчеты по рекламе в Google, ссылки на баннера для рекламы Google, там ссылки на какие-то дополнительные материалы, которые нужны именно для настройки рекламы Google, например, правило пометки ссылок. И соответственно хабовые задачи мы используем для того, чтобы разделить все задачи по проекту на большие блоки и понять, какие блоки как быстро движутся, сколько времени занимают, сколько процентов проекта уходит на те или иные блоки задач.
Ключевые точки, договоренности по проекту всегда надо дублировать на имейл. Комментарии в системе постановки задач, чат в Telegram можно удалить, имейл останется и у отправителя, и у получателя, и если у вас будет какая-то спорная ситуация, то вы поднимите этот имейл и посмотрите, кто что написал, когда это было написано и кто на это ответил: «Ок, делаем», например.
Если мы говорим про файлы Google Docs, Google Spreadsheets, которые мы используем для постановки технических заданий дизайнерам, программистам, то мы активно используем функционал комментариев, где можно выделить ячейку или текст и написать комментарий. В комментарии можно тегнуть или упомянуть другого человека.

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

Таким образом, если понятийно вы согласны с теми правками, которые внесли, например, в договор, то остается одной из сторон принять все эти правки, отправить договор на распечатку и подписать его.
Еще, если ты используешь программу для скриншотов, которая заливает скриншот по какому-то адресу, то я советую в большинстве случаев скриншот вставлять сразу внутрь документа. Так быстрее документ прочитать, а не надо делать 10 кликов и понимать, какой скриншот относился к какому абзацу текста.
Если глобально резюмировать этот пункт, то мы стараемся строить правильные инфопотоки и не рвать их. Что такое порвать инфопоток? Например, ты написал человеку в имейл, а он тебе ответил в чат, и потом свести это все воедино, поднять хронологию, понять последовательность действий и погрузиться в контекст крайне сложно. Поэтому, если выбирать правильные инструменты для правильного вида коммуникации и поддерживать это, т.е. что если ты написал клиенту комментарий в Worksection, он ответил там же в Worksection, то потом с этим работать проще и проекты такие идут к финишу на порядок быстрее.
Правило #2. Называем файлы так, чтобы их легко было найти
Мы прописываем названия документов, папок, чатов по стандартам. Это часть единого инфополя. Любой участник проекта может легко найти нужный документ, к которому у него есть доступ. Все знают, где этот документ искать. Это уменьшает затраты времени. Это позволяет людям всем быть в одинаковом информационном поле или пространстве и принимать решения на основе одинакового взгляда на вещи, одинаковых цифр под капотом, одинаковых фактов.

Кстати, мы очень любим использовать Google Docs для того же утверждения договоров, потому что не надо потом искать договор «финальный после правок», «теперь точно финальный», «номер 2». В Google Docs есть история изменений и плюс все смотрят на один и тот же документ, знают, как его искать, где он лежит, в какой папке, и он отражает последнее состояние, например, правок по договору.
Вообще с договорами у меня отдельная нелюбовь. Я буквально с первых же дней основания агентства попросил юриста. Мы подготовили договор-оферту для того, чтобы каждый раз не подписывать, не утверждать, не править с каждым из клиентов свою версию договора. Мы просто составили один раз договор-оферту, потом время от времени ее обновляли, и по сути, там, оплачивая счет, клиент соглашается с условиями этого договора и мы не тратим кучу времени на утрясение условий.
А еще я верю, что небрежность в оформлении документов распространяется на небрежность в содержание этих документов и мыслях автора. Поэтому мы всегда проверяем все документы, которые мы отдаем, на опечатки, правильно их форматируем, выделяем главное, создаем автособираемое оглавление из заголовков и стараемся, чтобы наши документы отражали тот же уровень мышления, который мы заложили в их основу. То есть, если ты думаешь структурировано, у тебя будут структурированные документы, если ты думаешь структурировано, но ты готовишь неструктурированные документы, то, скорее всего, либо ты обманываешь себя и думаешь неструктурированно, либо ты просто небрежен и тогда эта небрежность может проявляться и в других местах в работе.
Правило #3. Уменьшаем человеческий фактор и вероятность ошибок
Для того чтобы уменьшить влияние человеческого фактора и чтобы люди реже ошибались, мы используем чеклисты в системе постановки задач, где ты ставишь галочку, галочку, галочку, это сделал, это сделал, это проверил. Мы используем шаблоны проектов на русском языке, на английском языке, и при запуске проекта копируем задачи, подзадачи, регулярные задачи для того, чтобы даже руководитель проекта не думал, там, «А вот в этом проекте вот эту штуку надо или не надо?». У него уже есть шаблон проекта, где заведено больше 100 задач, ему остается его скопировать в новый проект и убрать лишнее.

А еще мы вовсю используем внутреннюю базу знаний, которая построена на Google Сайтах, где хранятся инструкции о том, как делать те или иные действия, где хранятся, например, скрипты для Google Ads, и это прям очень развернутый сайт, который доступен внутри компании и не доступен клиентам, где есть наши ноу-хау и наши стандарты, и регламенты работы. Там даже есть пароль от Wi-Fi или как часто поливать цветы в офисе.
Здесь в подкасте выходит множество полезных выпусков о продуктивности, об IT-бизнесе, об интернет-маркетинге. Поэтому, если ты еще не подписан, подпишись, чтобы не пропустить новые выпуски.
Подпишись и слушай подкаст
«Продуктивный Роман»
Правило #4. Храним данные безопасно
Мы используем сложные пароли и двухфакторную аутентификацию. Сложный пароль в моем понимании — это 10-12-16 символов с большими и маленькими буквами. В большинстве случаев сотрудник даже не знает пароль от того или иного сервиса. Мы выдаем доступы без сообщения конкретно пароля через Zoho Vault — это специальный сервис, который позволяет тебе расшарить пароль, только человеку он не отображается, а расширение в браузере, например, в Google Chrome, заполняет на конкретном сайте логин, пароль, и пользователя пускает авторизоваться на этом сайте.
Мы вовсю, где только можно, используем двухфакторную аутентификацию. Что такое двухфакторная аутентификация? Ты ставишь на телефон, например, приложение Google Authenticator и после того как ты авторизуешься в некоторых сервисах каждый раз, в некоторых сервисах раз в 30 дней или с нового устройства, они после логина, пароля спрашивают у тебя одноразовый пароль. Этот одноразовый пароль привязан ко времени. Ты должен его в течение 2 минут ввести. И на телефоне он постоянно обновляется каждые 2 минуты. И соответственно это проверка, что ты не просто знаешь логин, пароль от какого-то сервиса, но у тебя есть с собой еще конкретное устройство, которое генерирует одноразовый пароль. Это используют банки вовсю, One-Time Passwords или OTP-пароли, и это используем во всех сервисах, где только можно, мы, потому что это очень сильно защищает от взлома аккаунтов.

Если тебе неудобно пользоваться мобильным приложением, то вот эти одноразовые пароли могут приходить в виде, например, смски.
А еще по максимуму мы стараемся выдавать доступы на рабочую почту, приглашать на рабочую почту. И в случае, если мы прекращаем сотрудничество с тем или иным человеком, у нас есть отдельный вообще чеклист, как мы гасим все доступы. Во многих компаниях я видел, когда ты прекращаешь с ними сотрудничество, спустя полгода, год, иногда и 5 лет, у тебя остаются какие-то доступы. Даже у компаний, которые считают, что они относятся серьезно к безопасности. Вот мы не считаем, что мы относимся серьезно к безопасности. Мы действительно серьезно к ней относимся.
Правило #5. Держим команду в тонусе за счет регулярного менеджмента
Мы контролируем исполнителей и руководителей проекта с помощью ежедневных и еженедельных встреч и совещаний.
Первый вид встреч, который происходит каждое утро в 10:00 в будни — это Daily Scrum Meetings. Они занимают буквально там 15-20 минут, где каждый член команды говорит, что он сделал за вчера, что он планирует сделать на сегодня и какие сложности в процессе у него возникают. Таким образом вся команда синхронизируется, руководители проектов могут скорректировать, расставить приоритеты, и люди должны постоянно давать некие результаты, двигать компании наших клиентов, рекламные кампании и компании как бизнесы нашего клиента вперед, потому что на следующий день тебя спросят, что ты сделал за вчера.
По сути мы строим системы, где люди не могут не делать то, что они должны делать.
И это одна из важных вещей, которая позволяет нам показывать рост клиенту год к году, квартал к кварталу и положительную динамику.
Второй вид встреч, с которыми мы регулярно работаем, это Weekly Account Meeting. Мы встречаемся с руководителями проектов каждую неделю, я и Оля, и обсуждаем динамику по их проектам, какие есть сложности, что зависло на клиенте, какая у нас долгосрочная динамика, что еще мы можем делать для того, чтобы клиент рос быстрее, развивался быстрее, и мы вместе с ним получали лучше результаты.

Это такая иногда стратегическая сессия с руководителями проектов, где я, исходя из своего опыта, или Оля со своего, накидываю, что еще мы можем сделать, а иногда очень оперативные и тактические моменты, когда мы рассматриваем конкретный скрипт, конкретную сложность, например, в доставляемости писем или конкретное письмо, которое позволяет задать проекту совсем другую скорость и чтобы он мчался на полных парах дальше.
Правило #6. Следим за динамикой ключевых показателей и влияем на нее
Мы проводим регулярные оптимизации и срезы для мониторинга ситуации по проекту. Мы вовсю используем Google Data Studio и настраиваем клиенту автоматически обновляемую отчетность, как в целом по его маркетингу, так и по конкретным направлениям, например, контекстная реклама или email-маркетинг.

И благодаря тому, что мы смотрим на одни и те же цифры, и мы, и клиент, и эти цифры влияют на его бизнес, — это возврат инвестиций, чистая прибыль, стоимость транзакций, стоимость заявки, — и промежуточные цифры, которые приводят к вот этим вот бизнес-показателям, мы можем отслеживать динамику, понимать, что мы растем месяц к месяцу, год к году, квартал к кварталу, сравнивать периоды между собой и замечать какие-то проседания, и вносить коррективы, чтобы эти проседания скомпенсировать или обсудить их с клиентом, если они касаются его части работы, например, заведение ассортимента, ценовой политики, акции и так далее.
Правило #7. Проводим ретроспективу с Клиентом и определяем планы на будущее
Естественно, мы практикуем ежемесячные отчеты. Это отчеты, которые мы чаще всего обсуждаем на встречах или в онлайне вместе с клиентом и которые содержат все ключевые показатели, все зависшие задачи, все задачи на клиенте, все сложности по проекту, которые нужно обсудить чаще всего голосом. Они содержат также наши планы на следующий период и учет того, что мы успели сделать в прошлом периоде или что перенеслось, а если перенеслось, то по каким причинам.
В отчетах Google Docs мы анализируем результаты за месяц, специалисты прописывают свои комментарии к цифрам. В Google Data Studio сводим финансовые показатели, которые влияют на деньги в кассе у конкретного клиента.
И тут мы плавно подходим к следующему пункту.
Правило #8. Оставляем самое важное для живого или онлайн общения
На регулярных встречах с клиентами, — это раз в 2 недели, раз в месяц, — мы обсуждаем вопросы тактики, стратегии и конкретные финансовые показатели их проекта. На встречи или созвоны с клиентом мы берем с собой конкретных исполнителей. Почему? Потому что так, во-первых, информация происходит без искажений, во-вторых, руководитель проекта может потом проговорить, какая у клиента была мотивация, что они одинаково клиента услышали, что они одинаково его поняли, и клиент тоже получает информацию без искажений, если это какой-то узкий момент, который конкретный специалист настраивал, и он лучше может объяснить, чем руководитель проекта, который смотрит больше на результаты и в целом, чтобы проект двигался в правильную сторону, а не сам там руками настраивает какой-то микромомент.
На таких встречах мы очень много смотрим на цифры в Google Data Studio, обсуждаем блокеры, если они на нашей стороне или на стороне клиента, зависшие задачи, обсуждаем планы клиентов, в целом по бизнесу, конкретно по его сайту, по рекламе, по email-рассылкам.
Правило # 9. Делаем больше, чем просто рекламу
Для сложных и больших проектов мы проводим стратегические сессии раз в полгода, в год, где оцениваем соответствующий период в ретроспективе, обсуждаем, что еще может делать клиент, не обязательно даже в наших зонах ответственности, для того, чтобы расти быстрее, расти кратно и получать совсем другие результаты. Это чаще всего встречи, которые включают в себя в том числе брейншторм, где мы накидываем, что еще можно сделать, и обсуждаем с клиентом, как им можно поменять бизнес-модель, какой ассортимент есть смысл добавить, на что есть спрос, какие услуги добавить, что сработало хорошо на других рынках, в других нишах, куда долгосрочно движется рынок и как к этому приготовиться, чтобы оставаться в рынке, быть конкурентоспособным и сохранять темпы роста.
У меня есть идея распечатать эти наши девять правил как инфографику и сделать постер. Поэтому если ты хочешь получить такой постер с нашими правилами проектного менеджмента, повесить где-то у себя над столом или в компании, напиши в комментариях на YouTube «Хочу получить эти правила», «Хочу постер», и среди всех комментаторов мы разыграем, я еще не решил, сколько постеров, это будет зависеть от ваших комментариев.

Ну и я буду тебе очень благодарен, если ты поставишь лайк на YouTube, подпишешься на канал, если еще не подписан, и будешь следить за новыми выпусками. До новых встреч. Пока, пока.
И если тебе понравился этот выпуск, зайди на YouTube, поставь лайк, подпишись в том подкаст-терминале, где ты слушаешь подкаст, на наш подкаст, если еще вдруг не подписан. Если ты слушаешь нас через Apple Подкасты, обязательно ставь 5 баллов. Это очень помогает нашему подкасту ранжироваться выше. И до новых встреч. Пока, пока.