А что делает Менеджер Проекта?
А что делает Менеджер Проекта?
Как-то меня представили одному разработчику со стороны Клиента, сказав, что я в команде - менеджер проекта. Разработчик не удержался и ответил: “А, так вы один из тех, кто с утра говорит нам, что делать, а сам потом весь день балду пинает?”
Это - классика жанра. Именно так менеджеры проекта воспринимаются многими разработчиками. Не всеми, конечно. Искренне верю, что читатели блога понимают, во что обычно превращается проект без менеджера.
Как бы то ни было, вокруг этого понятия существует масса разночтений, поэтому подобно слепым мудрецам, ощупывающим слона, попробуем рассмотреть, как выглядит PM с разных сторон. При этом для определенности рассматривать будем менеджера со стороны Заказчика (владельца веб-сайта), а не Подрядчика. Все-таки так правильнее.
Люди и Роли
Первое, что требуется четко осознать: PM - это не навык и не должность. PM - это роль в проекте.
Представьте себе, что вот есть задача (проект), вокруг него собирается куча людей, которые должны ее выполнить (команда). Это могут быть самые разные сотрудники компании, фрилансеры и представители компаний-подрядчиков. Каждый из них до начала проекта чем-то занимался, но с этого момента он получает роль. От него будет требоваться вполне определенный набор действий и решений для того, чтобы в итоге получился желаемый продукт.
С другой стороны, в условиях проектной деятельности существует вполне строго определенный набор ролей, при выпадании которых, риски проекта возрастают.
И вот тут начинается самое интересное. Угадайте, кому достаются те роли, для которых в команде не нашлось выделенных людей? Правильно: тому, что отвечает за конечный результат - менеджеру проекта.
Между тем, это далеко не всегда лучшее решение. Если в двух словах, то риск сводится к тому, что под давлением противоречивых интересов менеджер может допустить слишком много компромиссов, что в итоге пагубно скажется на результате. А то, что проектов без противоречивых интересов не бывает, и про соотношение Скорость/Качество/Бюджет я надеюсь, напоминать не обязательно.
Любая методология проектного управления очерчивает сферу ответственности PM вполне четко. Например PRINCE2 выделяет следующие процессы, за работу которых отвечает менеджер проекта (вольный перевод автора):
- Подготовка к проекту (Starting up a Project)
- Открытие проекта (Initiating a Project)
- Планирование (Planning)
- Управление стадиями (Controlling a Stage)
- Управление доставкой продуктов (Managing Product Delivery)
- Управление границами стадий (Managing Stage Boundaries)
- Закрытие проекта (Closing a Project)
Таким образом, для всего остального менеджер обязан привлекать специалистов. Предоставить таких специалистов - задача Заказчика. Самому Заказчику, разумеется, выгоднее обойтись минимальным количеством людей: и управлять проще, и дешевле. Отсюда появляются завышенные ожидания и связанные с ними риски, которые интересно разобрать подробнее.
Что часто ожидают от PM?
Оценка
Основной критерий качества оценки - это ее соблюдение по факту. Добиться этого можно только путем приобретения опыта выполнения схожих задач. У менеджера такого опыта, как правило недостаточно, поэтому риск неверной оценки возрастает.
При этом даже не важно, в какую сторону происходит отклонение. Если неверная оценка не соблюдается, становится сложно координировать работы, страдают бюджет и сроки. Если неверная оценка соблюдается, это означает, что исполнители либо измотаны, либо слишком расслаблены и в любом случае демотивированы.
Кроме того, у менеджера существует прямая мотивация завышать оценку, поскольку за объем и легкость продаж он не отвечает, а рамки проекта соблюдать придется.
Принятие решений проектного уровня
На самом деле, хороший PM должен быть способен принимать решения. В ходе проекта это требуется постоянно. Но у его ответственности тоже есть границы. PM отвечает за доставку результата с заданым уровнем качества в рамках заданных сроков и ресурсов. Рамки необходимо устанавливать для каждой стадии, и если проект выходит за эти рамки, решение о коррекции обязан принимать Заказчик.
Если Заказчик от этого уклоняется, то решение все равно будет принято менеджером, но это произойдет без учета той информации, которая доступна только Заказчику.
Проектирование
Проектирование начинается с составления Технического Задания, которое является частью проектной документации. За проектную документацию традиционно отвечает PM, поэтому ему и карты в руки.
Следуя такой логике, мы часто получаем ТЗ, которые: недостаточно подробны, содержат противоречивые требования, не соответствуют возможностям платформы, не учитывают мнение конечных пользователей.
Но как практик я должен сказать, что способность менеджера проектировать веб-сайты радикально повышает эффективность проекта. Сочетание ролей проектирования и управления проектом - то редкое исключение, к которому имеет смысл стремиться. Только убедитесь, пожалуйста, что это реально работает.
Практическое знание технологий
Есть мнение, что хороший PM веб-проекта может получиться только из бывшего разработчика. И хотя знание технологий нельзя переоценить, я все же придерживаюсь другой точки зрения.
Во-первых, менеджер проекта должен всегда держать дистанцию между собой и проектом. Только тогда он сможет видеть картину целиком, не погружаясь слишком глубоко в детали. Для бывшего разработчика детали - слишком большое искушение, потому что слишком привычно и слишком увлекательно.
Во-вторых, менеджер проекта, влияя на продукт, обязан больше думать об использовании продукта, чем о процессе его разработки и внутреннем устройстве. Для бывшего разработчика это тоже затруднительно, потому что выработались уже свои взгляды на удобство.
Контроль качества
Если Ваш менеджер самостоятельно контролирует качество, это прекрасно. Он знает каждую функциональность сайта и в любой момент может сказать, где и сколько дефектов, и когда все будет исправлено.
Только помните, что тестирование продукта - финальная стадия проекта, когда сроки почти вышли, и ресурсы почти закончились. Именно в этот момент человек, который отвечает за ресурсы и сроки, начинает идти на компромиссы с качеством. У тестера совершенно обратная мотивация: его обязанность - зарегистрировать отклонение от ТЗ или внутренних стандартов.
Кроме вышеперечисленных ожиданий случаются и другие - более спорные. Например, постановка технических задач, обеспечение загрузки ресурсов, установление стандартов управления проектами. Но идея, я надеюсь, уже понятна.
Теперь у успешных Заказчиков возник вопрос: Зачем мне обо всем это думать, если мой менеджер гениален, и даже при совмещении ролей проблем нет?
Возник? Тогда продолжаем разговор…
Учет ресурсов
Вы же адекватный руководитель, правда? Значит, понимаете, что менеджер проекта - это сотрудник, который рано или поздно либо сменит род деятельности, либо покинет компанию.
И вот Вам нужно начинать новый проект (сайт устарел, изменились требования и пр.), находите Вы нового человека и начинаете ощущать разницу:
- Либо выясняется, что новому менеджеру нужно еще 3 человека в помощники
- Либо оказывается, что прежний менеджер “управлял проектом” 30 часов в неделю, а новый утверждает, что будет тратить на “управление” 15 часов в неделю при схожем размере проекта
- Либо все это происходит наоборот
Чтобы была возможность измерить работу Вашего сотрудника, имеет смысл фиксировать потраченное время не по должностям, а по ролям или категориям. При совмещении ролей это становится просто критично для адекватного анализа статистики.
Категоризация работ внутри проекта веб-разработки может быть, например, такой:
- Управление проектом
- Проектирование (включая ТЗ и/или прототип)
- Разработка дизайна основных шаблонов
- Графические работы
- Разработка фронт-офиса (статических шаблонов)
- Программирование (внедрение функционала и CMS)
- Тестирование
- Разработка сопроводительной документации
- Обучение пользователей
- Администрирование
Как минимум 5 категорий их этого списка очень часто выполняются менеджером проекта.
И в заключение, заранее отвечая на вопрос “Какие роли объединять, а какие - нет?”, скажу: единого рецепта не существует. Старайтесь балансировать таланты Вашего менеджера и его полномочия/ответственность. На баланс влияют:
- Размер проекта и организации
- Типизация проектов
- Мотивация менеджера
- Наверняка что-нибудь еще :)
Удачи! Следите за эфиром!
