«Здравствуйте, я – IT Project Manager» как каминг-аут

Всем привет! На связи Берёзкин Александр и я хочу вести блог на тему Project Manager в IT. Я пытался посерчить блоги и статьи, посвященные проектному менеджменту в IT, но к сожалению столкнулся с непробиваемой стеной — они попросту отсутствуют.

К примеру:

• Вы можете встретить топ 10, 20, 30, 100 каналов, сайтов, посвященных разной степени свежести курсов на PM или же роликов/статей;
• Описание роли и работы PM в посте компании, описывающей успешный кейс внедрения ПО для разбора, где про труд PM будет сказана пара слов;
• Рекламные посты от компаний по онлайн-обучению, где скажут, что: «Сменить профессию легко и просто», но маленький сноской укажут, что для опытных PM.

Это грустно, невкусно и неприятно как человеку, который сам работает проджектом, но действительно ли так мало мы можем рассказать о себе?

Вопрос, с которым сталкивается разработчик, тестировщик, дизайнер вплоть до самого проджекта.

С первого взгляда сложно оценить вклад и работу проектного менеджера по ряду причин:

• Если ваш проект только стартовал, то без должного масштабирования со структурной и организационной работой команды/проекта может справиться человек, который интегрировал идею (стартап, молодая компания разработки);
• Ошибка ведения проекта не сыграет роли. Если мы говорим о внедрении нового цвета кнопки и её роли на каком-нибудь маркетплейсе, то ошибка при работе над ней не станет сильно затратной (в случае с медициной, строительством, авиацией цена ошибки буквально может стоить жизни);
• Линейно-каскадные проекты, которые не требуют его ведения при полной автоматизации проекта (здесь мы говорим о цикличной и простой работе, где правок/изменений или форс-мажоры если не отсутствуют, то практически исключены).

Это если говорить от лица компании и смежных коллег, однако в голове проектного менеджера тоже могут возникнуть вопросы: Что я делаю?; Мы создали спринт и расписали дедлайны, а дальше сидеть и плевать в потолок?; Кто я вообще?; А не секретарша ли я для IT эквивалента?

По настоящему оценить работу проектного менеджера можно далеко не сразу, а лишь на дистанции. Давайте попробуем смоделировать работу компании в нескольких актах.

По началу вы обсуждаете ТЗ и все правки с клиентом/партнёром. Вы чётко сформировали список потребностей клиента и выявили все нюансы. Задокументировали и обозначали объём работы в часах перед разработчиками. Большинство скажет, что на этом можно закончить вести работу, особенно разработчики. В чём-то они могут быть правы, однако всё же нет.

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

Разработчик с каждой новой проблемой всё больше отдаляется от первоначальной сути и уходит в постоянное (или же нет) решение багов от тестировщика. Задача менеджера оценить ошибку и её критичность на разработку.

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

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

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

Вот вы уже на пороге выпуска релиза MVP, как вдруг обрастаете новыми клиентами и проектами. Как быть в таком случае?

Все просто — систематизируйте! Инструментарий дарован вам как от платных таск-систем (Jira, Confluence, Yandex Tracker, Битрикс24, и т. п.) до интеллектуальных карт (Mindmaster, Miro). Как только вы нарисуете полную картину, то сможете наблюдать как ведёт себя проект, что нужно сделать и кто должен заниматься поставленными задачами. На некоторых этапах вы можете вновь обратиться к построенной карте и убрать или же добавить этапы.

Ни в коем случае нельзя путать таск-трекеры и mind-map карты с нотацией BPMN или CJM (Customer Journey Map). Да, вы будете на 100% правы если скажете, что на них стоит обращать внимание при разработке, однако полноты внутренней разработки они не дадут:

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

Так что вкратце: Собирай, систематизируй, адаптируйся.

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

Всё прозаично и просто: развивайся. Как бы глупо и странно не звучало, но ни PM, ни девелопер или дизайнер не должен сидеть 24/7 перед монитором. Количество строчек в коде не сделает из тебя senior, а большая стопка проектов в фигме не превратит дизайнера в UX/UI. Точно такая же история касается и проектного менеджера. Нельзя расти и развиваться в рамках ведения проекта и не изучать новый материал, читать книги. Сам факт того, что вы внесли задачи и распределили их между коллегами! = ваше развитие.

Если вы начинаете расти в рамках Product Manager/Owner, то начинаете мыслить и видеть вещи совсем под другим углом. Вы начинаете говорить не только за администрирование, но и за бизнес. Однако одного желания стать PO недостаточно. Вы можете пройти курсы и получить отметку об их прохождении, однако реальные знания вы начинаете получать, когда возьмёте на себя больше ответственности за проект и за себя.

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

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

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

"project managers LIVES matter"

Про методологии и способы их применения, литературу, мысли и инструменты хочется рассказать отдельно, так что…

Ставлю себе таск и дедлайн написать новый пост через неделю. И спасибо всем тем, кто дочитал до конца!

See ya soon!