Как-то исторически сложилось, что роль менеджера проекта окутана завесой тайны, в связи с чем появилось куча мемов, что менеджер нужен только для того, чтобы передвигать таски и постоянно спрашивать, а когда будет готово то или иное. Я периодически встречаю мнение коллег из мира IT о том, что в целом они могли бы обойтись и без менеджера.
Меня, как человека, который работает 7й год в в IT, проджекта, который реализовал множество проектов для разных индустрий и на базе большого стека технологий (в основном - на стыке AR/VR/3D), и бывшего операционного директора стартапа, в котором я настраивала все процессы с нуля - это конечно огорчает.
Поэтому я решила написать статью, в которой расскажу, а чем вообще занимается “правильный” менеджер проектов, почему так важен менеджмент в IT, что может пойти не так в команде без проджекта и какими качествами он должен обладать.
Я абсолютно уверена, что менеджер проекта это незаменимый для команды человек. Именно этот специалист - лицо проекта, который отвечает за проект от начала до конца, ведет его от начальной идеи клиента до использования конечным пользователем. И несет ответственность за каждое принятое решение, и за результат, которое оно повлечет.
Для менеджера проекта продуктом выступает не сам проект – за это отвечает менеджер продукта. Продуктом для PM выступают именно процессы, по которым работает команда.
Процессы бывают двух типов: внешние и внутренние.
Процессы внутри команды – это про обуздание хаоса. Менеджер общается с клиентом, принимает его бриф, расписывает флоу и цели команды, формулирует задачи для каждого исполнителя, следит за дедлайнами, принимает правки от заказчика, доносит их до команды и сдаёт финальный продукт.
Бывает так, что менеджер попадает в проект не с начала – тогда задачей будет модернизирование процессов, улучшение тех, что не эффективны. Нужно не бояться экспериментировать: внедрять новое и собирать фидбек от команды. Тут могут помочь no-code инструменты.
Когда я вела много проектов одновременно, мы с командой придумали и разработали бота для Slack. Он проводил письменные ежедневные встречи с членами команд, собирал обратную связь, делал опросы и помогал писать апдейты. Поначалу я думала, что у нас получился универсальный инструмент, который подойдет каждому проекту и постаралась его интегрировать везде. Но через некоторое время стало понятно, что он применим не под все задачи. Важно в таком случае вовремя заменить инструмент, чтобы не было процесса ради процесса.
В коммуникации с клиентом важно показать, что он будет работать с профессионалами, у которых отлажены процессы. На старте проекта вы фиксируете сроки, договариваетесь о том, когда будут промежуточные результаты, как часто вы встречаетесь, в какое время отвечаете и что делать, если случился форс-мажор. У клиента не должно остаться никаких вопросов по проекту – всё прозрачно и четко.
Меня несколько раз выручала почта. Важно вести в ней всю переписку, присылать фоллоу-апы встреч (месседжеры в этом плане менее надежны, так как в них можно удалять сообщения). В спорных моментах можно поднять эти письма и разобрать с клиентом, с чьей стороны есть недопонимание. При этом важно: если ошибка на стороне проджект-менеджера, ее необходимо признать и сделать все, чтобы обе стороны остались в выигрыше. Это важная черта профессионала, в спорных моментах корректно отстоять свою позицию или найти решение, которое устроит всех.
Менеджер отвечает и за культуру внутри команды. Он должен знать, какие качества важны для эффективной работы и помогать развивать их. Расскажу про некоторые из них:
Стратегическое мышление: если увидел проблему, не молчишь, а говоришь о ней. Ещё лучше, если предлагаешь возможные решения. Для самого менеджера важно:
- генерировать максимум решений и выбирать наилучшее,
- думать, как избежать повторения проблемы в будущем,
- отлавливать похожие ошибки до того, как они стали проблемой для всех процессов
Умение расставлять приоритеты: всегда лучше уточнить про приоритеты у менеджера, чем взять и решить не очень важную/срочную задачу.
Ответственность в работе: чтобы каждый выходил немного за рамки “своей поляны”. Например, разработчик увидел ошибку в чужом коде и сразу поправил её. Не стал ждать, пока всё сломается или искать виноватого.
Неравнодушие и сплоченность команды: сфера IT развивается быстро, иногда бывает так, что команда не предусмотрела какие-то риски и случился форс-мажор. Если у команды всё хорошо с мотивацией и они понимают ценность и цель проекта – то останутся и проработают задачи. А менеджер останется с ними и подбодрит, поможет, закажет пиццу. Проджект должен понимать, что он – часть команды, а не начальник. Команда будет работать слаженно и чувствовать себя единым целым, только если все заодно.
Эмоциональное состояние ребят: если у кого-то в команде проблемы, что-то не нравится в проекте и задачах или он ходит непривычно грустным – задача менеджера узнать, что случилось и постараться решить проблему. Чтобы вовремя замечать такие вещи, нужны регулярные встречи с каждым. Обычно их проводят руководители.
Фидбек: менеджер должен уметь правильно получать и реагировать на обратную связь. Новичкам бывает сложно отделить себя от работы, какие-то замечания или критика могут ударить по самолюбию, поэтому важно уметь обрабатывать профессиональный фидбек, и так же профессионально его давать, не допускать токсичной коммуникации.
Менеджер отвечает не только за процессы, но и за урегулирование конфликтов. Лучший способ уладить конфликт – не допустить его. Тут помогает междисциплинарность.
Команда состоит из разных людей: дизайнеров, копирайтеров, верстальщиков, разработчиков, ML специалистов, CG-художников. У каждой профессии своя специфика постановки задач, поэтому менеджеру важно понимать понемногу в каждой дисциплине. Хорошо, если проджект погружает все команды в одно информационное пространство, чтобы они тоже знакомились со спецификой работы друг друга. Это помогает избежать недопонимания. Здесь помогают тематические общие вечера и общие апдейты.
Бывает так, что конфликт уже случился и никто не говорит об этом, но напряжение витает в воздухе и на созвонах. Тут приходится немного играть в детектива: сходить к одному, второму, спросить что случилось. Далее можно организовать общую встречу и вместе придумать решение проблемы. Но тут важно не вставать ни на чью сторону. Менеджер – независимый человек, который со стороны помогает решить проблему.
Вместо вывода
Менеджер проекта – важный винтик команды. Без него было бы сложнее жить в рамках проекта, договариваться друг с другом и с клиентом, определять приоритеты реализации, выходить из конфликтов. Менеджеру важно развиваться Т-образным подходом, то есть не только вглубь, но и в ширину: прокачивать soft и hard skills. По сути менеджер проекта – переводчик между командой и клиентом, благодаря которому решаются проблемы бизнеса, и команда может спокойно работать, не отвлекаясь от своих привычных задач.
сложно найти хороших проджектов, некоторые умеют только таски переставлять и от этого у всех разработчиков миф, что менеджеры не нужны. спасибо за материал)
знаешь, когда я работал продавцом в магазине, мне казалось что директор магазина не делает ничего, всё делаем мы - линейные сотрудники. Я стал директором и "присел", пока я был директором мне казалось что мой супервайзер ничего не делает, а только тыкает в бук и ходит курить с телефоном в руках. Я стал супервайзером и чуть не сошёл с ума. С проджектом точно так же, не всегда видно его работу и не всегда проджект выставляет что он делает, даже тот проджект кто "просто переставляет таски" на самом деле не просто их переставляет, до "переставления тасков" он проходит большой путь от брифа и переговоров и тд, до этих самых тасков) Да и уровень ответственности, как ни крути, на порядок выше, чем у линейного сотрудника.
ЗЫ: я еще не проджект, а только учусь, но мнение имею)