Экспрессом быстрее и удобнее. Фреймворк P3 Express в 1С

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

Почему вообще родилась идея этой статьи и откуда родился мой интерес к фреймворку P3 Express? Я довольно давно преподаю и консультирую в сфере Project Management. Ко мне очень часто приходят люди и говорят: «Мы хотим грамотно управлять проектами, посоветуйте нам, пожалуйста, какой комплект документов внедрить, какую технологию или методологию реализовать, чтобы у нас все стало хорошо с проектами».

Я, как правило, на такие запросы только широко развожу руками. Есть масса разных инструментов и способов. Например, возьмем PMBOK Guide – 6-й или предыдущей версии. Он выделяет 18 компонентов плана управления проектом.

К сожалению, какой-то универсальной «пилюли» нет, поскольку все контексты и проекты разные. Вы можете сами решить, какие из этих 18 компонентов плана управления будут вам полезны, и какие из документов по управлению проектами – их более 33 – пригодятся: журнал изменений, журнал допущений, устав команды, отчеты по рискам и так далее. А также какие из 46 процессов можно применять в управлении проектами.

Как вы понимаете, если начать перечислять все это собеседнику, который спрашивает: «Дайте комплект документов, чтобы внедрить» – он грустнеет, скучнеет, бледнеет и понимает, что ему, скорее всего, с этим не справиться.

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

Технологии 1С и их ограничения

Есть 1С:Технология стандартного внедрения, 1С:Технология быстрого результата, 1С:Технология корпоративного внедрения, которую мы достаточно часто используем. Это мощные инструменты, которые могут применяться в разных ситуациях, но опять же – это порядка 70 разных документов. Честно скажу: когда я реализовывала проекты по 1С:ТКВ, никогда не было такого, чтобы я брала все эти документы. Потому что если брать все документы и следовать всем процедурам, это отнимает столько ресурсов, что баланс между пользой от применения документа или инструмента и затратами на его применение очень часто нарушается. Оказывается, что мы слишком много времени и сил тратим на организацию процесса, а пользы – чуть-чуть.

Что еще мне не очень нравится в 1С:ТКВ – это то, что она предполагает, что все документы надо заверять на высшем уровне. Допустим, у вас есть большой документ, называемый «устав проекта». По сути это, скорее, план управления проектом. И любое изменение, по замыслу, должно быть согласовано с генеральным директором организации заказчика и генеральным директором организации исполнителя. Хотя в реальной жизни согласовывается не все.

«Быть» vs «Казаться»

У нас с вами, когда мы работаем, управляем, реализуем, есть умение «быть» – то есть делать реальную работу – и умение «казаться», то есть производить впечатление. У каждого в окружении есть люди, у которых очень хорошо получается «казаться», производить впечатление, но гораздо хуже – «быть». Эти люди умеют говорить красивые слова, показывать красивые графики, создавать впечатление. Как говорится: «Наша компания производит инвестиционно-привлекательное впечатление. Больше наша компания ничего не производит».

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

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

Особенности P3 Express

P3 Express не про «казаться» – он как раз про то, что мы реально делаем. Это простой, минималистичный фреймворк для управления проектами.

Я очень не люблю англицизмы, но не придумала, как перевести слово «фреймворк» на русский. Наверное, это каркас, поддерживающий и задающий структуру. Схема: делай раз, делай два, делай три. И когда мы это делаем, получаем результат.

Подойдет ли P3 Express вам на 100%? Конечно же нет, потому что все то, о чем я говорила выше – что контекст имеет значение и что каждая организация, каждая ситуация уникальна, – остается верным. Но по принципу Парето это те самые 20% усилий, которые дают 80% результата. Если вы возьмете документы из шагов P3 Express, то у вас большая часть вопросов будет закрыта.

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

• P – потому что Project.

• 3 – потому что третий уровень: индивидуальное управление, техническое управление, проекты, программы, портфели.

• Express – потому что быстро, коротко.

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

Честно скажу: если вы ожидаете, что ниже я буду рассказывать что-то уникальное, новое – что, оказывается, в проекте надо делать то, о чем вы никогда и не думали и никогда не представляли, – вас ждет разочарование. Потому что большая часть этих шагов из серии «Капитан Очевидность». Мы все про них знаем, но, к сожалению, не всегда их делаем.

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

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

Как мы работаем с P3 Express

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

Естественно, что эта схема не работает, потому что нет никакого контроля, нет уверенности в будущем. С другой стороны, обязать всех РП следовать 1С:Технологии корпоративного внедрения – тоже неработающая схема: под какие-то проекты она подходит, под какие-то – нет. К тому же она все-таки предполагает работу ближе к Waterfall, а у нас сейчас практически все проекты, если не гибкие, то гибридные. И это тоже надо учитывать.

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

Еще одно удобство – это открытая лицензия Creative Commons. Можно просто брать и пользоваться, мы никому ничего не должны.

Иногда мы используем P3 Express отдельно, иногда сочетаем его с другими технологиями. Например, как интеграторы мы снаружи с заказчиком берем технологию 1С:ТКВ или 1С:ТБР, а внутри компании управляем по P3 Express: проходим все месячные, недельные циклы и постоянно держим руку на пульсе, чтобы убедиться, что все хорошо.

Запуск проекта:

• A01 – Назначить спонсора,

• A02 – Назначить менеджера проекта,

• A03 – Назначить ключевых членов команды,

• A04 – Описать проект,

• A05 – Определить ожидаемые результаты,

• A06 – Определить риски и запланировать меры реагирования,

• A07 – Провести ревью запуска проекта,

• A08 – Решить «Go/No-go»,

• A09 – Провести стартовую встречу проекта,

• A10 – Направить фокусированную коммуникацию.

Остановлюсь на самых интересных шагах. Во-первых, это шаг «Описать проект».

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

1. Зачем? Какова цель ожидаемой выгоды?

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

3. Как будет проходить приемка? Каковы требования по качеству? Большинство историй с болезненными завершениями проектов связаны именно с тем, что этот момент не оговорен.

4. Перечень заинтересованных сторон. Кто ключевые участники? На кого мы ориентируемся?

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

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

В кратком резюме не было ответа на вопрос «что»: что же мы делаем? Какие результаты проекта? Это нужно описать в карте результатов проекта. Форма может быть любой. На картинке пример: мы взяли список функциональных разрывов и оформили его в виде карты пользовательских историй.

Очевидно, что карта результатов проекта будет пополняться и изменяться в течение проекта, потому что собрать все полностью с самого начала практически невозможно. Бесполезно пытаться собрать все требования сразу. Это просто рабочий документ, который будет изменяться. И в отличие от 1С:ТКВ, мы не просим генерального директора подписываться под каждым изменением. Главное, что мы на старте оговорили требования, как будет проходит приемка.

Следующий пункт – один из самых интересных в P3 Express. Мы пока только работаем над его внедрением, но я очень надеюсь, что в дальнейшем смогу успешно отчитаться о том, что получилось.

Этот пункт – Провести ревью запуска проекта, то есть проверить, что все пункты из списка запуска проекта успешно реализованы.

Самое интересное в этом пункте:

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

• Во-вторых, и это самое главное: кто проводит эту проверку.

Чек-лист здоровья проекта

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

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

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

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

То же самое – с управлением проектом. Если РП знает, что его потом проверят по чек-листу, это снижает вероятность того, что он попытается проскочить какие-то этапы.

Планирование цикла:

• B01 – Обновить и детализировать планы,

• B02 – Провести ежемесячное ревью,

• B03 – Решить «Go/No-Go»,

• B04 – Провести стартовую встречу цикла,

• B05 – Направить фокусированную коммуникацию.

Закрытие цикла:

• E01 – Оценить удовлетворенность стейкхолдеров,

• E02 – Извлечь уроки и запланировать улучшения,

• E03 – Направить фокусированную коммуникацию.

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

Очень важный пункт – это принятие решения «Go/No-go»: мы продолжаем или мы прерываем проект? Каждый месяц проект должен быть обязательно проверен на то, стоит ли его продолжать или нужно прервать. Это очень полезная практика.

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

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

Эта метрика может применяться как так называемая «опережающая метрика». Метрики можно разделить на запаздывающие, которые сообщают нам, что что-то уже случилось, и на опережающие, которые предупреждают, что что-то случится в будущем.

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

Еженедельные действия:

• C01 – Оценить и зафиксировать прогресс,

• C02 – Реагировать на отклонения,

• C03 – Провести еженедельную встречу,

• C04 – Направить фокусированную коммуникацию.

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

Во-первых, это субъективные ощущения самого руководителя проекта, руководителей рабочих групп. Вспоминая истории провальных проектов, часто можно вспомнить случаи, когда руководитель проекта пытался эскалировать проблему наверх: «У нас проблема, мы не справляемся», но ему не удавалось донести эту мысль до того уровня, где ее можно было решить. Тогда потихоньку начинал нарастать снежный ком, пока всем не становилось очевидно, что ничего не работает.

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

С одной стороны, мы оцениваем субъективные ощущения команды, а с другой – обязательно стараемся оценивать объективные показатели: бюджет, сроки, освоенный объем. Потому что бывают такие руководители проектов, которые думают: «Зачем я буду беспокоить своего начальника, выводить его из состояния гармонии? Я, как хороший подчиненный, должен сам исправить все проблемы» – и докладывает: «Все хорошо, все в порядке». Как в песенке: «А в остальном – прекрасная маркиза, все хорошо».

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

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

Внутри еженедельного цикла есть ежедневные шаги, когда мы смотрим, что происходит. Здесь я рекомендую такой инструмент, как журнал открытых вопросов. Его можно вести на Google Диске, можно – в таск-менеджере. Главное – не путать его со спискрм задач, которые надо делать. Важно отдельно выделять проблемы – то, что требует дополнительного внимания. Потому что в списке обычных задач, которые выполняются и с которыми «все хорошо», проблемы, требующие особого внимания, как правило, теряются.

Закрытие проекта:

• F01 – Передать продукт,

• F02 – Оценить удовлетворенность стейкхолдеров,

• F03 – Сделать ревью этапа закрытия,

• F04 – Заархивировать проектную документацию,

• F05 – Отметить окончание проекта!

• F06 – Направить фокусированную коммуникацию.

После проекта:

• G01 – Оценить полученные выгоды,

• G02 – Сгенерировать новые идеи,

• G03 – Направить фокусированную коммуникацию.

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

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

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

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

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