Трек распаковки РП: быстрая и (относительно) безболезненная адаптация Руководителей проектов

Начнем с синхронизации понятий.

• Слово «трек» подразумевает пройденный путь. Так обычно называют след, который заряженная частица оставляет в веществе. Или маршрут: например, GPS-трек – это последовательность точек, которые фиксируют перемещение.

• А «распаковка» – это процесс снятия всех упаковок с нового устройства, чтобы начать им пользоваться.

Получается, что «Трек распаковки руководителя проектов» – это путь, который проходит руководитель проекта от первых шагов входа в компанию до момента, когда он полностью готов выполнять свои функции.

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

Если у вас такого не было, значит вы либо ещё не нанимали РП, либо вам повезло, либо вы просто не хотите в этом признаваться.

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

• Покажу, как этот трек построен у нас, зачем он нужен, и почему мы к этому пришли.

• Поговорим, когда нужен трек – частый вывод РП, наличие и соблюдение технологии, и другие условия…

• И рассмотрим технологию сборки этого трека.

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

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

Бывают разные случаи, почему РП выглядит как РП, но с проектом не справляется – на слайде перечислены ситуации, с которыми сталкивались мы:

• Например, мы берем руководителя проектов, который ранее делал только проекты конкретного вида – например только проекты внедрения WMS-систем. У него отличный опыт внедрения, но как только меняется программный продукт, масштаб проекта или отрасль, которую мы автоматизируем, все, что он делал, ломается. Потому что та технология, которой он обладает, заточена только на конкретные виды бизнеса. И он не может справиться с новыми задачами. В результате он либо не доводит проекты до конца и сбегает из компании, а потом кому-то приходится доделывать за ним. Либо приходится подключать в проект дополнительного руководителя и новых людей, которые смогут вытянуть проект и снизить недовольство клиента.

• Другой вариант – руководитель проекта запускает проект по своей технологии. Тут есть плохой вариант, когда на внедрении оказывается, что технология не работает – система не запустилась, происходит откат, клиент недоволен, все плохо.

• И еще один вариант – лучше, но тоже не идеальный. Здесь у РП тоже есть своя технология, и он по ней даже смог запустить проект – формально все получилось. Но в результате мы имеем продукт, который непонятно как запущен. Мы имеем заказчика, который непонятно чего ожидал и непонятно какие его ожидания в результате удовлетворены. Потому что подписанные акты и полученные деньги – это не всегда показатель довольного и лояльного клиента, с которым можно работать дальше.

• И последний вариант – РП вообще не может управлять проектами. А его успешный опыт связан с тем, что на предыдущем внедрении ему повезло с руководителем проекта со стороны заказчика, который смог «вытянуть» весь процесс – смог отлично управлять своей командой, исполнителями и руководителем проекта со стороны исполнителя. Проект кажется успешным, но в этом нет его заслуги – бывают сильные ИТ-директора и менеджеры проекта со стороны заказчика, которые, увидев, что проект заваливается, берут все в свои руки и вытаскивают.

Что такое трек распаковки?

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

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

Материалы были, но возникала другая сложность: взрослые сотрудники часто либо читают их формально, либо вообще не открывают. Они могут сказать: «Я всё изучил, всё понял», а через неделю выясняется, что половину файлов они даже не видели.

Мы уже прошли через это с «Книгой сотрудника». Там нет ничего сложного – NDA, общая информация о компании, работа во внутренней учетной системе. Раньше мы не проверяли, изучил ли сотрудник материал, и это приводило к тому, что важная информация просто игнорировалась. Поэтому теперь мы обязательно проводим зачёты.

С «Книгой РП» всё ещё сложнее – это объёмный материал с диаграммами, примерами документов и практическими рекомендациями. Понятно, что просто так её никто досконально не читает.

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

В трек входят:

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

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

• Встречи, внимание куратора – обычно в формате «трио»: куратор (как правило, руководитель проектного офиса), сам РП и HR. Раз в неделю они обсуждают прогресс, закрепляют пройденное и дают задания на следующую неделю.

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

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

На слайде – реальный чек-лист, который мы используем. Я убрал только персональные данные.

Это та самая «зачетка» нового руководителя проекта. Когда к нам выходит РП, под него создается отдельная папка. Пока вся эта информация ведется только в Excel – потом, возможно, автоматизируем и переведем все в другую систему.

В «зачетке» есть:

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

• Внутри каждого этапа прописаны контрольные точки: «Знает, зачем нужен этап, как он проводится, каковы его результаты» и т.д.

• К каждой контрольной точке есть уточняющие вопросы, например: Проводил ли РП моделирование ранее в других компаниях? В чем отличие тех моделей, которые он делал до нас, от нашей модели? Такие вопросы помогают руководителю проекта поискать отличия, плюсы и минусы. Может быть, он что-то хорошее привнесет. У нас нет цели «вдолбить» в него нашу технологию – мы хотим и забрать себе что-то полезное.

• Есть материалы для изучения.

• Метод проверки контрольной точки – зачет, практика, упражнения.

• И указано, кто проверяет.

Всего в этом чек-листе около ста пунктов. Часть из них – обязательные (они помечены желтым цветом), это то, что новый РП обязательно должен выполнить в рамках трека.

Обычно трек длится около трех месяцев. Мы предполагаем, что опытный руководитель проекта за 3 месяца с контролем и учебными материалами сможет полностью адаптироваться и начать вести проекты по нашей технологии, обеспечивая клиенту именно тот результат, который мы обещали на пресейле. Ведь когда мы общаемся с клиентом на старте проекта, у него формируются ожидания: что будет на каждом этапе, какие документы он получит, и как будет организована работа. Наша задача – не допустить ситуации, когда клиент говорит: «А нам обещали одно, а сделали другое».

На слайде показано, как выглядит список встреч по треку.

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

Например, одно из упражнений – участие в стартовой встрече по проекту с клиентом. Новый РП сам ее не ведет – на этом этапе это делает опытный руководитель, чтобы исключить риски. Задача новичка – наблюдать за происходящим и на встрече по развитию дать развернутую обратную связь, ответить на вопросы: «Что происходило? Как себя вел клиент? Было ли в его поведении что-то необычное? Были ли попытки изменить границы проекта или устав? Какие риски могут возникнуть в проекте, судя по текущему впечатлению?» И т.д.

Когда стоит всем этим заниматься?

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

На эту работу потребуется вложить время. Поэтому заниматься всем этим имеет смысл, только если:

• Новых РП нужно много, и вы планируете нанимать их регулярно – для вас это не разовое мероприятие. Если вам нужен просто еще один РП и в обозримой перспективе больше не понадобится – проще взять человека и вести его «вручную», исходя из здравого смысла.

• У вас есть своя технология управления проектами, и вам важно, чтобы новые РП ее соблюдали. Если технологии нет, и вы берете РП, чтобы он принес свою, тогда учить его нечему – наоборот, вы будете учиться у него.

• Есть кому адаптировать руководителя проектов. Без регулярных встреч трек не заработает. Отдать материалы и пару раз встретиться – это не обучение. Взрослые учатся только при наличии структуры и контроля – иначе обучение превращается в «отложенный курс». У многих есть купленные, но так и не пройденные онлайн-программы. Даже если заплатил свои деньги, без дедлайнов, зачётов и контрольных точек руки до них не доходят. С треком та же история: если просто выдать стопку материалов с формулировкой «разберись за три месяца», ничего не произойдёт – текущие задачи всегда будут важнее. А вот когда обучение встроено в конкретные даты и есть обязательные встречи, задания и отчётность, вероятность пройти путь до конца значительно выше.

Технология сборки трека

При составлении трека в нем необходимо описать:

• Продукт руководителя проектов (результат его деятельности).

• Систему оплаты труда.

• Общую информацию про проекты и управление проектами в вашей организации.

• Основные этапы проекта.

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

• К каждому пункту – «как изучить». Если теория – что прочитать или посмотреть. Если практика – какую задачу или наблюдение в проекте сделать.

• Как проверяем знания и навыки

Вопросы и ответы

Что делать, если РП приходит на проект, который велся до него несколько лет? Как за месяц-два передать ему весь нужный объем знаний и при этом не перегрузить человека? Тем более, что чаще происходит ротация – РП приходит на место другого, который увольняется. И чтобы получить информацию по проекту, нужно приходить без оплаты 2-3 дня до фактического приема на работу. А тот, кто увольняется, не заинтересован тратить много времени на передачу дел.

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

• Например, из плана проекта – по нему можно понять, насколько мы по этому плану идем, отстаем, не отстаем. Где мы должны находиться, и где мы находимся на самом деле.

• Еще есть требования, устав и все остальное.

• Статус-отчеты, если они были.

• Записи встреч. Мы обычно, если клиент не против, делаем видеозаписи статус-встреч и интервью. Если есть видеозаписи, их можно пересмотреть в ускоренном режиме, чтобы уловить ключевые моменты и понять, что происходило на предыдущих этапах.

• Дальше – команда. Разговариваем с каждым: что сейчас происходит, какие задачи, какие проблемы были, как ведет себя клиент.

• Затем – руководство. У них может быть информация о финансовой части, договорах, штрафах, обязательствах.

• Полезно также сходить к продавцу проекта – особенно, если он до сих пор в контакте с клиентом. Он тоже может что-то дать интересное.

• И в крайнем случае, если внутри компании никто ничего не знает – идти к клиенту. Честно представиться, объяснить, что информации немного, но есть желание довести проект до конца, и предложить вместе разобраться в текущем статусе и обновить план. Но это последнее, что я бы сделал. Потому что идти к клиенту и признаваться, что мы облажались и даже не умеем проекты передавать внутри – неправильно. Но такая искренность, наверное, может сработать.

Изучение заданий во время адаптации происходит в рабочее время или в нерабочее?

У нас в рабочее время заложено от 30 до 40% на изучение, на прочтение материалов, книг, статей, на просмотр шаблонов и видео, записанных по этапам проекта.

Оставшиеся 60–70% занимают реальные рабочие задачи, которые тоже связаны с учебным треком. Например, изучая этап реализации, РП одновременно ставит задачи разработчикам, участвует в клиентских демо и параллельно читает материалы и кейсы по этому этапу. То есть примерно 40% времени уходит на обучение, а 60% – на выполнение работы на практике.

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

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

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

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

У каждого РП есть своя система отчетности: подготовка и согласование статус-отчетов, планирование, ведение проектной документации и работы в учетной системе ().

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

Кто отвечает за то, чтобы эти 100 строк в чек-листе соответствовали актуальному состоянию технологии? Например, у нас технология меняется минимум раз в полгода-год и иногда достаточно заметно. Мы можем договориться по-другому вести себя с заказчиками или сдавать другую отчетность – в результате из-за какой-нибудь новой договоренности может потребоваться переписать половину базы знаний. Как вы с этим справляетесь?

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

Мы следим за актуальностью постоянно и добиваемся, чтобы сотрудники перечитывали обновлённые материалы. Сейчас мы перешли на автоматизацию – внедрили систему LMS (Learning Management System). В ней любое обновление, будь то памятка или инструкция, автоматически формирует задание для сотрудников: прочитать, поставить отметку о прочтении или ответить на тестовые вопросы. Сейчас постепенно переводим всех на обучение через неё.

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

Да, без этого никак, потому что иначе наши наработки просто теряются.

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Анализ & Управление в ИТ-проектах.