PMsoop: Глава №6: Собираем Команду Проекта

в 2х частях

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

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

Суть – Менеджер Проекта собирает Команду Проекта

Пришло время познакомиться с командой проекта – простыми (и не очень) разработчиками, тестировщиками, дизайнерами, админами и прочими причастными.

Часть 1. Формирование Команды

Команда формируется обычно Менеджером Проекта по согласованию с начальниками отдела, отделом кадров, менеджерами других проектов и руководством компании. Происходит это в несколько этапов.

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

Попробую представить краткий список ролей часто встречающихся при разработке заказного ПО:

1. менеджер проекта. уже рассматривалась

2.бизнес аналитик. основные задачи – выяснение и уточнение требований, поддержание рабочих документов по требованиям в актуальном состоянии. может совмещаться с МП

3. системный архитектор. основная задача – разработка архитектуры данного проекта и определение основных используемых компонентов. может совмещаться с ролями “начальник группы разработки”, “ведущий разработчик” и “разработчик”

4. начальник группы разработки. основная задача – руководство группой разработчиков (обычно  группы формируются либо по технологии, либо по ответственности за определенный функционал), самостоятельное принятие важных технических решений в рамках своей группы (в соответствии с архитектурой проекта). может совмещаться с ролями “разработчик” и “ведущий разработчик”

5. ведущий разработчик. основные задачи – написание кода, помощь в решении технических проблем другим разработчикам, анализ кода других разработчиков.

6. разработчик. основная задача – написание кода.

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

8. ведущий тестировщик. основные задачи – выполнение тестов, написание тестов, помощь другим тестировщикам

9. тестировщик. выполняет тесты

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

Это только краткий список, и рассмотрены далеко не все варианты совмещения ролей. В малых проектах (фриланс) все роли может выполнять один и тот же человек, включая сюда и сейлза тоже. Однако следует помнить, что делать качественно всё и сразу умеют только гении. Чем больше масштаб проекта – тем большая нужна квалификация для каждой роли и тем больше негативные последствия совмещения нескольких ролей.

Определение какие роли могут быть совмещены, а какие совмещать не стоит, и определение необходимой квалификации персонала для выполнения определённой роли в проекте обычно выполняются руководством компании – Разработчика при участии МП в соответствии с бюджетом проекта, ценностью Заказчика для компании, свободными ресурсами компании и множеством других факторов. Подбор конкретных разработчиков под проект также относится к этой таинственной области. Следует понимать что в разных компаниях это происходит по разному. Также следует понимать, что часто 3 человека с большим опытом и высокой квалификацией могут заменить полноценную команду из 10 “новичков” без потери качества разработки. Рекомендаций в этой области могу дать ровно две:

- Рекомендация Заказчику: вы либо доверяете компании-разработчику, и значит принимаете что их понимае какой состав команды будет лучше для данного проекта, либо не доверяете – но тогда разработку лучше сразу прекращать.

- Рекомендация Разработчику: если вам важны хорошие отношения с Заказчиком – не стоит экономить на команде; “студентов” лучше натаскивать на долеках старых проектов или повторных проектов проверенных заказчиков, а не на новых заказчиках и технически сложных проектах.

За сим считаем что размер команды и кто какие роли будет выполнять уже определили. А раз определили – рекомендую Менеджеру Проекта определенную схему сразу зарисовать, можно на бумажке, а можно например в Visio, и ознакомить с ней всех участников проекта. Вид зарисовки может быть разным, начиная от табличного в виде “Вася = разработчик + иногда тестировщик; Петя = архитектор + разработчик”,  до схем с определением полномочий, например как в следующем примере:

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

Часть 2. Первое собрание

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

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

1. Объявить участнкиам о новом проекте, в котором им предстоит работать

2. Кратко объяснить бизнес-идею и задачи проекта на необходимом и доступном уровне

3. Объявить и обсудить предлагаемый вариант распределения ролей и обязанностей в проекте (по результатам задуманная менеджером оргсхема может измениться)

4. Раздать документацию по проекту для внимательного изучения

5. Назначить время проведения следующего собрания для обсуждения возникших при прочтении документации вопросов и предварительного планирования проекта

На всякий случай перечислю основные рекомендации по проведению собраний вообще:

1. Участники собрания должны узнать об оном заранее, лучше хотя бы за день – чтобы все успели прочитать агенду и спланировать своё время. Предупреждать о собрании за 10 минут до начала – дурной тон. Использование “напоминалок” типа outlook appointment – хороший тон

2. Рассылая участникам собрания приглашение обязательно стоит включить в него агенду собрания – перечень основных тем которые планируется обсудить. Это помогает людям правильно настроиться и, возможно, подготовить какие-то вопросы

3. В процессе проведения собрания следует соблюдать правило “один оратор в эфире!” – т.е. не допускать “галдежа”

4. Собрание должен вести о начал и до конца один человек. Он же следит за порядком высказываний и порядком вообще

5. Желательно дать высказаться каждому, кому есть что сказать по существу

6. Все принятые решения (в т.ч. о следующей встрече) нужно зафиксировать. Meeting minutes – очень полезная штука. Если “все свои” – хотя бы еще раз огласите все решения в конце собрания

7. Важно проконтролировать, что если кому-то что-то поручено, то он это запомнил. Опять же о пользе meeting minutes

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

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

Кроме этого важным моментом является задание положительного и конструктивного настроения в команде проекта начиная с первого собрания. Как именно это сделать – пока выходит за рамки данного текста т.к. пока с трудом поддаётся классификации и алгоритмизации. Могу только сказать, что вера команды в проект и его нужность/важность, а также определенные профессиональные/статусные/материальные стимулы для определенных членов команды за участие в проекте могут быть весьма полезны. Интересующимся – снова в Гугл по ключевому слову “мотивация”.