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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В Express 42 мы используем следующее:
— slack — для внутренних коммуникаций;
— notion в качестве базы знаний;
— miro для составления схем процессов, дорожных карт и брейншторма.

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

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

Надежный тыл

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

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

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

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

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

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

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

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

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

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

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

Например, мы не пользуемся отдельным документом «Здоровье проекта», потому что качество коммуникативных связей позволяет оперативно реагировать на тенденции. При этом артефакт «ретроспектива» расширили до настоящего инструмента повышения качества работы команд — мы проводим ретро не только с Клиентом, но и внутри команды. И для более эффективной постаналитики фиксируем итоги всех ретро по всем проектам в сводной таблице, оформленной как раздел в Notion. А с ноября 2021 стали активно использовать облегчённую версию ретро для проведения встреч внутри команды. Об этом подробнее ждите отдельной публикации в блоге pmclub.

В качестве основного ресурса, где будет описание фреймворка, я выбрала привычный и понятный коллегам Notion. При написании статей уже использовала устоявшуюся терминологию. Так, например, «Стартовая встреча» по р3х стала у нас называться «Kick-off internal» и «Kick-off external», «Фокусированная коммуникация» — daily, weekly с последующим оформлением и рассылкой саммари на участников и заинтересованных лиц.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Такие приятные последствия мы получили почти сразу:

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

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

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

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

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

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

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

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

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

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