Привет, Хабр!

Меня зовут Кристина Спирина, я руководитель проектов в IT.

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

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

Для начала расскажу немного о своем опыте. В IT-сфере я работаю уже около 13 лет. Раньше я была аналитиком, но в последние 9 лет занимаюсь именно проектной деятельностью. Вместе с командой мы создали дистанционное банковское обслуживание Рязанскому банку, а сейчас я помогаю растить талантливых молодых руководителей проектов. Большую часть времени я занимаюсь проектами корпоративных рисков. Это несколько проектов по импортозамещению и программа по переходу банка на ПВР (продвинутый способ оценки кредитных рисков).

Старт проекта

Ничего не понятно, но очень интересно

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

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

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

Третье, узнать команду, чтобы знать, к кому идти с нужными вопросами.

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

Планирование

План – это уже половина успеха

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

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

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

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

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

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

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

Также в бюджете вспоминаем, что раз в год сотрудники могут прийти за повышением. Закладываем буфер на повышение. Закладываем буфер на проектную премию в конце проекта, если у вас в практике это присутствует.

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

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

Совет. Я рекомендую закладывать +15% как на бюджет, так и на длительность работ, чтобы в случае, если что-то пойдет не так или ключевой сотрудник заболеет/уволится, в проекте сразу не возник сдвиг финального срока или превышение бюджета. Также бывают ситуации, что все-таки мы что-то забыли при первоначальном планировании.

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

Основные отличия риска от проблемы:

• риск – это событие, которое может случиться в будущем и может привести к определенным потерям (снижению качества продукта, перерасходованию бюджета, задержке сроков либо полной неудаче проекта);

• проблема же – это событие, которое уже случилось. Риски превращаются в проблемы, если с ними не работать.

  

Совет. Если ты только начинаешь заниматься управлением проекта, обязательно делай эту табличку, привлекай команду для ее составления, периодически обращайся к ней, чтобы смотреть, реализовались ли каки-либо риски. Более опытные РП эту табличку держат в голове.

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

Исполнение

Полное погружение

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

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

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

Тебя команда в основном воспринимает как спасителя, помощника и, действительно, может к тебе прийти с любой проблемой и без решения – и это нормально. Твоя задача — им помочь и направить.
Хвали команду даже за маленькие успехи. Даже простое слово «молодец» всегда мотивирует делать больше.

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

Совет. Я назначаю встречу, тем самым выделяю их время на мою задачу, и мы совместно по ней идем.

Контроль

Шеф, все под контролем!

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

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

Совет. Обычно я использую такую структуру презентации:

• бюджет, что мы потратили

• сколько еще осталось

• дорожная карта

• верхний уровень всего проекта

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

• и поручения с прошлого статуса.

Когда на проекте возникает проблема, лучше прийти к заказчику и сказать об этом сразу, чем оправдываться в конце проекта, почему мы чего-то не смогли. Бывает, что руководители проекта иногда боятся говорить о своих проблемах и пытаются спасать ситуацию и решать что-то самостоятельно. Да, это иногда получается, но успешных кейсов не так уж и много.
Поэтому лучше честно прийти к заказчику, признаться, что да, у нас произошла проблема в проекте. Сразу предложить несколько вариантов решения с оценкой плюсов и минусов, и заказчик уже выберет конечный вариант. Также очень важно вести протоколы. Особое значение это приобретает, когда заказчики склонны часто отказываться от своих решений, когда им это выгодно. Протоколы лучше вести в общедоступном месте для того, чтобы, если ты ушел в отпуск или, вдруг, заболел, то подменяющий тебя сотрудник, спокойно смог найти необходимую информацию. И в целом общую информацию по проекту я рекомендую также хранить в общедоступном месте. Я использую для этого страницу в Confluence с определенной структурой. Мы отображаем информацию по команде проекта, в том числе, и по команде со стороны заказчика. Например, основные артефакты, это могут быть бизнес-требования, архитектурные решения, презентации, презентации со статусов с заказчиком, план-график. Отдельно храним только бюджет, потому что эта информация не для всех.

Завершение

Мы команда

Итак, мы подошли к завершению проекта, все проекты когда-то заканчиваются.
И тут самое главное — поддержи команду. Мы выкатываем последние релизы, за это отвечают IT-лидеры, тех-лидеры, и руководители проекта – иногда от этого отстраняются. Но даже тех-лидеру нужна поддержка.

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

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

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

Пример. У меня бывало, что я с одной и той же командой я делала два проекта. Они были в разное время и дружеская нота помогла нам успешно завершить и второй проект тоже.
Ну и как говорится, мир IT – круглый, мы все еще встретимся в новом проекте.

Совет начинающим

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

Методологии

• Waterfall (Водопад)

• Agile

• Scrum

• Канбан

• Методология рационального управления (Lean)

• Экстремальное программирование (XP)

Более подробно можно почитать здесь: про методологии проектного управления .

Также есть стандарты, которые описывают данные подходы.

• Стандарт PMI PMBOK® 7 (2021)

• PRINCE2® 7 Managing Successful Projects» (2023)

• Agile Practice Guide (2017)

• The Real Scrum Guide (2024)

• ГОСТ Р 54869-2011 «Проектный менеджмент. Требования к управлению проектом» (2011)

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

Если ты только начинаешь заниматься проектным управлением или хочешь перейти в это направление, то я бы точно не советовала читать PMBOK, как минимум, потому что там 700 страниц, и это точно не книга для легкого чтения на ночь. Обычно PMBOK используют или как углубление своих знаний в определенной области, или при подготовке к сертификации.
Сейчас актуальная 7-я редакция, которая, на мой взгляд, только всех запутала. Рекомендую начать прочтение с 6-ой редакции.

Как первую книгу для прочтения я бы посоветовала – «Deadline, роман об управлении проектами». Том Демарко прошелся по всем этапам жизненного цикла проекта: от формирования команды до сдачи результатов. Книгу легко читать, так как она написана в стиле бизнес-романа.

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