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

Разбирается Дарья Викторова, менеджер проектов вертикали «Товары» в «Авито».

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

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

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

Большинство компаний на рынке имеют цикличные процессы, в которых:

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

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

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

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

1. Цель планирования

2. Участники планирования

3. Что должно быть результатом планирования

4. Инструменты и формы, которые используются для планирования

5. Правила заполнения

6. Ответственные за заполнение

7. Таймлайн планирования

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

Этот пример основан на реальном кейсе. Я создала инструкцию для планирования OKR вертикали — этот процесс фасилитирует проектный офис. Вот как выглядит структура созданной спецификации:

Давайте разберём, что на ней есть.

В первую очередь, это отдельная карточка текущего планирования и его стадии, дежурный по процессу текущего квартала, ссылка на общий финальный файл и расписание планирования. Далее по содержанию:

1. Stages — стадии процесса планирования

2. Description of stages — описание каждой из стадий, отображённых на схеме и DOD после каждой стадии

3. Responsible — матрица ответственных по процессу в каждой стадии

4. Rules — ключевые принципы формирования и заполнения OKR

5. Calendar — общий таймлайн и пример расписания всех встреч, которые надо провести

6. Meetings and notifications — какие встречи должны быть и какие уведомления необходимо сделать во время планирования

7. Useful artefacts — другие полезные ссылки, которые помогут детальнее погрузиться в процесс планирования

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

Создавать шаблоны можно не только в рамках стандартных рабочих задач. Они подходят и для других процессов. Вот ещё один пример 👇🏻

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

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

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

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

Стратегия должна идти первой и всегда должна быть согласована заказчиком. В данном случае — с менти. Мы встретились и обсудили вводные: цель и задачи менти, критерии приёмки и таймлайн.

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

Я начала размышлять: что может быть доказательством того, что человек является профессионалом в своей области? Ответ пришёл быстро — общественное признание коллег, которые будут соотносить тебя с должностью, на которой ты находишься. Что может являться физическим воплощением общественной оценки? Это процесс performance review, когда тебе ставят оценки, основываясь на профессионализме и соответствию ожиданиям по занимаемой позиции.

Цепочка вышла такая:

Я работаю над развитием в профессии → коллеги и руководитель оценивают мою работу → они ставят мне оценку не ниже, чем «соответствует ожиданиям» → я могу объективно считать себя профессионалом.

Так у нас родилась физическая цель из неочевидно сформулированного запроса.

Подготовила материалы. Тайминг проекта был нам известен — ведь мы знаем, когда происходит performance review. Осталось наполнить его артефактами, которые необходимы для подтверждения работы, и утвердить с менти.

Согласовать стратегию — значит решить 50% задачи. Дальше остаётся только декомпозировать большую цель на промежуточные вехи и наполнить их необходимыми задачами и артефактами.

Моя менти находилась на испытательном сроке, так что очевидной и ключевой вехой было прохождение испытательного срока — период был обозначен в 3 месяца. Я разбила его на месяцы и в каждый добавила шаги, от простого к сложному, которые надо будет пройти для успешного онбординга. Шаги также были напрямую связаны со стратегией и отражали hard и soft скиллы, которые необходимы для нашей большой цели — успешного прохождение review. Выполнение этих шагов было возможно с помощью инструментов, указанных в стратегии.

Калибровалась с менти на промежуточных этапах. После успешного прохождения испытательного срока мы сделали большой синк и выровняли ожидания. Далее остался второй период — 2,5 месяца до performance review. Мы заполнили новыми задачами такой же шаблон и начали по нему двигаться. Каждая задача на таймлайне содержит артефакты, которые находятся на той же доске, то есть к ним всегда можно обратиться.

Благодаря такому подходу, мы успешно прошли по всему процессу. Менти выполнила цель, к которой шла, а я осталась на руках не только с успешным кейсом менторинга, но и с шаблоном для этого процесса. Он позволит мне масштабировать процесс и в будущем справляться с ним гораздо быстрее. Даже если у новых подопечных будут другие цели, это не повлечёт глобальных изменений логики, по которой будет идти процесс менторинга.

Шаблонизация — это качественная проработка процесса или сущности, которая позволит сократить time to market целей и задач и масштабировать их с наименьшей затратой ресурсов. Шаблоны сами по себе гибкие, благодаря этому сохраняется и гибкость задач, которые они решают.

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