Лекции-фонда-фонда-новых-форм-образования.-Гибкие-компетенции-пр. Лекция 1 общее представление о проектной деятельности 1 Проектная деятельность общее представление. Понятие проекта
 Скачать 0.68 Mb.
|
|
7.2 Требования в проекте Что же требуется еще прояснить, чтобы в представлении о целях и результатах проекта появилась определенность? Этими деталями, вносящими определенность в ожидания, являются требования. Требования позволяют конкретизировать и детализировать ожидания различных групп заинтересованных сторон, отражают различные точки зрения на результат проекта. Проработка требований позволяет проверить образ результата на полноту и непротиворечивость, а также зафиксировать все необходимые потребности. Требование – это условие, которому должен соответствовать, или характеристика, которую должен иметь результат проекта в соответствии с договором или другой формально предписанной спецификацией. Например, для проекта по организации выставки научно-технического творчества в мастерской Фаблаб требованиями могут быть: выставка должна быть проведена в выходные дни; обеспечить количество экспонатов в количестве не менее 30 штук; приглашения разослать не менее чем за месяц до начала и т.д. Требoвания включают в себя потребности и ожидания Спонсора, Заказчика и прочих заинтересованных лиц. Они должны быть задокументированы со степенью детализации, достаточной для того, чтобы вы могли на их основе построить план работ и бюджет проекта. Разработка требованийк результату проекта, в зависимости от сути проекта,может выполняться сразу и полностью или же последовательно, по частям (например, когда используются гибкие подходы к управлению проектом, о которых будет рассказано в одной из следующих лекциях). Итак, должным образом проработанные требования позволяют: выработать общее понимание между Заказчиком и Исполнителем; более точно определить финансовые и временные характеристики проекта; обезопасить Заказчика от риска получить продукт, который ему не нужен; обезопасить Исполнителя от риска попасть в ситуацию со значительным увеличением затрат. Управление требованиями – это систематический подход к выявлению, организации и документированию требований к продукту проекта, а также установка и поддержание соглашения между заказчиком и исполнителями по поводу изменений требований к продукту. 7.3 Какие бывают требования? Существует различные классификации требований к продукту проекта. Одной из часто используемых классификаций является разделение по уровню детализации: Бизнес-требования содержат высокоуровневые цели Заказчика проекта, определяют назначение продукта проекта. Например, для уже упомянутого проекта по организации выставки таким требованием может быть: привлечь не менее 200 посетителей. Требования пользователейописывают задачи, которые должен решать продукт проекта с точки зрения пользователя (что пользователи могут делать с его помощью). Например, напомнить зарегистрированным пользователям о мероприятии за один день до начала; организовать кофе брейк в течение дня. Требования исполнителей определяют функциональность и характеристики продукта, которые должен выполнять продукт проекта, чтобы реализовать бизнес-требования и требования пользователей. Например, у каждого экспоната должно быть свое освещение; должна быть организована электронная регистрация с автоматической рассылкой оповещений. Другая классификация – по типу требований: Функциональные требoвания – требoвания к поведению продукта проекта, отвечают на вопрос «что он должен делать» в тех или иных ситуациях. Нефункциональные требoвания – требoвания к характеру поведения продукта проекта, определяют свойства продукта, т.е. как он должен работать. Применительно к этому типу требований часто говорят о показателях качества[1] продукта и об ограничениях продукта.  [1] Согласно стандарту ГОСТ 15467-79 под качеством понимается совокупность свойств продукции, обуславливающих ее пригодность удовлетворять определенные потребности в соответствии с ее назначением. А под показателем качества продукции – количественная характеристика одного или нескольких свойств продукции, входящих в ее качество, рассматриваемых применительно к условиям ее создания и эксплуатации или потребления. Выделяют различные свойства требований, приведем основные из них: Ясность (понятность) – требoвание однозначно понимается Заказчиком и исполнителями. Для этого они должны быть написаны достаточно просто, логично и точно. Например, требование «экспонаты должны соответствовать заявленной тематике выставки и выставлены в трех залах» лучше разделить на два. Полнота и единичность – требoвание описывает одну и только одну характеристику, содержит всю необходимую информацию для исполнителей. Трассируемость (прослеживаемость) – требoвание не противоречит другим требованиям, полностью соответствует остальной документации. Выполнимость – требoвание может быть реализовано в пределах проекта. Проверяемость (тестируемость) – существует возможность проверить реализованные требования, например, одним из следующих методов: тест, анализ, осмотр. К примеру, требование «чтобы экспонаты были красивыми» – явно не отвечает этому требованию, а вот «экспонаты должны быть разработаны резидентами Фаблаба» уже проверяемо. 7.4 Источники требований Практика показывает, что хорошие требования начинаются с хороших первоисточников. При этом источники зависят от специфики проекта и контекста предполагаемого использования продукта проекта. Помимо Заказчика и пользователей в качестве источников требований обратите внимание на: Пользователей продукта (явных и потенциальных), их представления и ожидания. Обслуживающий и технический персонал. Нормативные документы: законодательство, нормативное обеспечение организации (регламенты, положения, приказы). Экспертов в предметной области проекта. Журналы и отчеты об использовании существующих систем, устройств, процессов. Конкурирующие (аналогичные) продукты, а также их исполнители. Наблюдения за работой пользователей на их рабочих местах. Маркетинговые исследования, опросы, статистические выборки. Отчеты об ошибках, жалобы, запросы на усовершенствование. Системы, продукты, с которыми необходимо обеспечить интеграцию, и т.д. 7.5 Методы выявления требований Для выявления требований используются различные методы. Спрашивать у пользователей «Что вы хотите?» бесполезно, в подавляющем большинстве случаев не смогут внятно описать свои пожелания. Поэтому для того, чтобы собрать наиболее качественные требования, рекомендуется сочетать между собой несколько методов. Рассмотрим основные методы выявления требований: Интервью: используется для получения информации у заинтересованных сторон через беседу с ними. Многое можно узнать, например, пообщавшись с командой сопровождения (техподдержкой) текущей системы или продукта. Умение задавать вопросы – это полезный навык, который может оказать неоценимую поддержку в работе. После каждого интервью рекомендуется документировать полученную информацию и отправлять на проверку респонденту. Анкетирование: позволяет быстро собрать информацию у большого числа респондентов. Важно грамотно составить вопросы и хорошо оформить анкету, чтобы ее было удобно заполнять. Фокус-группы: предназначены для проведения встречи заинтересованных сторон и экспертов по предметной области, чтобы узнать их ожидания и отношение к предложенному проекту. Наблюдения: позволяют вникнуть в обстановку, непосредственно увидеть, как проходит процесс и выполняется сотрудником работа; изучить на месте улучшения, сделанные пользователями. Это особенно полезно в случае, когда заинтересованное лицо не может отчетливо изложить свои требования. Методы группового творчества (мозговой штурм, диаграммы сходства и т.д.): предназначены для совместной генерации и отбора лучших идей, связанных с требованиями к проекту. Бенчмаркинг: используется для выявления лучших практик, изучения аналогичных продуктов. Анализ документов: необходим для выявления требований путем анализа существующей документации, в том числе для исследования отчетов о проблемах и жалоб. Прототипы: предназначены для демонстрации заинтересованным сторонам рабочей модели ожидаемого продукта и получения предварительных отзывов относительно требований. 7.6 Шаги по разработке требований Обобщенный алгоритм разработки требований включает: Выявление требований. Анализ требований. Документирование требований. Проверка требований. Стоит сразу отметить, что редко, когда данные шаги делаются последовательно. По своей сути, это итерационный процесс: шаги чередуются и периодически повторяются. Рассмотрим каждый шаг подробнее. 1. Выявление требований к результату проекта – самый сложный шаг в процессе разработки требований. От того, насколько точно, полно и достоверно собраны требования, зависит реализация всего проекта. Хоть выявление требований – это творческий процесс, но есть ряд методов, которые помогут вам собрать требования (приведены на предыдущей странице). На данном шаге рекомендуется пользоваться предварительно созданным планом выявления требований. Он существенно повышает эффективность выявления, делает процесс более осознанным и направленным. План может состоять из следующих разделов: Что хотите узнать: перечисление целей выявления требований. Где хотите узнать: перечисление источников. Как будете узнавать: используемые методы, мероприятия. Что хотите получить: список предполагаемых документов, результатов. Когда хотите узнать: назначение исполнителей. Как понять, что требований уже достаточно? Полностью выявить требования к продукту проекта практически невозможно, однако можно выделять ряд признаков, которые могут указать, что пора переходить на следующий шаг – проводить анализ требований: заинтересованные стороны говорят о проблемах, которые уже были обсуждены и зафиксированы; информация из различных источников стала повторяться; заинтересованные стороны стали предлагать новые характеристики, функции, которые явно выходят за рамки текущего проекта; заинтересованные стороны стали предлагать новые способы решения их задач, однако команда проекта уже приняла решение, каким образом будут реализовываться данные задачи. 2. Анализ требований имеет своей целью получение понятных и непротиворечивых требований, на основе которых можно проектировать и реализовывать продукт проекта. Поскольку в проект невозможно включить все выявленные требования, во время процесса анализа отбираются окончательные требования к проекту. Какие действия происходят на данном шаге: Сформулируйте полученную информацию в виде требований с такой степенью подробности, которая будет понятна исполнителям. При необходимости уточните требования; выявите вторичные требования, логически проистекающие из запросов пользователей; определите невысказанные ожидания; исключите конфликтующие и дублирующие требования. Проанализируйте осуществимость заявленных требований; рассмотрите риски, связанные с реализацией каждого требования, включая зависимость от внешних факторов и препятствия технического характера. Определите совместно с Заказчиком их приоритеты и сроки реализации. Выбор средств анализа зависит от типа проекта, количества и взаимосвязанности требований. Для небольших проектов достаточно составить список требований в Word и проанализировать его. Для средних и больших проектов требования удобно анализировать и описывать с помощью моделей требований. К наиболее часто используемым моделям обычно относят методы анализа бизнес-процессов, объектно-ориентированного анализа и структурного анализа. В том числе используются методологии графического моделирования: ER (IDEF1FX), IDEF0, IDEF3, DFD, UML, eEPC и др. 3. Документирование требований происходит обычно параллельно с процессом анализа требований. Может сначала происходить высокоуровнево, а затем постепенно детализироваться по мере поступления новой информации. В зависимости от проекта формат документа с требованиями может варьироваться: от реестра требований – простого документа, перечисляющего все требования, отсортированные по приоритету; до полноценного технического задания – более тщательно проработанного описания, содержащего технические решения. Требования могут документироваться при помощи текстового описания или в виде графических диаграмм. Важно, чтобы требования были сформулированы на понятном языке для Заказчика, иначе он не сможет адекватно оценить, то ли ему нужно получить в итоге. Помимо описания документ с требованиями может включать в себя: Критерии приемки результата проекта: набор условий, по которым Заказчик будет оценивать результаты проекта, порядок проведения приемки работ. Ограничения и исключения из проекта: сформулировано то, что ограничивает выполнение проекта, что находится вне содержания текущего проекта, например предопределенный бюджет, ограничивающие даты. Данный раздел помогает управлять ожиданиями заинтересованных сторон. Приведем некоторые из рекомендаций к формулированию требований: Абзацы и предложения должны быть краткими и ясными. Используйте термины так, как они определены в словаре, желательно не использовать синонимов и близких по значению слов. Применяйте визуальное представление информации: списки, таблицы, графики, диаграммы и рисунки. 4. Проверка требований. После того, как требования собраны, проанализированы и задокументированы, необходимо проверить качество разработанных документов. В такой проверке участвуют как представители команды проекта, так и представители Заказчика, в том числе, эксперты в предметной области. Проверка заключается в поиске предметных неточностей, противоречий, недостающих сведений, оценке реализуемости. После проверки и исправления замечаний утвердите документ у Заказчика и смело приступайте к реализации проекта. ЛЕКЦИЯ 8 - ЖИЗНЕННЫЙ ЦИКЛ ПРОЕКТА 8.1 Определения и понятия Какие бы явления, события или процессы в природе и в обществе мы бы не стали рассматривать, все они проходят путь от момента своего зарождения до завершения. И в своем развитии они последовательно сменяют свои состояния, или фазы, требующие соответственно разных подходов к управлению, к реализации. Во многих случаях такой путь называют жизненным циклом. Понятие жизненного цикла применимо и к проекту. Любой проект проходит состояния, когда «проекта еще нет» до момента, когда «проекта уже нет». В рамках проектного управления принято выделять состояния проекта, в которых он пребывает в течение своего жизненного цикла. Как говорят, прoект «Жизнь» делится на три фазы: когда ты веришь в Деда Мороза, когда ты не веришь в Деда Мороза, и когда ты уже сам Дед Мороз. Какие моменты принимать за начало проекта и его окончание зависит от участников проекта. Началом проекта могут быть такие события, как: начало выполнения работ по проекту, начало финансирования проекта, дата заключения договора, возникновение идеи, которая легла в основу проекта, предложение воплощения задуманной идеи другим участникам и т.д. Окончанием проекта можно считать: достижение поставленной цели, ввод в эксплуатацию, принудительное завершение проекта, расформирование команды проекта, дату окупаемости средств, вложенных в реализацию проекта, дату, когда закончились деньги на реализацию, и т.д. Жизненный цикл проекта (англ. Project Life Cycle) — это полная последовательность фаз проекта, задаваемая исходя из технологии производства работ и потребностей управления проектом. Такой жизненный цикл включает совокупность различных фаз. Каждая фаза существенно отличается от других не только содержанием и решаемыми задачами, но и методами управления. Замечание. Из чего состоит жизненный цикл: в источниках по управлению проектами обычно используют понятие «Фаза», а в стандартах по проектированию – «Этапы и стадии». В дальнейшем в лекции во избежание путаницы будем использовать термин «Фаза проекта». Выбор используемой терминологии в данном случае определен исключительно ее использованием в PMBoK. Фаза проекта – это набор логически взаимосвязанных работ проекта, в процессе завершения которых достигается один из значимых основных или промежуточных результатов проекта. Универсального подхода к делению жизненного цикла на фазы не существует. Количество, название и содержание фаззависят от ряда причин, в том числе, во многом определяются условиями осуществления рассматриваемого проекта, потребностями в управлении, прикладной областью проекта, опытом участников проекта. Например, прoект может быть разбит на фазы в зависимости от промежуточных результатов, определенных контрольных событий, доступности финансов и т.д. Никто не сможет дать однозначный ответ, что во всех предпринимательских или научно-исследовательских, или каких-либо других проектах нужно выделять строго 4 фазы или 5 фаз. Решение принимается для каждого проекта индивидуально. Проект по строительству загородного дома может состоять из следующих фаз: Инициация Инженерные изыскания Проектные работы Строительно-монтажные работы Пуско-наладочные работы Сдача объекта А для другого строительства дачи более удобным с точки зрения управления будет следующий вариант: Создание проекта для строительства частного дома Геодезические работы Общестроительные работы Устройство инженерных систем Отделочные работы Благоустройство территории Похожие проекты, а выделение фаз в проектах разное. Тем не менее, можно определить такую структуру жизненного цикла: инициирование; организация и подготовка; выполнение (реализация и контроль); завершение. Более подробно структуру ЖЦ рассмотрим далее. |