 |
Проверка и контроль содержания
|
|
|
|
_______________________________________________________________________________
Управление содержанием проекта включает процессы, необходимые для того, чтобы удостовериться в том, что проект включает все необходимые работы (и только их) для достижения успеха проекта.
Процессы этой области знаний:
· сбор требований;
· определение содержания;
· создание ИСР (иерархической структуры работ);
· проверка содержания;
· управление содержанием.
Управление содержанием осуществляется на протяжении всего жизненного цикла проекта.
Содержание проекта — работы, которые необходимо выполнить, чтобы получить продукт, услугу или результат с указанными свойствами и функциями.
Содержание продукта — свойства и функции, которые характеризуют продукт, услугу или результат.
Определение содержания и управление им определяет общий успех проекта. При работе над каждым проектом важно соблюдать баланс средств, источников данных и методологий, процедур и других факторов для того, чтоб усилия, потраченные на работу с содержанием, соответствовали размеру, сложности и важности проекта.
Многие проекты терпят неудачи чаще всего из-за того, что их содержание и границы плохо определены. Ожидания стороны, заинтересованной в реализации проекта (в частности, заказчика или спонсора), часто не совпадают с ожиданиями команды, занятой в проекте. Сделать так, чтобы ожидания совпадали, — задача трудная, однако крайне важно решить ее для успеха проекта в целом.
Когда речь заходит об определении содержания проекта, команда проекта и клиент как бы меняются ролями. До этого момента с заказчиком в основном контактируют люди, в задачи которых входит «продать» проект. «Продавец» пытался убедить заказчика, что проект — дело стоящее, на него стоит потратиться. Иногда «продавец» описывает проект в столь ярких красках, что намеренно или непроизвольно заставляет клиента поверить: все, что мог себе представить последний в самых невероятных мечтах, благодаря проекту превратится в реальность. На деле такое происходит весьма редко. У заказчика формируются завышенные ожидания, что очень опасно для проекта.
|
|
|
Когда команда проекта сформирована и определение содержания проекта происходит в процессе переговоров, заказчик считает, что проект уже согласован. В итоге весь процесс определения содержания и границ проекта заказчик считает пустой тратой времени. Клиент может даже воспротивиться определению содержания проекта. Это происходит в том случае, если заказчик не знает в точности, что ему необходимо.
Одно из наиболее сложных испытаний для команды проекта — убедить представителей заказчика, что их цели в проекте во многом схожи. Другими словами, главная цель проекта — дать заказчику то, что ему действительно нужно и очень важно, и описать содержание проекта.
Команда проекта должна войти в положение заказчика. То, что заказчик знает о проекте немного, не помешает его успешно реализовать. В конечном счете, причина, по которой на проекте работают определенные люди, как раз в том и состоит, что это специалисты именно в данной области. Что бы представители заказчика ни думали, они специалистами не являются, иначе не обратились бы к подрядчику.
Иногда для определения границ проекта должны быть использованы неординарные средства. Возможно, одному или нескольким сотрудникам проекта придется поработать какое-то время у заказчика, чтобы войти в курс дела и осознать, каких усовершенствований он ждет от проекта. Это хороший прием, если клиент не желает или не способен выделить необходимые временные и кадровые ресурсы для работы с командой проекта. Представитель проекта как бы перевоплощается в заказчика и, узнав о нем достаточно много, начинает выступать от его имени.
|
|
|
Сбор требований
Сбор требований — это процесс определения и документирования требований участников проекта относительно результатов проекта (табл. 2.1).
Таблица 2.1. Сбор требований
| Входы в процесс | Методы и инструменты | Выходы из процесса |
| Устав проекта Реестр участников проекта | Интервью Фокусные группы Вспомогательные семинары Методы коллективной работы Методы коллективного принятия решений Вопросники и анкетирование Мониторинг Прототипы | Документированные требования участников проекта План управления требованиями Матрица отслеживания требований |
Реестр участников проекта должен включать:
· перечень участников проекта;
· идентификационную информацию: имя, должность, роль в проекте, контакты;
· содержательную информацию: основные требования, основные ожидания, их потенциальное влияние на проект;
· классификацию участников проекта: внешний/внутренний поддерживающий/нейтральный/препятствующий и т.д.
Документированные требования участников проекта должны содержать:
· бизнес-цели проекта;
· функциональные и нефункциональные требования;
· требования к качеству;
· влияние на окружение внутри и снаружи исполняющей организации;
· допущения и ограничения требований.
План управления требованиями (рис. 2.1) определяет порядок анализа, документирования и управления требованиями в течение жизненного цикла проекта.
Матрица отслеживания требований — это таблица, в которой показана корреляция между требованиями к проекту и его элементами, как то:
· бизнес-целями и возможностями;
· целями проекта;
· содержанием проекта / Результатами ИСР;
· проектированием продукта;
· созданием продукта;
· стратегией и порядком испытаний;
· и т.д.
Пример матрицы отслеживания требований показан в табл. 2.2.
Таблица 2.2. Пример матрицы отслеживания требований
| № п/п | Описание требования | Цель проекта | Обоснование | Источник | Приоритет |
| Требование 1 | |||||
| Требование 2 | |||||
| Требование 3 |
В российской практике требования к проекту оформляются в Техническом задании на проект. Часто техническое задание является приложением к договору. Необходимо отметить, что в российской специфике бизнеса только договор с подписями и печатями сторон является несокрушимым аргументом в споре с заказчиком при разрастании требований к проекту. Поэтому команда проекта должна всеми силами стараться включить максимально подробные требования к проекту со всеми ограничениями и допущениями в контракт.
|
|
|
Техни́ческое зада́ние (ТЗ, техзада́ние) — исходный документ для проектирования сооружения или промышленного комплекса, конструирования технического устройства (прибора, машины, системы управления и т. д.), разработки информационных систем, стандартов либо проведения научно-исследовательских работ (НИР).
История, леденящая душу
...и наказал тогда царь (Заказчик) - построить мельницу, да такую, чтобы от силы ветра работала, круче, чем у короля аглицкого («хотелки» Заказчика), да чтоб на зависть всем буржуям (соответствующую современному уровню развития науки и техники и не уступающую аналогичным требованиям, предъявляемым к лучшим современным отечественным и зарубежным аналогам).
Приволокли опричники холопа государева, умепьца местного (Исполнителя), кинули царю-батюшке в ноги. Бился лбом умелец о пол палат каменных - дык, оно, конечно! Сделаем, твое величество, все безоговорочно, точно, в срок и в полном объеме.
Настало время, прибыл царь на мельницу (приемка-сдача работ). Смотрит и диву дается - крылья крутятся, жернова жито молотят, мука сама-собой в мешки сыплется! (Полное соответствие требованиям к функциям (задачам), выполняемым системой). Да возьми и запусти руку в мешок... (что не было предусмотрено ни техническим заданием, ни программой и методиками испытаний, поскольку не существовало таковых).
Побагровел царь - что ж, смерд, мельница сия муку непотребно мелет?! (Несоответствие производимой продукции требованиям ГОСТ 7045-90 Мука ржаная хлебопекарная. Технические условия). Схватили мужика опричники, да долбанули буйну его голову топором каменным. И кончил жизнь Левша под звуки «Реквиема» Моцарта из музыкального автомата...
|
|
|
Выводы
В стародавние времена в отношениях сторон, Заказчика и Исполнителя, равноправия было маловато. Чем-то, само-собой, отношения регламентировались. Возможно, готовились берестяные грамоты - прообразы современных Договоров. Вряд ли в подобных договорах можно было учесть все, даже качество помола. Да и не было общепризнанных стандартов, документов, в широком смысле регламентирующих все аспекты взаимоотношений Заказчика и Исполнителя.
Издавались Указы, Распоряжения - «в университете московском студиозусам надобно на соломе сидеть, сморкаться в кулак, нос утирать пучком соломы. А нарушивших правила сии розгами драть нещадно» (или что-то в этом роде).
Равноправия нет и сейчас - кто платит, тот и заказывает музыку. А платит Заказчик.
ТЗ содержит основные технические требования, предъявляемые к сооружению, изделию или услуге и исходные данные для разработки; в ТЗ указываются назначение объекта, область его применения, стадии разработки конструкторской (проектной, технологической, программной и т. п.) документации, её состав, сроки исполнения и т. д., а также особые требования, обусловленные спецификой самого объекта либо условиями его эксплуатации. Как правило, ТЗ составляют на основе анализа результатов предварительных исследований, расчётов и моделирования.
Как инструмент коммуникации в связке общения заказчик-исполнитель, техническое задание позволяет:
- обеим сторонам
- представить готовый продукт
- выполнить попунктную проверку готового продукта (приёмочное тестирование — проведение испытаний)
- уменьшить число ошибок, связанных с изменением требований в результате их неполноты или ошибочности (на всех стадиях и этапах создания, за исключением испытаний)
- заказчику
- осознать, что именно ему нужно
- в т.ч. опираясь на существующие на данный момент технические возможности и свои ресурсы
- требовать от исполнителя соответствия продукта всем условиям, оговорённым в ТЗ
- исполнителю
- понять суть задачи, показать заказчику «технический облик» будущего изделия, программного изделия или автоматизированной системы
- спланировать выполнение проекта и работать по намеченному плану
- отказаться от выполнения работ, не указанных в ТЗ
Техническое задание — исходный документ определяющий порядок и условия проведения работ по Договору, содержащий цель, задачи, принципы выполнения, ожидаемые результаты и сроки выполнения работ.
Любое техническое задание должно содержать разделы, отражающие сведения:
|
|
|
- что надо сделать;
- для чего, с какой целью надо сделать это;
- где, в какой области применения, на каком объекте это должно решать задачи и выполнять свои функции;
- какие требования будут предъявлены к этому;
- какие работы потребуется выполнить, чтобы сделать это;
- каков порядок приемки-сдачи работ Заказчику;
- как должно быть задокументировано проведение работ;
- и, наконец, на основании каких нормативно-технических документов должны проводиться работы?
Ограничения по проекту — это все, что ограничивает рамки проекта. Например, ограничением содержания проекта по проведению учебного курса будет являться программа курса. При желании заказчика программа курса может быть расширена, то есть количество работы увеличивается, но расширение программы будет сделано за дополнительную плату.
Допущения проекта — это все предположения, которые делает команда при планировании работ. Например, при проведении курса мы делаем допущение, что заказчик самостоятельно подготовит учебный класс и предоставит компьютеры слушателям.
Определение содержания
Определение содержания — это создание детального документа, отражающего цели и задачи проектных работ («Описание содержания проекта», согласно PMI). Необходимо отметить, что из-за плохого перевода термина в России никто не использует подобное название документа.
Процесс определения содержания показан в табл. 2.3.
Таблица 2.3. Определение содержания
| Входы в процесс | Методы и инструменты | Выходы из процесса |
| Устав проекта Документированные требования участников проекта Активы организационного процесса | Экспертная оценка Анализ продукта Анализ альтернатив Вспомогательные семинары | Описание содержания проекта Обновления документации проекта |
Обычно, подобный документ называется Техническим проектом, Концепцией или просто Проектом, содержащим проектную документацию (например, чертежи здания).
Основой для разработки Описания содержания проекта (Технического проекта) служит Устав проекта, который детализируется в Требованиях к проекту (Техническом задании). Включает следующие разделы:
· описание содержания продукта;
· критерии приемки продукта;
· результаты проекта;
· границы проекта;
· ограничения проекта;
· допущения проекта.
В крупных технологически сложных проектах, к которым предъявляются серьезные требования к безопасности и технологии проведения работ, российские предприятия применяют требования ГОСТ для создания проектной документации. Примерами таких сложных проектов могут служить бурение нефтяных скважин, строительство дорог, зданий и т.д.
Однако даже в небольших проектах нужно очень подробно описывать все характеристики будущих результатов проекта, для того, чтобы избежать потом разногласий с заказчиком по приемке работ. Даже если заказчик считает подобный документ ненужным, команда проекта должна убедить его подписать документ.
Всегда есть риск, что руководитель проекта не сможет доказать, что проект завершен из-за появления новых требований заказчика.
Чаще всего невозможно описать все содержание проекта подробно. Поэтому Описание содержания может детализироваться и уточняться в ходе проекта.
|
|
|
