Как понимать менеджера проекта28.11.2018 11:32

Я регулярно сотрудничаю с людьми на стороне клиента, которых принято называть менеджерами проектов. И сам периодически играю такую роль, когда ставлю задачи подрядчикам, а потом контролирую результат.

Я многому научился у этих людей (в частности, спасибо Саше Кабаргину из AGIMA и Андрею Попову из «Базы Технологий») — и продолжаю учиться — и благодаря этому стал больше зарабатывать и участвовать в более крутых проектах.

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

Кто такой проектный менеджер

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

Несколько лет назад я поймал настоящий инсайт (озарение) благодаря своей знакомой Катерине. Я работал пиарщиком SEO-компании, а Катя была менеджером проектов в крупной промышленной фирме. Однажды им понадобились услуги продвижения сайтов и Катя сначала обратилась в нашу студию, но в итоге продвижение не заказала.

Как она потом объяснила: «У меня есть несколько направлений: BTL, организация мероприятий, более классические рекламные инструменты и еще надо сайт «причесывать». Я сказала вашим ребятам, что мне не нужны многостраничные мудрёные отчёты с позициями, мне нужен простой и понятный отчёт на страничку — что было сделано, чтобы я потом могла пересказать эти вещи уже более вышестоящему руководству, отчитываясь за потраченный бюджет. Но ваши ребята не смогли так перестроиться, к сожалению».

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

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

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

Вывод: желательно создавать такую рабочую среду, при которой внешний наблюдатель (менеджер) может за 5 минут понять:

• о чем вы договаривались

• что сделано на текущий момент

• какие дальнейшие планы

Дальше — подробнее о такой рабочей среде.

Таблички, сервисы и папки

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

И поэтому полезно уметь работать с таблицами (хотя бы с Google Docs), с канбан-системами или любыми другими сервисами, которые помогают визуализировать рабочий процесс и его последовательную логику — например, с бесплатным Trello.

Никита Михеенков из Nimax объясняет про таблички еще лучше:

Пара советов по поводу работы в таблицах/сервисах

1Говоря «полезно уметь работать с таблицами» я имел ввиду, что как минимум, стоит зарегистрироваться в Trello и похожих сервисах и посмотреть, как они работают; попробовать описать там какой-нибудь ваш рабочий или домашний процесс. То же самое касается и работы Google Docs.

Это нужно, чтобы вы не пугались, когда вас добавят в один из проектных сервисов, где у людей идет работа. А в идеале, чтобы вы сами могли после обсуждения проекта создать новую доску/таблицу в удобном обеим сторонам сервисе, подытожить там все, о чем вы с заказчиком договорились, разложить движение к цели на конкретные задачи (тикеты).

2Достаточно важный пункт — навык работы именно в проектном сервисе. Отмечать там выполненные задачи, писать комментарии, двигать тикеты по мере выполнения задачи. Регулярно бывает ситуация, когда исполнителя добавляют в Trello, а он оттуда «утекает» и все равно по старой привычке пишет тебе в мессенджер, на почту и куда угодно.

3Описание и любые комментарии (апдейты) к тикетам должны помогать «вспомнить» задачу. Представьте, что вы открываете пятый тикет десятой задачи и видите там комментарий исполнителя «исправил». Что исправил, как и почему? Еще раз: комментируя задачи, помните, что читающий их человек может страдать частичной потерей памяти :).

4Важные обновления, ссылки и файлы лучше давать не в комментариях, а прикреплять в основное описание (description) тикета. Описание всегда остается на месте, тогда как в комментариях может идти длиннющая война правок и просто легкий оффтоп.

Про папки и ярлыки

Довольно многие заказчики предпочитают, чтобы вы сразу сохраняли результат работы в их рабочем пространстве (на их Гугл-диске), писали письма с их почтового ящика и так далее. Это нужно, чтобы лишний раз не беспокоиться про авторское право. Закрыли проект? —? у заказчика остались все материалы, письма, контакты и так далее.

Поэтому файлы и письма тоже нужно сортировать, а не просто сваливать все в кучу. Заказчик может «зайти в гости» не только в конце работы. Например, ему понадобилось найти какой-то файл в вашей папке, а вы в отпуске.

Почему менеджеры иногда пишут огромные комментарии с исправлениями

У вас бывала ситуация, когда менеджер, работающий с вами, пишет правки на 2–3 абзаца, хотя, казалось бы, он может просто исправить нужное слово в тексте за пару секунд?

А вот почему:

1Когда человек работает проектным менеджером, он перенимает соответствующий тип мышления (профдеформация). Функция менеджера состоит в том, чтобы давать задачи и контролировать результат. Если он будет закапываться в каждую задачу «руками», это уже не менеджер. Потому что в одном проекте правки могут на две секунды, а в другом — растянуться на два дня.

2Если исполнители привыкают к тому, что менеджер правит за ними сам, они отвыкают думать самостоятельно. Аналогия с воспитанием детей: если мама и папа не учат ребенка убирать за собой, он никогда и не научится. Зачем что-то делать, если всегда можно положиться на взрослых?

3Ну и в идеале, конечно, это желание, чтобы исполнитель после объяснений поймал нужную волну — так менеджер хочет сэкономить свое время в дальнейшем.

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

MVP

MVP (minimum viable product, переводится как «минимально жизнеспособный продукт») — это известный формат работы стартапов и быстрого запуска бизнеса.

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

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

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

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

Советы:

1Если вы видите, что не успеваете сдать что-то качественное к сроку — не тяните, лучше предупредите заранее.

2Если получилось так, что качественного к дедлайну нет — выкатывайте то, что есть. И имейте этот материал на руках, а не просто абстрактно в голове. На основании этого сырого можно сделать хоть что-то; поставить хоть какую-то отметку, что вы, например, закрыли 30% прогресса по задаче. Тогда как ничего — это ничего.

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

3У меня лично MVP-вариант регулярно выполняет свою основную функцию — оберегать от неправильных идей. Бывает, что мы расписали и согласовали большую и важную задачу. А когда я начинаю делать по ней наброски — то практика показывает, что нужно идти в какую-то другую сторону или все можно сделать сильно проще.

Делайте план работы (но, возможно, с оговоркой)

Практически все менеджеры и вообще любые управленцы в начале сотрудничества хотят получить от подрядчика план работ. Почему:

• Банальное: это как план в архитектуре. Если строить здание без плана, оно развалится. Заказчики с техническим, финансовым, аналитическим мышлением тем более живут такими вещами.

• Успокаивающее: за этот документ уже можно как-то зацепиться, даже если обе стороны понимают, что это примерные наброски, и все потом поменяется еще 10 раз. Это как рукопожатие или как деловой обед, в общем, такая своеобразная ступенька. В обмен на такой документ уже можно дать подрядчику деньги;, а в обмен на мысли из его головы, которые на бумагу еще не перенесены — вряд ли. Мысли это не физическое, даже если на словах вы замечательно друг-другу нравитесь. Может звучать странно, но после странички даже с очень приблизительными тезисами и цифрами «что мы получим» мне регулярно выплачивали деньги, а без такой странички — нет.

• Демонстрирующее: план, как и работа с таблицами, отлично показывает мышление человека и то, как у него построена работа с процессами.

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

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

Более хаотический процесс — это работа с людьми и разными переменными. Например, написание PR-статей. В прошлый раз у вас хорошо сработала PR-статья, вы получили заказы, трафик и узнаваемость. А потом по той же схеме не сработала, что-то «не зашло». В таких сферах можно планировать работу, опираясь на предыдущий опыт, но определенная доля — это эксперименты и нестабильность.

У меня в этом году был интересный разговор с проектом, получившим инвестиции: они хотели заводить корпоративный блог и мы общались насчет того, чтобы я стал там главным редактором. Я написал большой документ с планами, мыслями и идеями, но потом предупредил, что это не «высечено в камне»; что нужно будет регулярно смотреть — что из моих гипотез подтвердилось, а что нет, и корректировать стратегию. В подтверждение я привел опыт Людмилы Сарычевой, главреда Модульбанка.

Скриншот из статьи «Как запустить корпоративное медиа с нуля» в Секрете Фирмы

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

И по этой же причине их отпугивали другие кандидаты на позицию главного редактора, которые приходили и говорили, что точно знают — какая будет отдача от блога через 3 месяца и через полгода.

Даже в однотипных проектах есть различия.

Короткий итог: адекватный заказчик любит намеченный план. Но допускает, что работу нужно будет корректировать.

Помните, в чем смысл делегирования (передачи задач)

Иногда люди удивляются: почему моя работа стоит столько-то, а Василий получает в 5 раз больше?

А дело в том, что текст, дизайн, код и другие продукты — это только одна из составляющих, за которые отдают деньги. Очень важный момент — насколько удобно вы построили процесс (я знаю, что надоел с этой фразой). Иногда за удобный процесс платят даже больше, чем за сам продукт. Все люди хотят освободить свою голову, свое время, свои нервы. За это и отдают деньги.

Сделали задачу — не сидите, пока человек про вас вспомнит и придет проверять.

Затягивается дедлайн — тоже скажите об этом.

Нужна дополнительная информация — попросите ее.

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

Скучные советы, да? Ну, а что делать. Волшебные палочки где-то в другом месте.

Как стать системным?

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

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

Поучаствуйте в каком-то проекте, где люди умеют раскладывать процесс по полочкам. Вы увидите, как это работает.

Или найдите менеджера / наставника, который будет следить за вашими процессами и контролировать вашу системность на протяжении некоторого времени. Вы привыкнете и потом сможете делать это самостоятельно. Тоже хороший способ.

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

Искренне желаю успехов.

Полный текст статьи читайте на CMS Magazine