Всем привет. Меня зовут Даша Викторова, я Project Lead направления автоматизации доставки в Lamoda. Сегодня поговорим про проектный менеджмент… Но не совсем :) 

Как правило, проджект-менеджер (или просто PM) отвечает за реализацию проектов — как ни странно! Однако любой проект состоит не только из задач, которые ведут к достижению конечной цели, но и из процессов, от которых зависит качество и скорость их достижения.

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

Сущности, с которыми работает PM

Project manager — сама по себе очень неоднозначная позиция. Почти во всех вакансиях она сформулирована одинаково, но при этом подразумевает абсолютно разные функции, учитывающие специфику конкретного места работы. 

Все определяется тем, что считается проектом для организации: рекламная кампания, какой-то ивент, иногда даже продукт. В зависимости от этого будет разный набор хард скилов, начиная от собственных знаний об отрасли и заканчивая специфическими инструментами: таск-трекеры, сервисы, интерфейсы, визуализаторы. Тем не менее, можно выделить общие ключевые сущности, с которыми работает Project manager. 

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

Процессы в проектном менеджменте 

Что же такое процессы в Project Management? Ответ очень прост — это любой шаг, который мы предпринимаем для решения той или иной задачи. И все эти шаги можно и нужно описывать и регламентировать. Для кого-то может звучать неожиданно, что процесс, в котором человек работает каждый день, можно описать, а не просто «договориться на словах», но именно такой подход позволяет процессу жить, а всем участникам — соблюдать его. 

Давайте разберем на примерах. 

Каждое утро у вас есть стендап с командой. Он длится 15–20 минут, где все участники кратко рассказывают, что делали вчера и что собираются делать сегодня. Это кажется абсолютно обыденным действием, но на самом деле это самый что ни на есть процесс: он был построен кем-то из менеджеров или тимлидов этой команды, его правила были оговорены с участниками, его проведение было регламентировано и самое главное — его соблюдают. 

Еще пример. К вам пришел новый проект от вашего продакта. Вы прочитали BRD и поняли, что в нем недостаточно описания, поэтому вы пока не можете отдать его команде для проработки технического решения. Продакт дорабатывает документ и возвращается с обновленной версией. Она вас вполне устраивает, поэтому вы отдаете проект техлиду системы для декомпозиции и описания архитектуры — он оценил эту задачу в одну неделю. Он создает страницу в Confluence и проектный эпик в Jira, наполняет их по шаблону данными, нарезает и описывает задачи. Все вышеописанные действия — уже несколько процессов: процесс взаимодействия с продактом и процесс работы над проектом внутри команды. И каждый из них требует своих правил игры, которые должны соблюдаться. 

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

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

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

Теперь разберемся, как это делать. 

С чего начинать изменение процесса 

А начинать стоит с проблематики. Как и в проектном управлении, сначала задаем себе вопрос — какую проблему мы хотим решить? Не всегда ответ на него лежит на поверхности. 

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

• разработчики уделяют ревью недостаточно времени; 

• разработчики не успевают проводить ревью; 

• на доске слишком маленькое ограничение на колонку ревью; 

• качество задач слишком низкое и среди них большой процент брака, поэтому ревью идет долго. 

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

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

Итак, попробуем подойти к ситуации с разных сторон. Есть выявленная проблема — ревью тормозит реализацию задач. Следующий вопрос, который поможет вам определиться с действиями: «А как оно должно вообще работать сейчас? Как и почему оно работало раньше?» — типичное AS IS. Возможно, разработчики просто действуют вразнобой, потому что не понимают, как это надо делать «по ГОСТу». Так мы выявили одно из действий, которое предстоит предпринять в починке процесса — создать документацию по процессу. 

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

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

Итак, у нас есть документация, которая регулярно обновляется. Разработчики ее читали и даже стараются соблюдать — что тогда? Возвращаемся к началу и смотрим на другие возможные причины и прорабатываем гипотезы. Рано или поздно вы нащупаете root cause (то есть истинную причину возникшей проблемы) и тогда останется дело за малым. 

Я предлагаю использовать продуктовый подход: просто отнеситесь к процессу как к продукту. 

Проблему мы определили, гипотезы накидали и даже поняли, в какой из них вероятнее всего скрывается root cause. Теперь нужно понять, кто же потребители этого продукта (то есть — проблемы)? Иными словами, определяем ЦА. Важно учесть всех участников процесса, потому что для каждой группы нужно найти свое решение — такой же подход используется с b2b и b2c-продуктами. Проведите исследование и узнайте про аналогичные процессы у коллег: посмотрите, как они работают у них, с какими проблемами сталкивались команды и как их решали. 

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

Нашли проблему, выбрали решение — что дальше? 

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

Но не забывайте и про внедрение процесса. Все молодцы, проделали огромную работу, нашли проблему, продумали решение и устранили ее… А устранили ли? 

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

Итак, время подводить итоги

К изменению процесса стоит подходить так же, как и к любому проекту или продукту. Для успешной реализации нужно проходить точно такие же шаги: создание BRD (AS IS и TO BE), выявление проблемы, проработка решения, аналитика и декомпозиция, внедрение и постподдержка. 

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

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

Полезные материалы  

Почитать: 

• Джефф Сазерленд «Scrum. Революционный метод управления проектами»

• Михаил Рыбаков «Бизнес-процессы: как их описать, отладить и внедрить»

• PDCA Цикл на примере процессов

• PDCA Цикл на примере проектов 

Послушать:

• ‎Project Talks: Дарья Сутягина: как стать проектным менеджером в IT и куда расти дальше (Apple Podcasts)

• Hexlet: Интервью с Дарьей Сутягиной о проджект-менеджерах, разработчиках и их коммуникации