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

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

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

Привет! Я Кристина Павлив, CPO в МТС. В проектном управлении я уже около семи лет, сменила три компании и реализовала более 20 проектов. Наверняка почти каждому проджекту (особенно начинающему) знакома ситуация, когда ты должен делать почти всё: управлять командой, анализировать результаты и самому выбивать бюджеты.

Так было и у меня. Расскажу, как всё было и чем закончилось.

Начало проекта

Семь лет назад я сменила сферу аналитики данных на проектный менеджмент. В аналитике я занималась отчётами и таблицами, брала на себя дополнительные задачи: составляла ТЗ на доработку CRM, формировала программу и проводила обучение бизнес-команд. Это помогло мне «продавать» себя на собеседованиях.

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

  • Предпосылки: в точках обслуживания компании не вёлся учёт количества и затрат на расходные материалы (бумага, чековая лента, бланки и прочее). Поскольку у компании достаточно развитая сеть точек обслуживания, затраты исчислялись в сотнях миллионах рублей, которые никто не контролировал.
  • Описание: необходимо организовать процесс учёта в точках обслуживания, внедрить систему учёта расходных материалов. Соответственно, у меня была верхнеуровневая задача и ТЗ пришлось писать самой, исходя из бюджета.
  • Цели: экономия затрат на расходных материалах и обеспечение прозрачного учёта и контроля за целевым использованием.

На все руки мастер

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

Во-первых, таким был состав проектной команды:

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

Заметили что-то необычное? Конечно, можно написать, что в компании не было ресурсов и все были заняты своими задачами, а проект нужно делать срочно. Или мне так казалось, а на самом деле я просто не попросила ресурсы.

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

Все свои роли я выполняла добросовестно. Даже не имея компетенций в каких-то вопросах, старалась быстро во всём разобраться:

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

  • В роли бизнес-аналитика проводила интервью, писала ТЗ и взаимодействовала с командой разработки.
  • В роли руководителя проекта вела проектную документацию, взаимодействовала со спонсором и командой.

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

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

Почти fail: проект тянулся бесконечно и начался заново

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

Заказчиком всё ещё являлась я. Времени совсем не хватало, падало качество, работа велась в режиме 24/7. Поняла, что так не может продолжаться, и пошла к спонсору. Мы договорились о передаче проекта в другое ответственное подразделение.

И тут началось. Ответственный никогда не видел и не согласовывал ТЗ. А сейчас, когда всё реализовано, он не согласен с тем, как работает проект, ему кажется, что нужно было сделать по-другому, ему не удобно использовать текущие инструменты, появляются запросы на изменения.

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

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

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

Выводы

Из этого опыта я извлекла два главных урока:

  1. Все проекты — это прежде всего проекты компании. Они направлены на достижение целей бизнеса и нужны не только мне, поэтому все необходимые ресурсы должны быть.
  2. Даже если кажется, что ресурсов действительно нет и все заняты другими проектами, а сроки поджимают и будет быстрее, если я всё сделаю сама, — смотри пункт 1.

Каждый должен заниматься своим делом, а

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

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

Как быть новичку? Кейс разбирает Дима Ильенков

Привет! Я Дима, основатель онлайн-школы для проектных и продуктовых менеджеров PMCLUB. Кратко разберу историю нашей ученицы Кристины и дам несколько советов.

Можно ли избежать завалов на первом проекте?

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

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

Берите на себя ответственность за успех коммуникаций со спонсором и заказчиком.

Самое плохое — не извлекать уроков

Проблема не в том, что проектный менеджер что-то делает за других, а в том, что он решает за других. Если посмотреть на табличку Кристины, то больше половины ролей (спонсор, заказчик, тимлид) — это не про «делать», а про «думать».

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

Почему брать на себя всё — не ок?

Причин полно:

  • Быстро приходит выгорание. Проектные принципы NUPP говорят, что стоит беречь энергию и силы, чтобы принимать правильные решения.
  • ПМ может неправильно понять и передать требования. В итоге команда создаст не тот продукт, который нужен.
  • Не будет полноценного вовлечения в проект, так как проджект будет занят «перепрыгиванием» с роли на роль.
  • Проектный менеджер может лишиться поддержки и всех шорткатов. Например, отдельный заказчик мог бы помочь выделить ресурсы, а спонсор — дать новых людей в команду или найти экспертов, которые помогут разобраться в проблеме. Взяв все роли на себя, ПМ останется без помощи.
  • Менеджер упустит карьерные возможности. Например, в большой команде ПМ регулярно общается со спонсорами и заказчиками, показывает им свою работу и результаты. Это быстро приводит к росту.
  • Также когда ПМ берёт на себя много ролей, он проецирует эту модель и на команду: либо сам начинает что-то делать за сотрудников, либо ожидает, что они подумают за него.

Что делать?

Запуская проект, первым делом назначайте спонсора, а после — ключевых членов команды. Так, например, советует фреймворк p3express. Обозначьте заказчику важность ролей, а уже после переходите планированию.

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

PMCLUB — онлайн-школа для менеджеров проектов и продуктов. Мы учим управлять проектами и не срывать дедлайны, правильно оценивать сроки, риски и бюджет. Подписывайтесь на нас на vc.ru и в Telegram.

20
4 комментария