Заметки руководителя проекта: советы начинающим, факапы для бывалых
Привет, Хабр!
Меня зовут Кристина Спирина, я руководитель проектов в IT.
Сегодня мы пройдем по жизненному циклу проекта, на каждом этапе поговорим о важных моментах, о факапах, с которыми мы с командой сталкивались на практике, и о том, как мы их исправляли.
В своей работе я опираюсь в основном на стандарт PMBOOK, но есть и другие альтернативные подходы к проектному управлению. В конце статьи я о них расскажу, а также дам информацию о том, с чего же начать свой путь в проектном управлении.
Для начала расскажу немного о своем опыте. В IT-сфере я работаю уже около 13 лет. Раньше я была аналитиком, но в последние 9 лет занимаюсь именно проектной деятельностью. Вместе с командой мы создали дистанционное банковское обслуживание Рязанскому банку, а сейчас я помогаю растить талантливых молодых руководителей проектов. Большую часть времени я занимаюсь проектами корпоративных рисков. Это несколько проектов по импортозамещению и программа по переходу банка на ПВР (продвинутый способ оценки кредитных рисков).
Старт проекта
Ничего не понятно, но очень интересно
Итак, тебе дали новый проект. Пока очень интересно и ничего не понятно, с чего же к нему приступить?
Первое, надо изучить бизнес-задачу заказчика. Что же он хочет получить в итоге? Какая у нас цель проекта? Какой продукт мы создаем в рамках проекта?
Если по проекту уже есть какая-то документация или бизнес-требования, например, архитектурное решение, его также надо изучить.
Второе, познакомиться с заказчиком и со стейкхолдерами. Это заинтересованные лица, которые могут выставлять требования к проекту, и использовать конечный результат нашего проекта.
Третье, узнать команду, чтобы знать, к кому идти с нужными вопросами.
Пример. В моей практике был кейс, когда я пришла на проект уже на этапе реализации и не проверила скоуп проекта на полноту. На этапе приемки оказалось, что мы реализовали всего лишь 70% нужного функционала, а 30% не было ни в договоре подрядчика, ни у внутренней команды, хотя этот договор согласовывал заказчик и аналитик с его стороны. Поэтому важно, даже если ты пришел на проект не на старте, убедиться, что коллеги ничего не забыли и все включили в скоуп проекта.
Планирование
План — это уже половина успеха
Планирование — важный этап.
Первое — мы определяем скоуп работ проекта, определяем, какие ресурсы нам нужны. Если нужны дополнительные ресурсы, которых у нас нет, мы идем в подбор.
Тут самое важное — не забыть про смежные команды, про их работы, не забыть про инфраструктуру и, конечно же, не забыть про информационную безопасность, о которой в последнее время часто забывают.
После того, как мы определили работы, которые нам нужно выполнить, их нужно оценить.
Совет. Оценивать должен конечный исполнитель. Даже если ты работал разработчиком, аналитиком и вообще лучше всех все знаешь. Правильную оценку тебе даст только конечный исполнитель. Но если ты, вдруг, все-таки взял это на себя и выполнил оценку самостоятельно, обязательно подтверди ее с исполнителем. Если оценка не будет уточнена с исполнителем, а ты ошибся и в дальнейшем работы будут выполняться дольше, то это повлияет как на сдвиг срока проекта, так и на увеличение бюджета проекта.
Теперь можем приступать к формированию плана-графика.
Здесь важно не забывать, что все ходят в отпуска.
Так же помним о моменте, связанным с инфраструктурой — доставка оборудования сейчас очень затягивается. Если в лучшие годы доставка сервера могла составить два месяца, то сейчас у меня на практике может достигать до шести месяцев.
Пример. Однажды мы не заложились на долгий срок поставки, решили, что сервер придет через два месяца. Раньше же так приходил. И когда уже начались работы по развертыванию стенда, оказалось, что железа у нас еще нет.
Но мы пошли к инфраструктуре, попросили у них что-то из запасов для того, чтобы собрать наш сервер. Хорошо, что запасы у них были. Таким образом, сдвига по работам не произошло.
Но в запасах не всегда может оказаться то, что вам нужно.
Также в плане-графике нужно будет учесть обязательно подбор. Причем время на поиск специалистов тоже разный, и зависит от того, кого мы ищем. Сейчас подбор может достигать от трех и до шести месяцев. Точные сроки сможет сказать HR в зависимости от классификации искомого специалиста.
После этих шагов мы уже можем сформировать бюджет.
Первое, помним про бюджет на смежные команды. Очень часто, в рамках проекта работает несколько команд, и бюджет на них тоже потребуется.
Дальше не забываем про инфраструктуру — железо стоит денег.
Не забываем про информационную безопасность, потому что в последнее время их меры стали платными.
Пример. У меня планирование будущих проектов наступает в августе. И при планировании мы, конечно же, не сходили к информационной безопасности, не рассказали о том, что у нас намечается новый проект, и поэтому в бюджете это не учли. А в январе, когда уже было утверждение проекта, коллеги пришли к нам и выставили счет на свои работы. Но нам повезло, что такая ситуация произошла не только в одном проекте, и получилось договориться, что финансирование будет не за счет проектной деятельности, а за счет бюджета информационной безопасности. Но так везет не всегда. Поэтому про безопасников не забываем.
Также в бюджете вспоминаем, что раз в год сотрудники могут прийти за повышением. Закладываем буфер на повышение. Закладываем буфер на проектную премию в конце проекта, если у вас в практике это присутствует.
Пример. Сейчас у меня нет возможности заложить буфер в бюджет на повышение или проектную премию, потому что правила формирования бюджета у нас жестко диктует проектный офис, и мы формируем бюджет на основании текущих ставок команды. Но если в проекте есть подбор, то я могу выйти из этой ситуации таким образом: закладываю максимальную ставку по рынку. И в случае, если мы подбираем сотрудника чуть дешевле, то у меня формируется буфер на повышение или, возможно, даже проектную премию.
Для формирования плана-графика и бюджета в основном используется такой инструмент, как Microsoft Project. Он позволяет пошагово детализировать проект, произвести бюджетный расчет, отслеживать процесс реализации этапов проекта и строить дорожную карту по верхам проекта, который мы в дальнейшем можем показать нашему заказчику.
Совет. Я рекомендую закладывать +15% как на бюджет, так и на длительность работ, чтобы в случае, если что-то пойдет не так или ключевой сотрудник заболеет/уволится, в проекте сразу не возник сдвиг финального срока или превышение бюджета. Также бывают ситуации, что все-таки мы что-то забыли при первоначальном планировании.
И еще один очень нужный инструмент — это реестр рисков. Чтобы не забыть все важные моменты, я советую формировать его на начальном этапе. В него ходит описание всех видов опасностей, которые у нас могут возникнуть, их возможные последствия и мероприятия по предупреждению, снижению и обработке рисков.
В проекте могут быть и проблемы, и риски.
Основные отличия риска от проблемы:
риск — это событие, которое может случиться в будущем и может привести к определенным потерям (снижению качества продукта, перерасходованию бюджета, задержке сроков либо полной неудаче проекта);
проблема же — это событие, которое уже случилось. Риски превращаются в проблемы, если с ними не работать.
Пример реестра рисков по стандарту PRINCE2
Совет. Если ты только начинаешь заниматься управлением проекта, обязательно делай эту табличку, привлекай команду для ее составления, периодически обращайся к ней, чтобы смотреть, реализовались ли каки-либо риски. Более опытные РП эту табличку держат в голове.
Ну и помни, что ты не один, у тебя все-таки есть команда, и когда ты сформировал планы и бюджет, сверься с ними. В основном я хожу за подтверждением к IT-лидерам или тех-лидерам. Одна голова хорошо, а несколько — лучше.
Исполнение
Полное погружение
Дальше мы переходим уже к самому интересному — к исполнению проекта.
Здесь самое главное — запланировать рабочие встречи с командой и заказчиком.
Совет. Я рекомендую, регулярные встречи в одно и то же время, чтобы в проекте был порядок.
Каждая задача должна быть понятна. Как исполнителю, так и руководителю проекта. То есть ты как руководитель проекта не можешь думать про задачи «ну команда там что-то делает и ладно». Нет, ты должен понимать, зачем мы эту задачу делаем, зачем мы делаем ее на этом этапе, как мы ее в дальнейшем будем использовать. И также задача должна ставиться исполнителю по SMART, то есть она должна быть конкретна, измерима, достижима, актуальна и ограничена во времени.
Тебя команда в основном воспринимает как спасителя, помощника и, действительно, может к тебе прийти с любой проблемой и без решения — и это нормально. Твоя задача — им помочь и направить.
Хвали команду даже за маленькие успехи. Даже простое слово «молодец» всегда мотивирует делать больше.
Мой опыт коммуникации с командой или с отдельными сотрудниками показывает, что иногда лучше созвониться, чем целый день переписываться. Потому что текст может быть воспринят неправильно, а на звонке можно проще и быстрее обсудить проблему. Это же правило я использую при взаимодействии с IT-лидерами и тех-лидерами, потому что из-за своей большой нагрузки они фоном мою задачу сделают никогда или очень нескоро.
Совет. Я назначаю встречу, тем самым выделяю их время на мою задачу, и мы совместно по ней идем.
Контроль
Шеф, все под контролем!
Важность контроля в управлении проектами сложно переоценить.
Контроль осуществляется, как и на уровне заказчиков, так и на уровне команды. Для того, чтобы твоя задача была выполнена в срок, приди к исполнителю за несколько дней до. Тем самым ты повысишь шанс, что человек вспомнит про твою задачу, выполнит ее, и никакого сдвига по срокам не случится.
Помним, что большинство заказчиков — визуалы, они любят красивые картинки, и вряд ли им будет понятен план из MS Project. Поэтому для них составляем красивую презентацию с основными моментами.
Совет. Обычно я использую такую структуру презентации:
бюджет, что мы потратили
сколько еще осталось
дорожная карта
верхний уровень всего проекта
детализация конкретного этапа, на котором мы сейчас находимся, со статусом работ, проблемами и рисками, если нам нужно обсудить
и поручения с прошлого статуса.
Когда на проекте возникает проблема, лучше прийти к заказчику и сказать об этом сразу, чем оправдываться в конце проекта, почему мы чего-то не смогли. Бывает, что руководители проекта иногда боятся говорить о своих проблемах и пытаются спасать ситуацию и решать что-то самостоятельно. Да, это иногда получается, но успешных кейсов не так уж и много.
Поэтому лучше честно прийти к заказчику, признаться, что да, у нас произошла проблема в проекте. Сразу предложить несколько вариантов решения с оценкой плюсов и минусов, и заказчик уже выберет конечный вариант. Также очень важно вести протоколы. Особое значение это приобретает, когда заказчики склонны часто отказываться от своих решений, когда им это выгодно. Протоколы лучше вести в общедоступном месте для того, чтобы, если ты ушел в отпуск или, вдруг, заболел, то подменяющий тебя сотрудник, спокойно смог найти необходимую информацию. И в целом общую информацию по проекту я рекомендую также хранить в общедоступном месте. Я использую для этого страницу в Confluence с определенной структурой. Мы отображаем информацию по команде проекта, в том числе, и по команде со стороны заказчика. Например, основные артефакты, это могут быть бизнес-требования, архитектурные решения, презентации, презентации со статусов с заказчиком, план-график. Отдельно храним только бюджет, потому что эта информация не для всех.
Завершение
Мы команда
Итак, мы подошли к завершению проекта, все проекты когда-то заканчиваются.
И тут самое главное — поддержи команду. Мы выкатываем последние релизы, за это отвечают IT-лидеры, тех-лидеры, и руководители проекта — иногда от этого отстраняются. Но даже тех-лидеру нужна поддержка.
Пример. Недавно мы выкатывали релиз, и у нас должна была быть установка за один день. Все, конечно же, пошло не по плану, пришлось поработать и второй день. И для тех лидера были важны мои слова поддержки о том, что заказчикам мы все объясним, и ничего страшного, и второй день нам всем тоже оплатят.
Помимо прочего на статусе с заказчиком подсвечивай победы команды, потому что зачастую они думают, что это наша обычная работа, и она не стоит благодарности. Приучайте заказчиков говорить спасибо.
Приятный момент в завершении проекта — это проектная премия. И ты как руководитель проекта должен пойти к заказчику и обосновать ему денежное «спасибо». В первую очередь я прошу за команду, ну, а мне это уже может достаться как приятный бонус.
И помните, что команда — это навсегда. Очень часто после завершения проекта команда трансформируется в команду поддержки и развития продукта, и руководитель проекта от нее отходит. Но, всегда будь открыт, если команда придет к тебе с какими-то вопросами — помоги. Потому что вы все можете встретиться в новом проекте, возможно, даже в разных компаниях, и твоя отзывчивость будет тебе плюсом.
Пример. У меня бывало, что я с одной и той же командой я делала два проекта. Они были в разное время и дружеская нота помогла нам успешно завершить и второй проект тоже.
Ну и как говорится, мир IT — круглый, мы все еще встретимся в новом проекте.
Совет начинающим
Мы рассмотрели, как выглядит проект от инициации до завершения, какие бывают проблемы, и на что следует обратить внимание.
Давайте посмотрим, какие методологии управления существует, здесь я привела основные, на самом деле их намного больше.
Чаще всего в реальной практике управления используется симбиоз подходов.
Методологии
Waterfall (Водопад)
Agile
Scrum
Канбан
Методология рационального управления (Lean)
Экстремальное программирование (XP)
Более подробно можно почитать здесь: про методологии проектного управления .
Также есть стандарты, которые описывают данные подходы.
Документация про проектное управление в основном на английском языке, но в интернете можно найти достойный русский перевод.
Если ты только начинаешь заниматься проектным управлением или хочешь перейти в это направление, то я бы точно не советовала читать PMBOK, как минимум, потому что там 700 страниц, и это точно не книга для легкого чтения на ночь. Обычно PMBOK используют или как углубление своих знаний в определенной области, или при подготовке к сертификации.
Сейчас актуальная 7-я редакция, которая, на мой взгляд, только всех запутала. Рекомендую начать прочтение с 6-ой редакции.
Как первую книгу для прочтения я бы посоветовала — «Deadline, роман об управлении проектами». Том Демарко прошелся по всем этапам жизненного цикла проекта: от формирования команды до сдачи результатов. Книгу легко читать, так как она написана в стиле бизнес-романа.
На этом у меня все, спасибо за внимание. Если у тебя есть интересный кейс или нужен какой-то совет по работе — я всегда открыта к общению.
