PMsoop: Глава №14: Старт разработки

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

Артефакты – ТЗ, План Проекта, список рисков, спецификация сред проекта, концепция архитектуры, оргсхема команды проекта

Суть – Менеджер Проекта объявляет старт разработки

По окончанию подготовительного этапа перед началом собственно разработки рекомендую провести собрание с командой проекта. Цели собрания:

1. Проверить готовность всех артефактов созданных за время подготовительного этапа

2. Проверить готовность команды к старту работ

3. Объявить старт работ

Напомню правила проведения собраний:

- оповещать о собрании лучше заранее, желательно за день, в письменном виде, рекомендуется использование автоматических напоминалок (outlook appointment)

- цели собрания должны быть ясны всем участникам

- собрание надо «вести», последовательно и планомерно, не допуская «галдежа», «один оратор в эфире» – хорошее правило

- результаты собрания (принятые решения) рекомендуется фиксировать в формате meeting minutes

Перейдём к детальному рассмотрению целей собрания:

Цель №1. Проверка готовности артефактов

В течение подготовительного этапа проекта должны быть созданы следующие артефакты:

- ТЗ. Должно быть достаточно полным и ясным для старта работ по первой версии (старта первой итерации). Все участники проекта должны быть ознакомлены с ТЗ, сам документ должен находиться в доступном для всех участников проекта месте на протяжении всего проекта

- План Проекта. В плане должны быть представлены все основные элементарные задачи разработки, тестирования и дополнительные задачи. ПП должен быть доступен всем участникам проекта на всём протяжении проекта. В плане крайне желательно иметь «буферы» времени для страховки от мелких рисков.

- Список рисков. Должен охватывать все найденные критические риски. Находится у Менеджера Проекта.

- Спецификация сред. Должна охватывать все основные используемые среды – разработки, тестирования, запуска, планирования и учёта, хранения артефактов. Должна быть доступна команде проекта на всём протяжении проекта.

- Концепция архитектуры. Должна кратко описывать выбранную техническую реализацию проекта. Должна быть доступна всем разработчикам проекта на всём протяжении проекта. Рекомендуется назначить разработчика, ответственного за обновление концепции архитектуры в ходе разработки.

- Организационная схема команды проекта. Должна наглядно представлять распределение ролей и ответственности в команде проекта и быть доступна всей команде на всём протяжении проекта.

Если все артефакты созданы в том или ином виде и соответствуют описанным в этой и предыдущих главах критериям – переходим к проверке сред:

- Среды разработки должны быть уже установлены

- Среда хранения и контроля версий должна быть уже установлена, доступ к ней проверен

- Среда запуска для разработки – желательно чтобы уже была готова

- Среда планирования и учёта задач – должна быть уже готова

- Среда учёта трудозатрат – должна быть готова

- Среда хранения артефактов (документации) – желательно чтобы была готова

Среды тестирования, учёта дефектов и изменений и остальные среды запуска можно установить и настроить после начала разработки.

Проверять готовность артефактов (документов) и сред рекомендуется последовательно на собрании с командой проекта. Важный момент – вся команда должна признать готовность и достаточность артефактов и сред для начала разработки первой версии проекта.

Цель №2. Проверка готовности команды

Выполняется в процессе проверки готовности артефактов и сред. Если все участники команды проекта ознакомлены со всеми артефактами, не имеют по ним принципиальных вопросов и подтверждают готовность необходимых им сред – значит, команда готова к старту.

Цель №3. Объявить старт работ

Если все необходимые артефакты и среды в порядке, и команда готова – Менеджер Проекта может официально объявить старт разработки проекта.

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

«Чувствуй силу, Люк», как говорил мастер Йода. Проверьте, что в команде проекта нет уныния и чувства безнадёжности. Удостоверьтесь, что каждый участник команды проекта понимает не только суть проекта, но и зачем выполнение данного проекта нужно именно ему. Для кого-то это просто получение ЗП, для кого-то – возможность повысить свою квалификацию в некоторой технологической области, для кого-то – возможность проявить себя в новой роли, проявить оргспособности, доказать выросшую квалификацию и получить повышение. Каждый должен чётко понимать, что и зачем он делает, и что эти действия ему дадут – это один из залогов успеха. Для выяснения этих вопросов в течение подготовительного этапа МП может провести тет-а-тет беседы с каждым участником команды проекта, выслушать его вопросы и сформулировать совместное видение этого самого «зачем».

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