PMsoop: Глава №4: Явление Менеджера Проекта

В ролях - Заказчик, Менеджер Проекта

Артефакты - ПОЗП, предложение на разработку, Контракт

Суть - Менеджер Проекта вникает в суть Проекта

Заказчик и Разработчик уже понравились друг-другу, договорились о начале работ и заключили определенные договорённости (Коантракт). Именно в этот момент в большинстве проектов происходит назначение пожалуй, ключевой фигуры проекта - Менеджера Проекта.

Сразу замечу, что в некоторых случаях Менеджер Проекта начинает работу с Заказчиком еще на этапе pre-sale вместе с сейлзом и отвечать за оценки трудозатрат; в некоторых случаях Менеджер Проекта (МП) может выполять роль сейлза; в некоторых случаях Менеджер Проекта может быть назначен на более поздних этапах - например в случаях, когда с Заказчиком работает Бизнес Аналитик, который отвечает за написание качественных требований, МП может быть назначен на этапе сбора команды проекта (следующая глава).

В любом проекте, не только в области разработки ПО, можно выделить минимум три уровня работы с требованиями:

- уровень идеи, отвественный - Заказчик, признаки - на этом уровне думают преимущественно про бизнес и выгоду, задача уровня - получать ответ на вопрос “что надо сделать?”, типичный артефакт - Vision

- уровень логики и декомпозиции, ответственный - Менеджер Проектов либо Бизнес Аналитик, признаки - на этом уровне выясняют и уточняют логику/принцип воплощения идеи, задача уровня - ответить на вопрос “как оно будет работать?”, типичные артефакты - Use Case(s), Use Scenarios, SRS (спорно - в некоторых случаях может принадлежать и к следующему уровню)

- технический уровень, ответственный - архитектор, Lead Developer, признаки - описание технических инструментов и платформ, классов и интерфейсов, ну и т.п., задача уровня - ответ на вопрос “как именно мы это сделаем”, типичные артефакты - описание архитектуры проекта, прототипы, диаграммы классов

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

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

Итак, Менеджер Проектов получил назначение на новый проект. Основные задачи МП в проекте:

- Координация обмена информацией и артефактами между Заказчиком и командой проекта

- Определение, приоритизация и постановка задач команде проекта

- “Настройка” работы команды проекта как на профессиональном так и на личном уровне

Конкретные обязанности и действия следуют из данных определений и будут раскрыты в следующих главах более подробно.

Получив назначение в первую очередь Менеджер Проекта должен изучить всю доступную информацию о требованиях проекта и Заказчике проекта - рекомендуется не только прочитать текущий документ с ТЗ и Контракт, но и организовать интервью с сейлзом проекта, почитать (если сохранилась - а сохранять её стоит) переписку сейлза с заказчиком, прочитать первые версии описания проекта и ТЗ если они менялись в процессе подготовки предложения по разработке и заключению Контракта.

Все это следует сделать для того, чтобы максимально полно понять бизнес-идею проекта и образ мыслей Заказчика.

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

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

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

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

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

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

Все, теперь Менеджер Проекта готов знакомиться с Заказчиком лично и собирать Команду Проекта для старта работ, о чём читайте далее.

И еще раз повторю самый важный момент этой главы: Менеджер Проекта должен понимать бизнес-идею проекта максимально близко к пониманию Заказчика. Рекомендую обратить внимание на этот момент как Разработчикам (на уровне супервизора проекта), так и Заказчикам (приложить максимум усилий для объяснения и задать контрольные вопросы).