Как визуализировать P3.express для команды: опыт компании Express 42

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

Символом (!) буду помечать заметки, которые могут быть полезны, хотя я по разным причинам этим не пользовалась.

1. Собрать исходные данные

Стоит начать со сбора условий и нюансов работы, на которые будет наложен фреймворк:

• сегмент рынка;
• услуги/продукты;
• на что больше всего уходит внимания команд;
• в каких условиях работают команды;
• какими ресурсами они пользуются в оперативной работе;
• как происходит шаринг знаний и информирование о событиях.

Как строится работа во вне

Express 42 — это центр компетенций DevOps и построения ИТ-процессов. Компания помогает осуществить digital-трансформацию, ускорить процессы поставки и устранить препятствия на пути выхода в продакшн. Основные направления деятельности Express 42 — анализ и консалтинг, внедрение DevOps-практик и обучение.

P3.express я внедряла в Юнит DevOps-практик сначала одна, позже появился надежный напарник. Поэтому далее по тексту «я» сменится на «мы».

Исходя из особенностей наших услуг, я выписала следующие основные тезисы:

1. Средняя продолжительность проектов 1,5-3 месяца, и работа на территории Клиента. Значит, что мы подключаемся к инфраструктуре Клиента, работаем по принятым у него методологиям — Kanban, Scrum и так далее.
2. Несколько проектов находятся в работе параллельно, на каждом из них разные ресурсы (Jira, YouTrack, Trello, Notion, Confluence и очень многие другие). Следовательно, консолидация сводной информации по состоянию проектов занимает много времени и крайне неудобна.
3. Значительная доля времени уходит на коммуникации с Клиентом: уточнение стартовых позиций и как обстоят дела, передача статуса работ, передача экспертизы, периодические синхронизации по ожиданиям, получение обратной связи и прочее.

Как построена работа внутри

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

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

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

В дальнейшем такие заметки помогут в выборе понятных команде слов для описания фреймворка P3.express и могут быть основой для аргументации в пользу его внедрения.

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

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

(!) Для визуализации as is и to be так же отлично подойдет нотация BPMN.

Техническая составляющая

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

В Express 42 мы используем следующее:

• Slack — для внутренних коммуникаций.
• Notion в качестве базы знаний.
• Miro для составления схем процессов, дорожных карт и брейншторма.

Первичный вариант схемы работы с проектами и краткие тезисы я нарисовала в Miro. Работа с графическим отображением to be помогает очистить процесс от ненужного, постоянно задавая себе вопрос «чтобы что?». Например, проектная команда работает в ресурсах Клиента, а мы настраиваем внутреннее рабочее пространство, чтобы что? Чтобы основная информация по проекту была в одном месте, под рукой (контакты, стек, календарь встреч, заметки по встречам и т.д.) и доступна другим отделам, кто работает с этим же Клиентом.

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

Надежный тыл

Итак, у нас есть представление, как процесс видит команда, какой характер работы с Клиентами, через что будет идти техническая реализация основной задачи.

Вроде бы всё самое нужное для работы.

И это ошибочно.

Очень важно помнить про себя. И помочь себе будущему работать эффективно, экологично и не терять фокус.

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

(!) Про удалённую работу в PMCLUB есть бесплатный курс.

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

2. Организация своей работы

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

Теория и практика

На мой взгляд, внедрять P3.express в жизнь компании всё же лучше поэтапно, изучая шаг за шагом и постепенно адаптируя его к реалиям. Ведь если сначала пройти курс (или самостоятельно всё изучить) и потом попытаться применить к проектам, может возникнуть множество вопросов и желание перечеркнуть все прошлые наработки и начать «с чистого листа». Это тоже вариант, но моя практика и наблюдения показывают, что новое приживается легче и плотнее, если ложится на уже привычный фундамент.

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

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

Для более эффективной постаналитики фиксируем итоги всех ретро по проектам в сводной таблице в разделе Notion. А с ноября 2021 стали активно использовать облегчённую версию ретро для проведения встреч внутри команды. Об этом подробнее ждите отдельной публикации в блоге PMCLUB.

Описание фреймворка в Notion

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

• «Стартовая встреча» по P3.express стала у нас называться «Kick-off internal» и «Kick-off external».
• «Фокусированная коммуникация» — daily, weekly с последующим оформлением и рассылкой саммари на участников и заинтересованных лиц.

Раздел со всей информацией по фреймворку решили назвать просто и незатейливо — Процесс управления проектами (ПУП). Он имел простую вертикальную ориентацию с описанием шагов по порядку.

Чтобы информация воспринималась легче, в каждом блоке работ отдельно выделили:

• Действия, которые проводятся участниками команды.
• Документы, которые преимущественно оформляет Координатор проектов.
• И правила работы с Информационной системой управления проектами (ИСУП).

Ошибка: не учла специфику работы команды

Когда готовила справочный раздел в Notion, я предполагала, что работа по проекту будет проводиться последовательно:

• определяем цели/задачи,
• подписываем документы,
• получаем доступы,
• проводим установочную встречу,
• работаем,
• показываем результат,
• передаем экспертизу,
• закрываем проект.

Всё как у всех, всё как обычно.

Но я не учла очень важный момент — в проекте задействовано несколько ролей. Каждая из них со своим функционалом и со своей длительностью привлечения.

И здесь стоит сделать остановку. В чём была моя ошибка?

В работе мы опираемся на свой прошлый опыт. Но иногда от него всё же стоит абстрагироваться. Дело в том, что ранее я работала классическим project manager-ом, который вёл проект с момента первого контакта с Клиентом до… как минимум до получения последнего платежа после успешной защиты проекта.

В Express 42 я координирую работу проектов. При этом всегда на связи с Клиентом остаются Account Manager, который принимает в работу первое обращение компании, и Delivery Manager, который подключается уже на предпроектном этапе, когда идёт урегулирование условий договора. И тут важно отметить, что каждая роль на проекте отвечает за свой участок.

Соответственно, и в выполнении тех или иных шагов по P3.express участники команды могут подключаться в асинхронном режиме и ограниченном объёме.

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

Итак, я получила простое сообщение от одного из наших Delivery Manager:

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

(!) При внедрении фреймворка думайте о пользователе и его комфорте в процессе использования. Имеет смысл заранее разработать user stories и CJM.

3. Унификация, шаблонизация, адаптация

За 3 месяца промышленной эксплуатации первой версии ПУПа я собрала критерии, которым должна была соответствовать следующая версия.

Их можно выразить так:

1. Принцип одного монитора — чем меньше пользователю нужен будет скроллинг, тем легче он будет получать необходимую информацию.
2. Цветовые акценты — чем быстрее пользователь будет находить необходимую информацию, тем чаще он её будет использовать.
3. Персонализация — у пользователя должна быть возможность как ознакомиться с процессом полностью, так и отфильтровать шаги только для себя.
4. Шаблоны и чек-листы — правильная визуализация должна сохранять время пользователя для возможности выполнения осмысленных действий.
5. Учёт уникальностей — стоит заложить в свою визуализацию возможность дополнительных артефактов, которых нет в P3.express, но которые необходимы конкретной компании.

Возможности Notion позволяют создать доску (изначально это была классическая kanban-доска) и настроить необходимые представления. Да, элементы цикличности работы с проектом, которые заложены в основу P3.express, здесь никак не отражены. И это иногда вызывает вопросы у новых сотрудников. Но пока пользуемся такой визуализацией, потому что своё предназначение выполняет хорошо.

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

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

Разделы в рабочем пространстве Notion

Раздел «Инструментарий» служит сборником описаний других фреймворков, которые могут быть полезны на некоторых проектах.

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

Раздел «Положительные практики» является сводом фич, которые были придуманы и внедрены на отдельных проектах и могут быть полезны где-то ещё.

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

Особое внимание мы уделили шаблонам и чек-листам. Теперь каждый проект со своими локальными особенностями выглядит одинаково и проходит одни ключевые точки.

Какие результаты получили

1. Значительно быстрее стали разворачивать внутреннее рабочее пространство и проводить аудит подготовки (к старту, к сдаче этапа работ, к сдаче проекта, к закрытию работ и т.д.);
2. Значительно облегчился поиск необходимой информации, когда во всех проектах единый состав и расположение артефактов;
3. Минимизирован человеческий фактор (что-то забыли или изобрели велосипед).

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

4. Внедрение в работу

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

В Express 42 на момент вебинара и подготовки этой статьи было выпущено 2 версии ПУПа, и каждый раз процесс информирования команд и менеджмента проходил системно.

Если обобщить, можно выделить следующие пункты:

Использование устоявшихся форм информирования сотрудников об изменениях

• Каждые 2 недели в Express 42 проводятся встречи с докладами. Чаще всего на этой площадке инженеры делятся интересными техническими решениями из своих рабочих будней. Мы использовали площадку дважды (для каждой версии ПУПа), чтобы всем одномоментно рассказать о ПУПе и новым сотрудникам в дальнейшем давать ссылку на запись.
• Каждый четверг выходят дайджесты с автоматической рассылкой, где команды делятся новостями с проектов. При внедрении первой версии ПУПа я постила новости каждую неделю. Мне важно было внедрить в обиход название процесса, его расположение в Notion и максимально напоминать, что он есть, пока не все проекты были переведены на ПУП.

Последовательность в документации

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

Человеческое отношение к интеграции фреймворка в жизнь компании

• Уже несколько лет в Express 42 практикуется one-to-one, и с прошлого года внедрили coffee random. Сотрудники Express 42 работают из разных городов и, иногда, стран. И такой формат встреч позволяет сохранять связи и делать приятные перерывы между рабочими задачам. Иногда на таких встречах ребята задают вопросы о проектном управлении, до которых в работе могут руки не доходить.
• На вебинаре 4.12.2021 я рассказывала, что со второй версии ПУПа у нас появился свой маскот. Его честно, стырила из вселенной Автостопом по галактике, потому что исторически Express 42 тесно связан с творчеством Дугласа Адамса.
• Показателем органичной интеграции фреймворка в жизнь компании можно считать то, что у нас появились наши локальные мемасики, например, «Я.МЫ.ПУП». Здесь стоит уточнить, что в них нет никакой связи с хештегом Я/МЫ, который получил международное распространение несколько лет назад. Для нас он означает согласие и единение в слаженной командной работе, какой бы сложной или специфической она ни была.

5. Выводы

Первая редакция визуализации фреймворка помогла переработать его под особенности Express 42, но не решила поставленные задачи. Со второй редакции получилось построить рельсы, по которым сейчас проходят проекты.

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

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