PMsoop: Глава №7: Снова вопросы и ответы

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

Артефакты – ПОЗП->ТЗ

Суть – Команда проекта уточняет требования проекта, по результату ПОЗП превращается в ТЗ

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

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

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

В общем, при постановке задачи “изучить проектную документацию” следует:

- определить сроки на изучение и назначить дату и место следующего собрания

- обязательно попросить записать все возникшие вопросы и подготовиться к их представлению на след. собрании

- желательно попросить подготовить и представить на след. собрании свои предложения касательно разработки/тестирования/… проекта, если таковые появятся

Теперь переходим собственно к следующему (за изучением проектной документации) собранию. Его основные цели:

1. Собрать вопросы, возникшие у команды проекта в процессе изучения документации, и найти ответы на них

2. Выяснить готовность документации для начала проектирования архитектуры и планирования работ по проекту

3. Проверить, что все участники команды проекта одинаковым и правильным образом поняли требования

Дополнительными целями собрания могут являться:

4. Обсудить возможные варианты реализации проекта. Выбрать оптимальный вариант реализации с учётом всех условий и “набросать” концепцию архитектуры

5. Выделить основные задачи по реализации функционала и определить их последовательность

6. Наметить основные этапы и типы тестирования

7. Определить необходимые трудозатраты для выделенных задач и сверить сроки сдачи версий

8. Определить основные риски проекта

9. Зафиксировать все  принятые решения и сделанные оценки и перейти к составлению плана проекта

Однако, реализовать все обозначенные цели на одном собрании можно только для весьма небольших проектов с небольшими командами разработки, так что реализацию целей 4 – 9 я последовательно рассмотрю в главах 8, 9 и 10.

Перейдём к более подробному рассмотрению целей 1 – 3:

Цель 1. Собрать вопросы, возникшие у команды проекта в процессе изучения документации, и найти ответы на них

Реализуется во время подготовки к собранию, собственно на самом собрании и после него. На “установочном” первом собрании или при раздаче требований по проекту для их изучения рекомендуется попросить всех участников возникшие у них вопросы записывать и за некоторое время (одного дня обычно хватает) до собрания по “проверке требований” прислать свой список вопросов Менеджеру Проекта.

Менеджер Проекта с помощью бизнес-аналитика (если таковой присутствует в проекте) должен до собрания отсортировать присланные вопросы на следующие три группы:

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

- вопросы, требующие ответов Заказчика но не сильно срочно. Например, уточнение реализации определённой функции или расположение элменетов на интерфейсу.

- вопросы, ответы на которые можно дать самостоятельно исходя из уже имеющейся инфомации по проекту.

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

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

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

Проверка достижения цели – наличие вопросов, разбитых на обозначенные группы; критически важные вопросы заданы Заказчику

Цель 2. Выяснить готовность документации для начала проектирования архитектуры и планирования работ по проекту

Когда получены ответы на критические вопросы (первая группа) – можно озадачить Заказчика разбором вопросов второй группы, которые можно задать уже в виде email но обязательно с указанием желательного срока ответа. Затем нужно обновить требования проекта (ПОЗП) с учётом полученных ответов на критические вопросы. Наличие требований проекта в которых нет явных и критичных для планирования разработки “дыр” является важным фактором для успешности проекта. Информация должна быть собрана в одном месте, доступном всем участникам – для этого и документируют требования в виде определённого документа (Proposal For Development, SRS, etc), и именно этот документ нужно будет обновить. Делает это бизнес-аналитик, либо Менеджер Проекта (если нету бизнес-аналитика). Полученный документ, в котором собраны требования по проекту не не обнаружено (на данном этапе) критических недостатков отныне будем называть просто ТЗ.

Отдельно замечу, что ТЗ крайне редко является “неизменным” документом – обычно его еще предстоит обновлять, уточнять и изменять в ходе всего проекта и особенно на этапах между итерациями, после сдачи очередной версии  пр детальном планировании работ по следующей версии. Это – нормально, так и должно быть, т.к. “видение” финального приложения у Заказчика обычно меняется по ходу визуализации/реализации продукта. На подготовительном этапе при реализации цели №1 задачей Менеджера Проекта и всей команды является получение некоторой “отправной точки”, в которой информации достаточно для перехода к планированию реализации проекта. Критерий достаточной ясности требований – субьективное дело Менеджера Проекта и участников команды, и зависит от их профессионализма и опыта в разработке проектов подобной направленности.

Проверка достижения цели – наличие ТЗ, достаточного для перехода к планированию реализации с точки зрения всех участников команды проекта.

Цель 3. Проверить, что все участники команды проекта одинаковым и правильным образом поняли требования

Реализуется на собрании по проверке требований. Ответственный за реализацию – Менеджер Проекта. Анализируя вопросы, заданные участниками команды проекта и задавая свои дополнительные вопросы, а также разъясняе спорные и неясные моменты Менеджер Проекта должен добиться одинакового и ясного понимания бизнес-идеи проекта и его основных задач (основного функционала, как это должно работать) всеми участниками команды.

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