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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выводы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что делать?

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

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

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

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

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

1
Ответить

Тогда и ценник в космос на такие требования;) ну а как , из проектного треугольника не выбраться по-другому

1
Ответить

Отличная статья! Спасибо!

1
Ответить

Комментарий недоступен

Ответить