Менеджер проекта: что делать, если вам вручили белую каску
Иногда в жизни бывает так — вам вручают белую каску менеджера вместо привычной оранжевой или синей каски исполнителя и говорят: «Теперь ты — руководитель проекта. На тебя вся надежда». Что делать, если при этом вы не изучали, например, PMBoK (Project Management Body of Knowledge, свод знаний по управлению проектами)? Вы могли в них участвовать, но отвечали за функционал и делали работу руками. Как пересесть в другое кресло и вжиться в иную роль, по возможности гася в себе синдром самозванца?
В ЛАНИТ мы выполнили тысячи различных проектов — внутренних, внешних, с различными видами контрактов и оплат, сервисных и строительных, связанных с привлечением десятков субподрядчиков. Персонально я когда-то тоже получил белую каску — управлял внедрением ERP-систем, руководил отделом консалтинга, вел международные и локальные проекты. Так что сегодня дам несколько, надеюсь, полезных советов.
Экзистенциальное
Современное управление постепенно переходит от иерархических структур к сетевым. Координация деятельности при выполнении внутренних и внешних проектов — это как раз проявление такой тенденции. При этом члены вашей команды не подчиняются вам функционально, но работают под вашим руководством на конкретном коммерческом проекте. Компания получает доход именно за счет коммерческих проектов. Так что первое, что нужно сделать — это почувствовать, что вы — полновластный руководитель. Если вы не будете управлять, то и люди, и результаты могут пойти не туда. Например, кто-то откровенно ленится, некоторые пытаются реализовать своё любопытство и интерес в своей профессиональной области. Иные делают слишком много — пишут чересчур детальную документацию, немало времени уделяют тем вопросам, за которые заказчик не хочет платить.
Проект определяется как деятельность с уникальным результатом. Но строительство типового дома — тоже проект, хотя таких зданий может построено несколько сотен. Только внешние обстоятельства — место и время — делают этот проект уникальным.
Если вы ничего не знаете об управлении проектами, не бросайтесь читать стандарты — вы только потратите силы без хорошего результата. Постарайтесь заручиться поддержкой и добрыми советами от знакомого опытного менеджера. Это принесет гораздо больше пользы.
Еще одна ремарка: менеджер проектов — это не должность сама в себе. Есть профессиональные управленцы, но ценнее те, которые выросли из некоторой функциональной (предметной) области. Они могут более аргументировано координировать выполнение задач, направлять в нужное русло ожидания заказчика, уверенно коммуницировать с исполнителями, находить более правильные решения по построению структуры проекта. Так что не пасуйте перед матерыми управленцами. Их конек — водить руками, ваш — функциональные знания.
Не переживайте по поводу отсутствия опыта. Вспомните, что, к примеру, PMI (Project Management Institute, мировой лидер в стандартизации и сертификации профессионалов в управлении проектами) не даст удостоверение PMP, если у вас нет подтвержденной практики не менее 4500 часов. А это, на секундочку, чуть более двух рабочих лет. То есть нельзя получить подтверждающий ваш уровень сертификат без практики управления реальными, а не учебными проектами.
Кадр из к/ф «Золотой теленок»
«Золотой теленок» Ильфа и Петрова начинается фразой: «Переходя улицу, оглянись по сторонам (правило уличного движения)». Используйте этот мудрый совет и не ныряйте в проект сразу. Даже если его усиленно навязывают. Радость от статуса и нового цвета каски может затмить реальные особенности проекта — недостаточное количество исполнителей, невыполнимая задача и множество неопределенностей. Иногда лучше отказаться, чем соглашаться на утопическое. В противном случае вам нужно требовать карт-бланш у тех, кто торжественно вручает вам задачу.
Вместе с тем, проект на то и проект, чтобы в нем оставалась доля неопределенности. Она может и должна быть перекрыта готовностью к риску и некоторым налётом авантюризма в вашем характере, стремлением побеждать и решать проблемы.
Коммуникация
Второе чувство или модель поведения, которую вы должны себе привить — это возможность, способность и необходимость коммуницировать. Подключим образность. Менеджер проекта является ядром, центром нервной системы, а ваши исполнители (внутренние или внешние) — это дендриты и аксоны (нервные окончания). Вы не можете быть в курсе обо всем в проекте, не являетесь глобальным носителем функциональных знаний, используемых в нем. Однако вы являетесь хранителем ключевой информации о результатах, структуре, существе, показателях и участниках проекта. Мир не познаваем, но вы в центре паутины и тянете за нужные веревочки, чтобы все становилось более прозрачным, понятным и результативным.
Общение с исполнителями и заказчиком — это не B2B (взаимодействие бизнесов) или HR (управление сотрудниками). Это H2H (Human-to-Human) взаимодействие конкретных людей. С одной стороны, при всей жесткости работы менеджер проекта должен обладать эмпатией — уметь и стремиться нравиться заказчику, доброжелательно и конструктивно говорить с сотрудниками, находить компромиссы, выслушивать беспокойства. При этом сделать так, чтобы ваши коллеги захотели поделиться переживаниями именно с вами.
Если вам поручен внешний проект, зачастую в него активно вовлекается заказчик. Например, при внедрении программных систем он должен сформулировать бизнес-требования, затем протестировать решение, научиться и начать работать с ним. Несмотря на то, что он платит деньги, а вы менеджер проекта исполнителя, вы должны влиять на клиента. Определять, что нужно сделать его представителям, управлять его ожиданиями (иногда нужно говорить твердое «нет»), проявлять собственную экспертизу и четко пояснять, как должна выглядеть целевая система.
За это заказчик вас любит, хоть может и сопротивляться. Но это лучше, чем работать в стиле «чего изволите». Однако помните, что прививание культуры и обучение всегда связаны с некоторой долей давления — где-то вам придется проявлять твердость характера. При этом не жестите, но и не будьте как пластилин, или еще хуже — слайм или «лизун».
Если вы интроверт, то вам возможно будет сложнее строить спонтанные коммуникации между участниками. Но у вас есть другая сильная сторона — вдумчивость. Это означает, что вы, к примеру, сможете сформировать план коммуникаций, и четко следовать ему. Это существенно упростит вам жизнь.
Вначале проекта познакомьтесь со всеми, кто в него вовлечен с вашей стороны и со стороны заказчика (стейкхолдерами). Вас должны знать и четко понимать, что менеджер проекта — это вы. С ключевыми людьми назначьте персональную или групповую встречу для представления и определения ближайших планов: что будете делать вы, исполнители и заказчики. Определите, когда и как часто к вам можно обращаться. Расскажите, что вы ожидаете от участников встречи. Остальным участникам вы можете отправить письмо вежливости.
От заказчика также должен быть назначен менеджер проекта. Это — один конкретный человек, а не группа людей. Роль менеджера не должна превращаться в переходящее знамя. Вам нужен тот, кто отвечает со стороны заказчика за свой персонал, приемку работ, ресурсы, согласование задач. Очень желательно, чтобы раз в неделю (в идеале) вы с ним встречались и обсуждали статус проекта: что сделано за предыдущие семь дней, что будет сделано в последующие, в графике ли вы, какие изменение и риски возникают. Своему руководству должен отчитываться именно он — менеджер проекта заказчика. В крайнем случае, это должен быть совместный доклад.
Знайте, что руководитель проекта со стороны клиента также отвечает за успешность его реализации. Зачастую даже больше, чем вы. Потому что с точки зрения заказчика, исполнителя можно и поменять, а задачи останутся, и ответственный за них внутри компании-заказчика тоже останется. Поэтому не противопоставляйте себя друг другу, не культивируйте взаимное недовольство из-за возможных неудач или завышенных требований (в разумных пределах, разумеется).
От вас могут не ждать чётко запланированных периодических встреч, или даже будут им противиться. Вам могут сказать: «Когда сделаете, тогда и приходите». Но не соглашайтесь, не прячьте голову в песок, коммуникация — это важно и нужно. Даже если у вас нет явных результатов по проекту, необходимо встретиться, чтобы подтвердить, что процесс продолжается. Пусть даже в неактивной фазе или на этапе согласования и переноса сроков. Заказчик должен знать об этом, а вы выходите с открытым забралом.
Планирование
Третьим шагом после установления коммуникации является планирование. Вы можете не знать всех глубинных деталей проекта, но должны и обязаны иметь всю информацию по группе задач.
Сначала запишите всё, что вам известно в любой последовательности. Затем создайте структуру. Как ее выстроить и как описывать задачи?
На проекте обычно работает больше одного человека, поэтому задачи обычно выполняются параллельно. Также к ним привязываются исполнители и ресурсы (материалы, машины и пр.). Задачи надо именовать на основе результатов («поклеенная плитка на кухне»), а не ресурсов («плитка») и не работ («поклеить плитку»). Последовательность может строиться как угодно, но, как я думаю, лучше делать это:
по логической последовательности выполнения задач (или зависимости их выполнения),
по важности,
по очередности сдачи задач заказчику.
Детальность планирования задач — ещё один дискуссионный вопрос. Верхнеуровневое планирование основывается на этапах работ, то есть на получении промежуточных результатов. Масштаб разбивки на эти этапы, по моему мнению, должен быть в соотношении 5–10% от всего проекта.
Я предпочитаю планировать работы так, чтобы было легко увидеть результаты от реализации задачи каждым исполнителем в период от трех до семи дней. Мельчить вредно, крупнить тоже. При этом уверен, что можно добавлять и небольшие задачи, если они являются важными и должны быть отражены в проекте.
Также необходимо добавлять в план так называемые milestones (на русский язык обычно переводится на старославянский манер «веха»). Это точки на маршруте проекта, где нужно остановиться и оглядеться вокруг. Они характеризуют важный переходный этап с фазы на фазу.
После того, как вы выполните планирование на высоком уровне, попросите сделать детальное планирование ваших исполнителей по их собственным задачам.
Если вы в состоянии сами спланировать задачи более подробно, то попросите сотрудников проверить этот порядок действий на правильность структуры и оценок. В любом случае, это стоит сделать и на завершающем этапе планирования, чтобы каждый проанализировал общие предстоящие задачи, а не только свои собственные. Лишняя проверка не помешает. Но финальное решение по оценкам принимаете эксклюзивно только вы.
Учет фактически выполненных задач
Как оценивать процент и процесс исполнения задач? Есть несколько подходов.
При начале задачи, т. е. её передачи исполнителю, вы проставляете завершенность 50%. При её исполнении — 100%.
При начале задачи — 33%, в течение исполнения — 66%, при завершении — 100%.
Пропорции — 25%, 50%, 75%, 100% в зависимости от статуса задачи. Он может оцениваться по продолжительности исполнения, по затраченным ресурсам (материалам), по оценке результата (если результат измерим количественно).
Поскольку у вас есть план и факт, то вы сопоставляете эти два показателя. Для начала просто сравнивайте — насколько вы отстаёте по датам от выполнения задач по намеченному перечню.
Затем, когда вы освоитесь с этим, можно будет уже применять такие метрики из PMBoK, как BAC (Budget at Completion) — бюджет по завершении, EAC (Estimate at Completion) — прогноз по завершении, VAC (Variance at Completion) — отклонение по завершении, CV (Cost Variance) — отклонение по стоимости, PV (Planned Value) — плановый объем и другие.
На начальном этапе о них не нужно думать. Вы углубитесь в расчёты и формирование их методологии, потеряв время.
Различия факта и плана можно вести по группам задач, по ресурсам, по исполнителям. Это позволит вам скорректировать оценки на остаток проекта при его пересмотре.
Риски
Риски — это такие непредвиденные обстоятельства, более или менее вероятные, которые обычно негативно влияют на проект. Риски компенсируются деньгами, временем либо другими ресурсами.
Думайте о рисках, но в разумной степени — проработка реакции на любой риск (например, если от вас уходит ключевой сотрудник) требует большого количества времени. При его малой вероятности это время, которое будет потрачено зря.
Качество и согласование результатов с заказчиком
Качество может портиться в процессе производства продукта. Поэтому контролировать стандарты нужно постоянно, а не когда продукт уже готов. Аналогично с ожиданиями заказчиков — чтобы чего-то не упустить, необходимо периодически демонстрировать результат. Не забывайте вносить такие задачи и встречи с клиентом в план проекта. Итоги должны быть подтверждены заказчиком в виде принятого документа.
При создании программных продуктов, прежде чем перевести код разработчика в общую ветку, другой разработчик должен сделать валидацию (review) этого кода и подтвердить его достаточное качество. Эта практика может быть также применена в других отраслях. Поясните исполнителям, что это не признак недоверия — это:
стремление использовать общепринятые практики (например, рубрикацию документации, подход к проектированию, именование объектов),
вовлечение нескольких людей к задачам, то есть кросс-коммуникация,
формальные требования.
Создание отдела контроля качества как отдельной структуры, возможно, и имеет смысл. Но иногда это подразделение имеет ключевой показатель по выявлению недостатков. Поэтому в какой-то момент это звено может просто тормозить весь производственный процесс.
Работа с исполнителями
Распределять задачи и держать руку на пульсе во время их реализации — ваша важнейшая миссия. Хорошая практика — это ежедневные короткие встречи (daily meetings) на 5–10–15 минут с исполнителями или участниками проекта (их должно быть не более 10–15). Во время этих небольших совещаний они рассказывают:
что сделали за предыдущий день (детальные обсуждения выносятся на отдельную встречу по подведению итогов и анализу ретроспективы выполненных задач),
какие у них планы в ближайшей перспективе по назначенным для них задачам,
о возникших сложностях и ограничениях (длинные обсуждения выносятся на отдельные встречи).
Также во время этих планерок осуществляется быстрое назначение задач (детальное назначение задач выносится на отдельные встречи).
Причин для того, чтобы проводить daily meetings несколько. Во-первых, встреча короткая, поэтому ни у кого не отнимает существенного времени. Во-вторых, вы получаете наиболее актуальную информацию о течении проекта. В-третьих, другие его участники понимают, что происходит рядом с ними — не возникает информационного вакуума. Часто завязывается дискуссия, которая похожа на мозговой штурм, что тоже эффективнее, чем когда каждый решает собственную задачу, не зная, где получить помощь или с кем посоветоваться.
Управление изменениями
Проект — это живая ткань, поэтому процесс его выполнения может корректироваться и не всегда в меньшую сторону. В планы каждого из этапов нужно закладывать риски недооценки, усложнения, потребности в дополнительных изменениях, тестировании, документировании.
При ведении проектов с фиксированной стоимостью также закладывают рабочие часы на разнообразные риски (contingency risks). Зачастую они составляют 50% от затрат.
Если вы думаете, что это много, то это не так. Взгляните, скажем, на рост стоимости проектов олимпийских и футбольных стадионов.
Например, Национальный стадион Бразилии им. Манэ Гарринчи — 900 млн долларов США против проектных 300 млн долларов США.
Мерседес-Бенц Стадиум, Атланта, США — 1,6 млрд долларов США против проектных 1,2 млрд долларов США.
Газпром Арена, СПб, Россия — 43 млрд рублей против проектных 6,7 млрд рублей.
Контролируйте задачи, чтобы сам проект не расползался (для этого и нужны ежедневные встречи с исполнителями), и держался в тех рамках, как вы определили и изначально согласовывали с заказчиком. При этом, как бы мы не страховали риски, задачи часто становятся более обширными, чем мы планировали себе. Ведь энтропия (мера беспорядка, хаоса, степень неопределенности) растет и она так выражается в проекте.
Однажды наступает момент, когда вам нужно сделать следующее.
Сказать заказчику, что задачи, о выполнении которых он просит, выходят за рамки запланированных. Поэтому бюджет проекта должен быть расширен, либо предлагаемые задачи не должны выполняться.
Сказать заказчику, что изначально запланированные задачи требуют обоснованного расширения бюджета.
Эти утверждения нужно подкреплять практическими примерами и аргументами. Будет хорошо, если вы к такому разговору подключите ключевых исполнителей, которые смогут подтвердить ваши слова. Обычно это неприятная, но нужная беседа, потому что зарывать голову в песок будет еще худшим вариантом.
Когда начинать готовиться к такому разговору? Как только вы чувствуете, что бюджет проекта существенно увеличивается — на 7–10% и более.
Какими могут быть аргументы и предложения? Можно рекомендовать два варианта: уменьшить объем работ или не выполнять дополнительные (внеплановые работы), на которые вы не рассчитывали. Либо увеличить бюджет проекта. Либо и то, и другое, и можно без хлеба.
Чтобы у вас была возможность использовать управление изменениями — она должна быть определена в договоре.
Еще один вопрос — кто оплачивает ошибки? Как известно, лучше быть здоровым и богатым, чем бедным и больным. И лучше выполнять задачу быстро, качественно и с первого раза (без ошибок). Но мы все вообще-то люди, и имеем право на ошибки. С первого раза никто не может справиться с уникальной задачей, поэтому промахи и возможность их совершить закладываются в риски проекта. Аналогично при выполнении работ вашим исполнителям может потребоваться время на изучение технологий, проверку гипотез, эксперименты и моделирование. Обо всём этом нужно думать и примерно заложить в проект на этапе планирования.
Грубые ошибки от незнания, неумения применять технологии исполнитель обычно берет на себя.
Документирование
В большинстве случаев обёртка — это половина продукта. Дорогой товар в элитном флаконе может несущественно отличаться от дешевого в эконом-упаковке.
С проектом история такая же, и документы — это аналог упаковки в этом случае. Правильно оформленные бумаги с хорошим содержанием, выпущенные и переданные заказчику вовремя, создают позитивную ауру проекту.
Не ленитесь вести план и протоколы встреч, передавать их заказчику до и после разговора. Тщательно и красиво оформлять планы проектов и презентации по статусу проекта, меморандумы, закрывающие письма, подтверждения приёмки результатов работ. Это сыграет важную роль и оставит хорошее впечатление от взаимодействия с вами.
Завершение проекта
Как говорят немцы, «у всего есть свой конец, а у сосиски даже два». И любой проект когда-нибудь завершается. В финале нужно поставить точку. В управлении проектом это письмо о его окончании. За этим может следовать передача на поддержку, вторая волна работ или же вы расстанетесь с заказчиком навсегда. Подготовьте письмо и передайте его заказчику. Надеюсь, что вы расстанетесь друзьями.
Успехов вам в управлении проектами.
*Статья написана в рамках ХабраЧелленджа 2.0, который прошел в ЛАНИТ весной 2024 года. О том, что такое ХабраЧеллендж, читайте здесь.
