Выбор формы продукта проектной деятельности — важная организационная задача участников проекта. От ее решения в значительной степени зависит, насколько выполнение проекта будет увлекательным, защита проекта — презентабельной и убедительной, а предложенные решения — полезными для решения выбранной социально значимой проблемы.
Иногда бывает, что вид продукта сразу обозначен в самой теме проекта.
Хрестоматийным является проект «Изготовление воздушного змея», выполняя который американские школьники в 1920-е гг. изучали важные законы физики. Но чаще всего выбор продукта - непростая творческая задача. Проект под названием: «Исследование влияния климата природных зон на растительный и животный мир» может завершиться защитой обыкновенного реферата, а может вылиться в увлекательную подготовку Атласа несуществующего материка.
Приведем перечень (далеко не полный) возможных выходов проектной деятельности:
- Web-сайт;
- Мультимедийный продукт;
- Анализ данных социологического опроса;
- Оформление кабинета;
- Атлас;
- Пакет рекомендаций;
-Атрибуты несуществующего государства;
- Письмо в...;
- Бизнес-план;
- Праздник;
- Видеофильм;
- Прогноз;
- Видеоклип;
- Публикация;
- Выставка;
- Путеводитель;
- Газета;
- Серия иллюстрации;
- Действующая фирма;
-Система школьного самоуправления;
- Журнал;
- Сказка;
- Законопроект;
- Справочник;
- Игра;
- Сравнительно-сопоставительный
- Карта;
анализ;
- Коллекция;
- Статья;
- Костюм;
- Сценарий;
- Макет;
- Учебное пособие;
- Модель;
- Чертеж;
- Музыкальное произведение;
- Экскурсия.
Некоторые примеры удачно выбранных продуктов проектной деятельности:
1 дневник путешествия по римским провинциям эпохи распада Империи и по СССР
конца 1980-х гг. (видеомонтаж с собственным комментарием);
2 популярное пособие «Право на каждый день» (брошюра с рекомендациями и видеофильм);
3 частотный словарь английского молодежного сленга;
4 главы из учебника будущего «Биология и экология »;
5 Манифест Николая II «О даровании народу России Конституции», каким он мог бы
быть;
6 экологические программы мониторинга и лабораторного анализа питьевой воды,
состояния радиационного фона и воздушной среды в микрорайоне (по заказу Управы района);
7 сборник научно-фантастических сочинений учащихся 6-го класса «Как принимали гостей в Средневековье»;
8 коллекция софизмов, невозможных математических объектов и интересных чисел.
Требование – это условие, которому должен соответствовать, или характеристика, которую должен иметь результат проекта в соответствии с договором или другой формально предписанной спецификацией.
Требования к продукту. В своей основе требования - это то, что формулирует заказчик. Цель, которую он преследует - получить хороший конечный продукт: функциональный и удобный в использовании. Поэтому требования к продукту являются основополагающим классом требований. Более подробно требования к продукту детализируются в следующих ниже классификациях.
Требования к продукту получаются в результате проведения анкетирования и опросов будущих пользователей продукта проекта.
Все требования нужно дискретно выразить в Реестре требований и в Документации по требованиям. Что это за документы и чем они отличаются?
Реестр требований — это таблица с перечнем и ключевыми характеристиками всех требований к проекту и продукту. Применение данного Реестра позволяет отслеживать требования на протяжении всего жизненного цикла проекта, что помогает нам быть уверенным в том, что все требования выполнены к концу проекта. Более того, Реестр требований позволяет организовать грамотное управление изменениями в проекте.
Нужно понимать, что изменения в проекте неизбежны. О документировании изменений я подробно расскажу в статье по документированию проекта в процессе контроля, а сейчас просто отмечу, что основным источником изменений в проекте являются меняющиеся хотелки и новые пожелания основных стейкхолдеров проекта (заказчика, спонсора и ключевых пользователей продукта). Конечно, изменения в проекте неизбежны, но они и крайне важны для успеха проекта. Всё дело в том, что в начале проекта пожелания стейкхолдеров могут быть не внятными, а по мере «взросления» самого проекта и требования к проекту и продукту становятся всё более зрелыми. Именно грамотное внесение изменений в проект и обеспечивает успешность проекта. Как уже отмечалось в прошлой статье, мы живём в VUCA-мире и то, что заказчик хочет в начале проекта не равно тому, что ему будет нужно в конце.
Следовательно – требования будут меняться, а Реестр требований позволяет отследить эти изменяющиеся требования на всём протяжении проекта. Идеальным вариантом оформления и ведения этого документа – использование специального ПО для отслеживания требований, типа Redmine или того же MS Project Server, только немного «доработанного напильником».
Типовые колонки таблицы, описывающие требования, включают в себя: уникальный идентификатор, текстовое описание требования, источник, критерии приемки, приоритет, версию и текущий статус (например, активно, отменено, отложено, добавлено, одобрено, назначено, выполнено). Примерная таблица приведена на рисунке:
Из рисунка видно, что описание требований в Реестре достаточно краткое и часто требует дополнительной описательной информации. Для этого и используется второй документ — Документация по требованиям, который описывает каждое требование во всех деталях, чтобы они стали однозначными (измеримыми и проверяемыми), отслеживаемыми и полными. Формат Документа по требованиям может варьироваться от простого документа, перечисляющего все требования, разделенные на категории по заинтересованным сторонам и приоритетам, до некой папки-скоросшивателя или электронной папки на портале проекта, которая включает в себя все документы и файлы, связанные с требованиями из Реестра требований. Например, в Реестре сказано, что документирование некой автоматизированной системы должно быть произведено в соответствии с ГОСТ 34.201. Соответственно в Документации по требованиям сам этот ГОСТ должен быть в бумажном или электронном виде, чтоб любой разработчик мог получить к нему доступ и выяснить все делали данного ГОСТа.