Запутанные процессы?

Покажем, как навести порядок с помощью Кайтен — за 30 минут.

Записаться на демо

P3.express — молодая минималистичная методология управления проектами, которую применяют команды по всему миру, в том числе в российских компаниях. В России одним из главных популяризаторов методологии стал Дмитрий Ильенков, основатель школы управления проектами pmclub. Он участвовал в переводе руководства P3.express на русский и вместе с командой обучил методологии сотрудников Т-Банка, OZON, Avito.

Недавно Дмитрий вместе с супругой Валерией Ильенковой выпустил книгу «Не усложняй! Управление проектами по методу P3.express». По случаю выхода книги мы расспросили Дмитрия о методологии: как она устроена, какие ошибки мешают внедрению и почему начать перемены можно даже с одного маленького документа.

P3.express — способ доводить проект до конца и без боли

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

P3.express устроена по тому же принципу. В методологии 33 шага на весь проект, от первой идеи до подведения итогов, и в каждом шаге конкретное действие: описать проект, назначить спонсора, провести стартовую встречу. Прошли шаг — перешли к следующему: вот, собственно, и все управление проектом.

Чтобы в шагах было проще ориентироваться, авторы разбили их на семь этапов:

1. Запуск проекта: организация назначает спонсора, а тот определяет менеджера. Дальше формируется команда, описывается проект, определяются ожидаемые результаты и риски и принимается решение о запуске или отмене проекта.
2. Планирование цикла: раз в месяц команда обновляет и детализирует планы.
3. Еженедельные действия: команда фиксирует прогресс и реагирует на отклонения.
4. Ежедневные действия: участники решают текущие проблемы и принимают результаты работы.
5. Закрытие цикла: команда оценивает удовлетворенность заказчика и извлекает уроки.
6. Закрытие проекта: команда передает продукт, архивирует документы и отмечает завершение.
7. После проекта: компания оценивает, какие выгоды принес проект.

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

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

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

Так P3.express остается легковесной методологией даже после адаптации: в ней сохраняются простая структура, понятные шаги и минимум документации.

Успешные компании уже используют Кайтен Попробуйте расширенный функционал на своем проекте бесплатно

Попробовать

Методологий уже десятки — зачем понадобилась еще одна

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

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

Однако внутри компании, по опыту Дмитрия, часто нужно и то и другое.

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

Заставлять обе команды работать одинаково бессмысленно — им нужна методология, которая соединит оба способа работы:

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

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

Почему простые шаги не работают: ревью и KPI

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

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

Вот причины, почему так происходит:

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

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

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

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

Компании неправильно понимают роль спонсора

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

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

Где компании ошибаются. По опыту Дмитрия, роль спонсора часто трактуют неправильно:

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

Особенно трудно компаниям пересмотреть последнюю трактовку. Дмитрий объясняет проблему так:

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

На консультациях Дмитрий проверяет выбранного спонсора с помощью вопросов. Например:

• Кто может выделить сотрудников внутри компании?
• Кто согласует дополнительные часы?
• Кто обсудит приоритет проекта со смежным отделом? 

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

Проекты не закрывают по-настоящему

Закрытие проекта в P3.express — отдельный этап. На нем команда:

• передает продукт заказчику;
• оценивает удовлетворенность заказчика и команды;
• извлекает уроки;
• архивирует документы;
• отмечает окончание проекта.

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

На вопрос, часто ли команды так заканчивают проекты, Дмитрий отвечает: максимально часто. Причина не в безответственности:

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

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

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

Что еще мешает компаниям принять P3.express

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

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

Когда Дмитрий начал рассказывать о P3.express в России, методологию почти никто не знал. На тренингах люди слышали название впервые, в вакансиях его не упоминали, а примеров успешного внедрения было мало. На этом фоне Scrum, Kanban и каскадная модель выглядели надежнее просто потому, что компании давно с ними знакомы.

В этом ощущении Дмитрий и видит парадокс: «современность» привычных методов держится только на привычке:

Scrum действительно представили еще в 1995 году. Kanban еще старше: его принципы пришли из производственной системы Toyota середины прошлого века. Инструменты рабочие и проверенные, но новыми они были очень давно.

А вот страх сотрудников устроен иначе — он не исчезнет со временем. Причина в том, что новая методология делает работу прозрачнее, а прозрачность радует не всех:

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

Резюме проекта: 1 шаг, который окупается еще до старта

Тем, кто не готов внедрять все 33 шага, Дмитрий советует начать с одного документа — резюме проекта. Команда заполняет его до старта, еще на уровне идеи, и отвечает в нем на несколько вопросов:

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

Сила документа — в первом же вопросе:

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

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

Вопрос о рисках — дополнительный: в полной версии методологии работа с ними выделена в отдельный шаг. Но если для начала вы хотите использовать лишь базовый минимум P3.express, Дмитрий советует хотя бы коротко записать, что может помешать проекту. Так решение о запуске станет взвешеннее.

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

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

Дмитрий посоветовал никому не отказывать и просто просить заполнить резюме проекта в Google-форме. Форму заполнили единицы — ровно те, кому проект действительно нужен и кто готов в него вкладываться. Эффект Дмитрий описывает так: «здоровые проекты не пострадают, а пыль просеется».

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

Для Карты результатов и Реестра последующих действий создают две доски в одном пространстве. Собирать их с нуля не нужно: в Kaiten есть готовый шаблон для P3.express. Команда видит статусы шагов рядом с задачами и не переключается между отдельными документами.

Куда идти за остальными 32 шагами

Резюме проекта — один шаг из 33. Остальные Дмитрий разбирает в книге «Не усложняй! Управление проектами по методу P3.express», которую написал вместе с Валерией Ильенковой. Общий принцип у книги и методологии один: управление проектами складывается из понятных действий, которые по силам любой команде.

Памятка из разговора с Дмитрием

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

И главное — не усложняйте.