тест. ТЕСТ 3. Введение. Работа с заинтересованными лицами
 Скачать 64.6 Kb.
|
|
Введение. Работа с заинтересованными лицами Во время инициации проекта у заказчика и у команды формируется единое представление об ожидаемых результатах проекта. И шансы на успех проекта значительно вырастают, если эти представления совпадают. Но наличия одинакового образа результата еще недостаточно, чтобы уверенно утверждать, что и как именно должно быть сделано в течение проекта. Как говорят, «все дело в деталях». Нередка ситуация, когда к концу проекта выявляется требование, которое не было заранее учтено, а при этом является критично необходимым для пользователей. Например, сделали хоккейную коробку во дворе дома и не учли, что под ней проходит теплотрасса (см. фотографию в приложенной к лекции презентации). Или в итоге было сделано то, как объяснил Заказчик, а не то, что ему действительно было нужно. Например, Заказчик хотел справиться с очередями на кассу и предложил увеличить количество касс, что и было сделано, а на самом деле ему нужно было поставить рядом вендинговые аппараты. А ведь устранение проблем на этапе реализации обходится заметно дороже, чем тщательная проработка на этапе анализа. По мере выполнения проекта стоимость внесения изменений может возрасти в несколько, а то и в сотни раз! Поэтому процесс работы с требованиями является критичным для проекта. Давайте проанализируем, вообще кто или что является источником требований к продукту проекта? Откуда команде проекта понять, какие конкретно должны быть выполнены требования? Отвечаем: от Заказчика, пользователей, других людей и организаций. Для их обозначения используется термин – «Заинтересованные лица». Заинтересованные лица – это отдельные персоны, группы, организации, системы, которые активно вовлечены в проект, получают выгоду от реализации проекта, будут использовать результат проекта или чьи интересы затронет выполнение проекта. Неучтенные потребности заинтересованных лиц в основном появляются от того, что они не были выявлены заранее. Очевидное решение – надо проводить работу с заинтересованными лицами, начиная с самых ранних этапов проекта для необходимого понимания их интересов и потребностей. Чтобы проводить такую работу, хорошо бы сначала ответить на следующие вопросы: Кто является заинтересованными лицами? Чьи требования важнее? Как работать с различными группами заинтересованных лиц? С кем из них нужно работать в первую очередь? Попробуем разобраться в этих вопросах. Очевидно, что в первую очередь заинтересованными лицами являются клиенты: те, кто заказывает проект (это Заказчик) и те, кому предстоит пользоваться продуктом проекта (то есть Пользователи). Заказчик и пользователи априори максимально заинтересованы в проекте и являются источником большинства требований. Другими заинтересованными лицами могут быть: партнеры, конкуренты, потенциальные заказчики, производители используемого оборудования, органы власти и пр. А кто решает является ли конкретный человек, организация или система заинтересованным лицом? Это полностью находится в компетенции команды проекта. И тут хорошо бы соблюсти следующий баланс. Если команда не учтет кого-то из заинтересованных лиц и его требования – может возникнуть риск внесения существенных изменений и доработок на финальных стадиях проекта. А если метометдизбыточным составом заинтересованных лиц, то значительно увеличится трудоемкость и при этом, возможно, требования и интересы различных заинтересованных сторон нельзя будет удовлетворить одновременно, так как они с легкостью могут войти в противоречие друг другу. Какой тогда выход? Чтобы определить заинтересованных лиц, решить с кем из них и как можно работать, используйте инструмент «Матрица заинтересованных лиц». Эта Матрица служит для наглядного отображения множества выявленных заинтересованных лиц, а также степени их заинтересованности и влияния на проект. Она может быть представлена, например, в следующих координатах: интерес к проекту и степень влияния на проект (см. рисунок ниже). В зависимости от того, в каком квадранте матрицы находится заинтересованное лицо, и определяется стратегия работы с ним (на рисунке Заинтересованные лица, объединенные в группы, выделены одним цветом). Например, с некоторыми лицами вы будете активно взаимодействовать в течение всего проекта, а некоторых заинтересованных лиц достаточно будет извещать о полученных результатах. Естественно, что чем бОльшим влиянием и интересом обладает заинтересованное лицо (1-й квадрант), тем больше требуется уделять ему внимания: обсуждать ход проекта, согласовывать основные действия. С теми, кто мало заинтересован в проекте и не обладает особым влиянием (3-й квадрант), достаточно минимального взаимодействия, чтобы не тратить время и силы, например, оповещать о ключевых результатах или завершении проекта. Требования в проекте Что же требуется еще прояснить, чтобы в представлении о целях и результатах проекта появилась определенность? Этими деталями, вносящими определенность в ожидания, являются требования. Требования позволяют конкретизировать и детализировать ожидания различных групп заинтересованных сторон, отражают различные точки зрения на результат проекта. Проработка требований позволяет проверить образ результата на полноту и непротиворечивость, а также зафиксировать все необходимые потребности. Требование – это условие, которому должен соответствовать, или характеристика, которую должен иметь результат проекта в соответствии с договором или другой формально предписанной спецификацией. Например, для проекта по организации выставки научно-технического творчества в мастерской Фаблаб требованиями могут быть: выставка должна быть проведена в выходные дни; обеспечить количество экспонатов в количестве не менее 30 штук; приглашения разослать не менее чем за месяц до начала и т.д. Требoвания включают в себя потребности и ожидания Спонсора, Заказчика и прочих заинтересованных лиц. Они должны быть задокументированы со степенью детализации, достаточной для того, чтобы вы могли на их основе построить план работ и бюджет проекта. Разработка требованийк результату проекта, в зависимости от сути проекта,может выполняться сразу и полностью или же последовательно, по частям (например, когда используются гибкие подходы к управлению проектом, о которых будет рассказано в одной из следующих лекциях). Итак, должным образом проработанные требования позволяют: выработать общее понимание между Заказчиком и Исполнителем; более точно определить финансовые и временные характеристики проекта; обезопасить Заказчика от риска получить продукт, который ему не нужен; обезопасить Исполнителя от риска попасть в ситуацию со значительным увеличением затрат. Управление требованиями – это систематический подход к выявлению, организации и документированию требований к продукту проекта, а также установка и поддержание соглашения между заказчиком и исполнителями по поводу изменений требований к продукту. Какие бывают требования? Существует различные классификации требований к продукту проекта. Одной из часто используемых классификаций является разделение по уровню детализации: Бизнес-требования содержат высокоуровневые цели Заказчика проекта, определяют назначение продукта проекта. Например, для уже упомянутого проекта по организации выставки таким требованием может быть: привлечь не менее 200 посетителей. Требования пользователейописывают задачи, которые должен решать продукт проекта с точки зрения пользователя (что пользователи могут делать с его помощью). Например, напомнить зарегистрированным пользователям о мероприятии за один день до начала; организовать кофе брейк в течение дня. Требования исполнителей определяют функциональность и характеристики продукта, которые должен выполнять продукт проекта, чтобы реализовать бизнес-требования и требования пользователей. Например, у каждого экспоната должно быть свое освещение; должна быть организована электронная регистрация с автоматической рассылкой оповещений. Другая классификация – пу требований: Функциональные требoвания – требoвания к поведению продукта проекта, отвечают на вопрос «что он должен делать» в тех или иных ситуациях. Нефункциональные требoвания – требoвания к характеру поведения продукта проекта, определяют свойства продукта, т.е. как он должен работать. Применительно к этому типу требований часто говорят о показателях качества[1] продукта и об ограничениях продукта. [1] Согласно стандарту ГОСТ 15467-79 под качеством понимается совокупность свойств продукции, обуславливающих ее пригодность удовлетворять определенные потребности в соответствии с ее назначением. А под показателем качества продукции – количественная характеристика одного или нескольких свойств продукции, входящих в ее качество, рассматриваемых применительно к условиям ее создания и эксплуатации или потребления. ыделяют различные свойства требований, приведем основные из них: Ясность (понятность) – требoвание однозначно понимается Заказчиком и исполнителями. Для этого они должны быть написаны достаточно просто, логично и точно. Например, требование «экспонаты должны соответствовать заявленной тематике выставки и выставлены в трех залах» лучше разделить на два. Полнота и единичность – требoвание описывает одну и только одну характеристику, содержит всю необходимую информацию для исполнителей. Трассируемость (прослеживаемость) – требoвание не противоречит другим требованиям, полностью соответствует остальной документации. Выполнимость – требoвание может быть реализовано в пределах проекта. Проверяемость (тестируемость) – существует возможность проверить реализованные требования, например, одним из следующих методов: тест, анализ, осмотр. К примеру, требование «чтобы экспонаты были красивыми» – явно не отвечает этому требованию, а вот «экспонаты должны быть разработаны резидентами Фаблаба» уже проверяемо. Источники требований Практика показывает, что хорошие требования начинаются с хороших первоисточников. При этом источники зависят от специфики проекта и контекста предполагаемого использования продукта проекта. Помимо Заказчика и пользователей в качестве источников требований обратите внимание на: Пользователей продукта (явных и потенциальных), их представления и ожидания. Обслуживающий и технический персонал. Нормативные документы: законодательство, нормативное обеспечение организации (регламенты, положения, приказы). Экспертов в предметной области проекта. Журналы и отчеты об использовании существующих систем, устройств, процессов. Конкурирующие (аналогичные) продукты, а также их исполнители. Наблюдения за работой пользователей на их рабочих местах. Маркетинговые исследования, опросы, статистические выборки. Отчеты об ошибках, жалобы, запросы на усовершенствование. Системы, продукты, с которыми необходимо обеспечить интеграцию, и т.д. Методы выявления требований Для выявления требований используются различные методы. Спрашивать у пользователей «Что вы хотите?» бесполезно, в подавляющем большинстве случаев не смогут внятно описать свои пожелания. Поэтому для того, чтобы собрать наиболее качественные требования, рекомендуется сочетать между собой несколько методов. Рассмотрим основные методы выявления требований: Интервью: используется для получения информации у заинтересованных сторон через беседу с ними. Многое можно узнать, например, пообщавшись с командой сопровождения (техподдержкой) текущей системы или продукта. Умение задавать вопросы – это полезный навык, который может оказать неоценимую поддержку в работе. После каждого интервью рекомендуется документировать полученную информацию и отправлять на проверку респонденту. Анкетирование: позволяет быстро собрать информацию у большого числа респондентов. Важно грамотно составить вопросы и хорошо оформить анкету, чтобы ее было удобно заполнять. Фокус-группы: предназначены для проведения встречи заинтересованных сторон и экспертов по предметной области, чтобы узнать их ожидания и отношение к предложенному проекту. Наблюдения: позволяют вникнуть в обстановку, непосредственно увидеть, как проходит процесс и выполняется сотрудником работа; изучить на месте улучшения, сделанные пользователями. Это особенно полезно в случае, когда заинтересованное лицо не может отчетливо изложить свои требования. Методы группового творчества (мозговой штурм, диаграммы сходства и т.д.): предназначены для совместной генерации и отбора лучших идей, связанных с требованиями к проекту. Бенчмаркинг: используется для выявления лучших практик, изучения аналогичных продуктов. Анализ документов: необходим для выявления требований путем анализа существующей документации, в том числе для исследования отчетов о проблемах и жалоб. Прототипы: предназначены для демонстрации заинтересованным сторонам рабочей модели ожидаемого продукта и получения предварительных отзывов относительно требований. Шаги по разработке требований Обобщенный алгоритм разработки требований включает: Выявление требований. Анализ требований. Документирование требований. Проверка требований. Стоит сразу отметить, что редко, когда данные шаги делаются последовательно. По своей сути, это итерационный процесс: шаги чередуются и периодически повторяются. Рассмотрим каждый шаг подробнее. 1. Выявление требований к результату проекта – самый сложный шаг в процессе разработки требований. От того, насколько точно, полно и достоверно собраны требования, зависит реализация всего проекта. Хоть выявление требований – это творческий процесс, но есть ряд методов, которые помогут вам собрать требования (приведены на предыдущей странице). На данном шаге рекомендуется пользоваться предварительно созданным планом выявления требований. Он существенно повышает эффективность выявления, делает процесс более осознанным и направленным. План может состоять из следующих разделов: Что хотите узнать: перечисление целей выявления требований. Где хотите узнать: перечисление источников. Как будете узнавать: используемые методы, мероприятия. Что хотите получить: список предполагаемых документов, результатов. Когда хотите узнать: назначение исполнителей. Как понять, что требований уже достаточно? Полностью выявить требования к продукту проекта практически невозможно, однако можно выделять ряд признаков, которые могут указать, что пора переходить на следующий шаг – проводить анализ требований: заинтересованные стороны говорят о проблемах, которые уже были обсуждены и зафиксированы; информация из различных источников стала повторяться; заинтересованные стороны стали предлагать новые характеристики, функции, которые явно выходят за рамки текущего проекта; заинтересованные стороны стали предлагать новые способы решения их задач, однако команда проекта уже приняла решение, каким образом будут реализовываться данные задачи. 2. Анализ требований имеет своей целью получение понятных и непротиворечивых требований, на основе которых можно проектировать и реализовывать продукт проекта. Поскольку в проект невозможно включить все выявленные требования, во время процесса анализа отбираются окончательные требования к проекту. Какие действия происходят на данном шаге: Сформулируйте полученную информацию в виде требований с такой степенью подробности, которая будет понятна исполнителям. При необходимости уточните требования; выявите вторичные требования, логически проистекающие из запросов пользователей; определите невысказанные ожидания; исключите конфликтующие и дублирующие требования. Проанализируйте осуществимость заявленных требований; рассмотрите риски, связанные с реализацией каждого требования, включая зависимость от внешних факторов и препятствия технического характера. Определите совместно с Заказчиком их приоритеты и сроки реализации. Выбор средств анализа зависит от типа проекта, количества и взаимосвязанности требований. Для небольших проектов достаточно составить список требований в Word и проанализировать его. Для средних и больших проектов требования удобно анализировать и описывать с помощью моделей требований. К наиболее часто используемым моделям обычно относят методы анализа бизнес-процессов, объектно-ориентированного анализа и структурного анализа. В том числе используются методологии графического моделирования: ER (IDEF1FX), IDEF0, IDEF3, DFD, UML, eEPC и др. 3. Документирование требованийпроисходит обычно параллельно с процессом анализа требований. Может сначала происходить высокоуровнево, а затем постепенно детализироваться по мере поступления новой информации. В зависимости от проекта формат документа с требованиями может варьироваться: от реестра требований – простого документа, перечисляющего все требования, отсортированные по приоритету; до полноценного технического задания – более тщательно проработанного описания, содержащего технические решения. Требования могут документироваться при помощи текстового описания или в виде графических диаграмм. Важно, чтобы требования были сформулированы на понятном языке для Заказчика, иначе он не сможет адекватно оценить, то ли ему нужно получить в итоге. Помимо описания документ с требованиями может включать в себя: Критерии приемки результата проекта: набор условий, по которым Заказчик будет оценивать результаты проекта, порядок проведения приемки работ. Ограничения и исключения из проекта: сформулировано то, что ограничивает выполнение проекта, что находится вне содержания текущего проекта, например предопределенный бюджет, ограничивающие даты. Данный раздел помогает управлять ожиданиями заинтересованных сторон. Приведем некоторые из рекомендаций к формулированию требований: Абзацы и предложения должны быть краткими и ясными. Используйте термины так, как они определены в словаре, желательно не использовать синонимов и близких по значению слов. Применяйте визуальное представление информации: списки, таблицы, графики, диаграммы и рисунки. 4. Проверка требований. После того, как требования собраны, проанализированы и задокументированы, необходимо проверить качество разработанных документов. В такой проверке участвуют как представители команды проекта, так и представители Заказчика, в том числе, эксперты в предметной области. Проверка заключается в поиске предметных неточностей, противоречий, недостающих сведений, оценке реализуемости. После проверки и исправления замечаний утверждите документ у Заказчика и смело приступайте к реализации проекта. Определения и понятия Какие бы явления, события или процессы в природе и в обществе мы бы не стали рассматривать, все они проходят путь от момента своего зарождения до завершения. И в своем развитии они последовательно сменяют свои состояния, или фазы, требующие соответственно разных подходов к управлению, к реализации. Во многих случаях такой путь называют жизненным циклом. Понятие жизненного цикла применимо и к проекту. Любой проект проходит состояния, когда «проекта еще нет» до момента, когда «проекта уже нет». В рамках проектного управления принято выделять состояния проекта, в которых он пребывает в течение своего жизненного цикла. Как говорят, прoект «Жизнь» делится на три фазы: когда ты веришь в Деда Мороза, когда ты не веришь в Деда Мороза, и когда ты уже сам Дед Мороз. Какие моменты принимать за начало проекта и его окончание зависит от участников проекта. Началом проекта могут быть такие события, как: начало выполнения работ по проекту, начало финансирования проекта, дата заключения договора, возникновение идеи, которая легла в основу проекта, предложение воплощения задуманной идеи другим участникам и т.д. Окончанием проекта можно считать: достижение поставленной цели, ввод в эксплуатацию, принудительное завершение проекта, расформирование команды проекта, дату окупаемости средств, вложенных в реализацию проекта, дату, когда закончились деньги на реализацию, и т.д. Жизненный цикл проекта (англ. Project Life Cycle) — это полная последовательность фаз проекта, задаваемая исходя из технологии производства работ и потребностей управления проектом. Такой жизненный цикл включает совокупность различных фаз. Каждая фаза существенно отличается от других не только содержанием и решаемыми задачами, но и методами управления. Замечание. Из чего состоит жизненный цикл: в источниках по управлению проектами обычно используют понятие «Фаза», а в стандартах по проектированию – «Этапы и стадии». В дальнейшем в лекции во избежание путаницы будем использовать термин «Фаза проекта». Выбор используемой терминологии в данном случае определен исключительно ее использованием в PMBoK. Фаза проекта – это набор логически взаимосвязанных работ проекта, в процессе завершения которых достигается один из значимых основных или промежуточных результатов проекта. Универсального подхода к делению жизненного цикла на фазы не существует. Количество, название и содержание фаззависят от ряда причин, в том числе, во многом определяются условиями осуществления рассматриваемого проекта, потребностями в управлении, прикладной областью проекта, опытом участников проекта. Например, прoект может быть разбит на фазы в зависимости от промежуточных результатов, определенных контрольных событий, доступности финансов и т.д. Никто не сможет дать однозначный ответ, что во всех предпринимательских или научно-исследовательских, или каких-либо других проектах нужно выделять строго 4 фазы или 5 фаз. Решение принимается для каждого проекта индивидуально. Проект по строительству загородного дома может состоять из следующих фаз: Инициация Инженерные изыскания Проектные работы Строительно-монтажные работы Пуско-наладочные работы Сдача объекта А для другого строительства дачи более удобным с точки зрения управления будет следующий вариант: Создание проекта для строительства частного дома Геодезические работы Общестроительные работы Устройство инженерных систем Отделочные работы Благоустройство территории Похожие проекты, а выделение фаз в проектах разное. Тем не менее, можно определить такую структуру жизненного цикла: инициирование; организация и подготовка; выполнение (реализация и контроль); завершение. Более подробно структуру ЖЦ рассмотрим далее. Зачем нужен жизненный цикл? Жизненный цикл прежде всего нужен для удобства управления проектом, а именно: Чтобы зафиксировать и понимать общий план мероприятий по проекту и его общую последовательность. Чтобы на каждой фазе использовать свое управление, своевременно принять взвешенное управленческое решение: идем дальше или нет. По результатам выполнения каждой из фаз может приниматься решение о целесообразности продолжения проекта. Чтобы на каждой фазе контролировать свои цели. Чтобы на каждом фазе фиксировать свой результат. Структура жизненного цикла Приведем основные задачи, которые могут решаться на выделенных фазах проекта. Напомним, что наполнение фаз проекта сильно зависит от сущности проекта. Часто жизненный цикл путают с группами процессов управления проектом: инициация, планирование, выполнение, мониторинг и контроль, завершение. Эти группы процессов управления могут присутствовать на каждой фазе проекта. Инициирование. Происходит формальный старт проекта и определяется видение проекта. Содержание работ на этой фазе включает: Анализ проблемы. Формирование бизнес-идеи. Постановка цели проекта. Формулирование образа продукта проекта. Назначение руководителя проекта. Принятие решения о начале проекта. Организация и подготовка. Осуществляется подготовка к реализации проекта, проводятся организационные мероприятия. Содержание работ на этой фазе включает: Формирование команды проекта. Определение основных требований, ограничений. Определение требуемых материальных и трудовых ресурсов. Определение бюджета проекта. Разработка основного содержания проекта. Определение средств коммуникации участников проекта и контроля над ходом работ. Формирование плана управления проектом. Выполнения (реализация и контроль). Происходит выполнение работ, необходимых для достижения цели проекта. Основное содержание: Непосредственное выполнение работ проекта. Оперативное планирование работ. Организация и управление материально-техническим обеспечением работ. Координация работ, оперативный контроль и регулирование основных показателей проекта. Завершение. Проводятся мероприятия по формальному закрытию проекта. В зависимости от содержания проекта основные виды работ включают: Комплексные испытания. Сдача результата проекта Заказчику и ввод в эксплуатацию. Оценка результатов проекта и подготовка итоговых документов. Разрешение конфликтных ситуаций и закрытие работ по проекту. Реализация оставшихся ресурсов. Анализ опыта для последующих проектов. Расформирование команды проекта. Приведенная выше структура жизненного цикла проекта – высокоуровневое представление, которое обеспечивает единую систему отсчета при сравнении проектов, даже если они разнородны по своей природе. Виды жизненных циклов проектов Фазы проекта могут выполняться не только последовательно, но и в некоторых проектных ситуациях могут перекрываться. Существуют ситуации, когда проект может только выиграть от использования перекрывающихся или параллельно идущих фаз. При этом в одном проекте между различными фазами могут применяться разные связи (перекрывающиеся, последовательные, параллельные). Выбор типа связи между фазами зависит, например, от требуемого уровня контроля, степени неопределенности. Последовательная: Со всеми типами связи: Рассмотрим четыре вида жизненных циклов проектов, использующие разные типы связи. Иллюстрации моделей приведены в презентации к данной лекции. Водопадная каскадная модель – последовательное выполнение фаз проекта с четким определением границ между фазами, на которых результаты предыдущей фазы и набор документов, созданный на предыдущей фазе, передаются в качестве входных данных для следующей фазы проекта. Возвратная водопадная модель – это модель, предусматривающая возврат к предыдущим фазам жизненного цикла проекта в случае объективной необходимости. Итеративная модель (англ. iteration — повторение) – последовательность фаз-итераций, в рамках каждой из которых происходит один и тот же (или почти один и тот же) цикл действий. Создание начинается с реализации части функционала, становящейся базой для определения дальнейших требований. Этот процесс повторяется. В данной модели можно быстро увидеть всю картину (недоделанную, но всю). Используется, когда основной функционал (основное назначение) продукта определен, но детали реализации могут эволюционировать с течением времени. Иллюстрацией для этой модели может служить процесс создания картины: сначала это эскиз, набросок карандашом, затем добавляются цвета, тени, и через несколько итераций получается задуманная картина. Инкрементная модель– это итеративная модель с отличием в том, что в результате каждой итерации получается работоспособный продукт. По сути цикл разделен на более мелкие модули. С каждой последующей итерацией осуществляется добавление, дальнейшее развитие продукта. Используется, когда, например, требуется ранний вывод продукта на рынок, когда есть несколько рисковых требований. Иллюстрацией для этой модели может служить процесс создания картины «Утро в Сосновом лесу»: сначала Иван Шишкин нарисовал лес, а затем уже Константин Савицкий дорисовал медведицу и трех медвежат. Можно сказать, две картины в одной. Когда какая модель предпочтительна? Водопадные модели, как правило, являются предпочтительными, когда требования и способы их реализации максимально четко определены и понятны; используется неизменяемое видение продукта; если продукт необходимо предоставить полностью для того, чтобы он имел ценность для заинтересованных сторон проекта. Итеративные и инкрементные жизненные циклы обычно используются, когда цели и содержание могут меняться во времени, когда необходимо уменьшить сложность проекта (содержание проекта трудно определить заранее) или если частичная поставка продукта является выгодной и представляет ценность для заинтересованных сторон. Вообще, применение итеративного подхода подразумевает, что команда проекта владеет определенными коммуникационными навыками, способна к самоорганизации. Поэтому для малопытных команд, в частности реализующих учебные проекты, предпочтительнее начинать анализировать проект с точки зрения водопадной модели. Значимость плана для управления Когда вы гуляете не спеша, вы можете выбрать любую дорогу и посмотреть, куда она вас приведет. Однако, когда вы отправляетесь в командировку и едете в аэропорт, вам лучше понимать, как туда добраться вовремя. Независимо от того, насколько вы будете быстро ехать, если вы выбрали не тот путь или перед вами внезапно развели мосты, вы не сможете добраться к назначенному времени. Если вы хотите все же улететь, вам нужно запланировать, как вы собираетесь добраться и с тем, что вы должны с собой взять. Плaн проекта – это дорожная карта, которая приведет вас к пункту назначения. Чем меньше времени, денег или ресурсов у вас есть, тем более внимательно вам нужно планировать. Планирoвание проекта схоже с планированием других мероприятий – выясняется, что необходимо сделать, прежде чем это сделать. Как и многое вокруг нас, планы проектов обречены на изменение. Однако несмотря на неизбежность изменений, наличие плана проекта позволит вам быть у руля и направлять прoект в нужную сторону. Успех реализации проекта во многом зависит от того, как он был спланирован. Зачастую причиной неудачи проекта, выхода проекта за рамки плановых сроков и бюджета является то, что на этапе планирования не были учтены (включены в план) те или иные работы, которые «появились» во время реализации (выполнения) проекта и потребовали дополнительных затрат. Появление новых, незапланированных работ является одним из существенных рисков проекта. Планирование – это процесс определения наилучшего способа действий для достижения поставленных целей с учетом складывающейся обстановки. Что планируем (объекты планирования)? Планирование проекта нацелено на разработку плана управления проектом, который содержит информацию: почему проект необходимо выполнять и как команда проекта собирается это сделать. План управления проектом (англ. Project Management Plan) – утвержденный документ, в котором указано, как проект будет исполняться, как будет происходить его мониторинг и контроль и управление проектом, как проект будет завершен. Итак, на какие вопросы может ответить план управления проектом: В чем проблема, которую нужно решить, или возможность, которую хочется использовать? Другими словами, почему команде проекта стоит взяться за данный проект. Ответ на описывает существующую проблему, на решение которой будут затрачены силы. Каких целей нужно достичь и какая стратегия для решения поставленной проблемы подходит наилучшим образом? Стоит знать, чего должен достичь проект, чтобы понять, как и когда это будет сделано. Зачастую указанные проблемы имеют более одного решения. В плане проекта описывается стратегия, которая была выбрана для решения проблемы. Как понять, успешный ли проект? В плане проекта описываются критерии успеха, которые будут использованы, чтобы судить о приемлемости результатов, и на которые Заказчик будет ссылаться во время приемки результатов проекта. Что мы будем делать и кто будет это делать? Основываясь на выбранной стратегии, в плане проекта описывается, какие задачи должны быть для этого решены. В том числе должны быть определены границы проекта, чтобы заинтересованные стороны знали, чего стоит ожидать, а чего нет. На поставленные задачи назначаются ресурсы, с помощью которых они будут выполняться. В том числе внутри команды распределяется ответственность за выполнение проекта. Как будем управлять проектом? При управлении проектом есть сопутствующие мероприятия, о которых не стоит забывать: выявление рисков проекта, внесение изменений, организация коммуникаций внутри команды и др. Все это при необходимости описывается в плане управления проектом. Сколько это будет стоить и какие ресурсы необходимы? Обычно в проектах не обойтись без бюджета. Для реализации проекта необходимы какие-либо ресурсы (материальные, технические и др.), о которых стоит упомянуть в плане проекта. Естественно, что объем и содержание плана управления проектом напрямую зависит от параметров проекта, опыта команды проекта, требований со стороны Заказчика. Представим ситуацию: вы вдвоем выполняете небольшой проект. В этом случае вам будет достаточно только зафиксировать видение продукта, обсудить перечень работ и настроить коммуникации. Иначе разработка большого плана управления проектом пойдет только во вред, сместит фокус внимания, отвлечет от непосредственного выполнения работ. Плaнирование проекта – это процесс, который длится практически в течение всего проекта, а никак не разовое мероприятие. В зависимости от выбранного вида жизненного цикла (водопадный, итеративный или инкрементный) основное планирование происходит в начале проекта или для каждой итерации в отдельности. В любом случае, после того, как началось выполнение задач по проекту, будут появляться изменения, которые потребуют доработки плана. Календарный план проекта Одним из важных элементов плана управления проектом является календарный план проекта (иногда еще его называют расписанием работ проекта, план-графиком проекта, календарным графиком и т.д.). В контексте данной лекции термины «работа» и «задача» являются синонимами. Календарный плaн проекта (англ. Project Schedule) – перечень планируемых работ проекта со сроками исполнения и ответственными лицами, подготовленный в утвержденной форме. По сути, календарный плaн работ отражает, какие задачи должны быть выполнены, когда и с помощью каких ресурсов. Для чего нужен календарный план? Основными причинами являются: Чтобы не забыть что-то существенное во время выполнения проекта. Чтобы команда проекта видела, какие работы нужно делать сейчас. Чтобы любой член команды понимал, как влияет выполняемая им работа на весь проект. Чтобы оценить сроки выполнения проекта, потребность в ресурсах. При разработке календарного плана могут использоваться два следующих метода: Декомпозиция – это метод, суть которого заключается в последовательном уточнении задач проекта путем разделения их на подзадачи, на более мелкие и более управляемые. Участие членов команды в процессе декомпозиции может привести к получению лучших и более точных результатов. Разделение задач на подзадачи производится обычно до тех пор, пока получившаяся структура задач не станет легко управляемой и контролируемой. Например: – когда после очередного шага уточнения на задачу может быть назначен один исполнитель, – когда длительность задачи будет такой, что в процессе осуществления проекта возможен эффективный контроль выполнения. Планирование методом набегающей волны — это метод итеративного планирования, при котором задача, которую надо будет выполнить в ближайшей перспективе, планируется подробно, в то время как далеко отстоящая задача планируется с меньшей степенью детализации. Это одна из форм последовательного уточнения. Таким образом, работа может существовать на разных уровнях детализации в зависимости от того, на какой стадии жизненного цикла проекта она находится. В методе декомпозиции мы сразу пытаемся разделить весь объем работ на кусочки, а в методе набегающей волны – это делаем постепенно. Подобное содержание проекта представляют часто в виде иерархической структуры работ (ИСР) проекта. Иерархическая структура работ (англ. Work Breakdown Structure) – это представление результатов и работ проекта в структурированном виде, необходимое и достаточное для эффективного осуществления процесса управления проектом. Важно: результаты и работы, которые не входят в ИСР, находятся за рамками проекта! ИСР может состоять из следующих уровней: весь проект в целом – высший уровень иерархии; фазы проекта – второй уровень иерархии (крупные результаты проекта); группы работ проекта – третий уровень иерархии; работы проекта – четвертый уровень иерархии (или последующий, если третий уровень был также разбит на группы работ). Детализацию работ следует прекратить на том уровне иерархии, на котором можно назвать конкретного исполнителя, указать длительность, оценить ее трудоемкость и затраты. Шаги по разработке календарного плана Разработка календарного плана обычно включает в себя ряд шагов, последовательность которых может меняться в зависимости от предпочтений планировщика: 1. Построение иерархической структуры работ. На данном шаге определяются задачи, которые должны быть выполнены для достижения цели проекта. ИСР может строиться: – «сверху-вниз», когда постепенно детализируется каждая фаза проекта, – «снизу-вверх», когда сначала выявляются работы, а затем они группируются в более крупные блоки, – оба подхода вместе. 2. Определение последовательности работ. Для выстраивания логической последовательности выполнения работ используются связи между задачами. Существуют разные варианты связей между задачами. Примеры вариантов связей между задачами: – Мы не можем построить второй этаж, пока не построили первый; – Мы не можем запустить опрос, пока не сформировали перечень вопросов; – Мы не можем начать раздавать билеты на мероприятие, пока не запустили рекламную кампанию; – Подготовка декораций должна быть закончена до окончания репетиций. Связь между двумя задачами позволяет понять, каким образом время начала или завершения одной задачи влияет на время начала или завершения другой. Иногда такую последовательность называют сетевым графиком проекта. 3. Определение временных параметров проекта. Для каждой работы задаются ее временные характеристики: длительность, трудозатраты, дата начала или дата завершения. Даты должны быть согласованы с календарем, в том числе, должны быть учтены выходные, праздники, рабочее время команды проекта. При использовании информационных систем планирования даты начала и завершения задачи рассчитываются автоматически, в зависимости от установленных связей между задачи и длительностью задачи. Под трудозатратами понимается количество рабочего времени, необходимого для выполнения работы. Измеряются в человеко-часах. Например, если два сотрудника в течение трех рабочих дней (считаем, что в рабочем дне 8 часов) готовили презентацию для финального выступления, то трудозатраты будут равны 16 чел.час. Существуют задачи – вехи, которые обладают нулевой длительностью, однако их использование помогает в управлении проектом. Веха (контрольное событие, майлстоун, milestone) – ключевое (важное) событие или дата в ходе осуществления проекта, используемая для отображения состояния завершенности тех или иных работ. Примеры вех: техническое задание утверждено, запуск в эксплуатацию, помещение подготовлено для начала ремонта. 4. Назначение ресурсов на работы. На выявленные работы назначаются трудовые ресурсы – исполнители. При этом должен быть учтен график рабочего времени исполнителя. Помимо трудовых ресурсов на задачи назначают при необходимости материальные ресурсы (машины, станки и т.д.). 5. Оценка затрат, разработка бюджета. На данном шаге рассчитывается стоимость проекта на основании разработанного плана, анализируется его обеспеченность финансовыми средствами. 6. Анализ плана проекта. После того, как календарный план был построен, необходимо его проанализировать на предмет: все ли задачи, ресурсы были учтены, правильно ли расставлены связи, не завышены/занижены ли трудозатраты, соответствует ли срок ожиданиям Заказчика. Хорошим календарным планом проекта является план, который, с одной стороны, не содержит излишних подробностей, а с другой стороны, является достаточно подробным, позволяющим контролировать процесс осуществления проекта. То есть такой план, который является четким и ясным, при этом не является излишне подробным. Планы разрабатывают не ради самих планов, а для того чтобы достигать целей Формы представления календарного плана Календарный план проекта может быть представлен в форме таблицы, однако чаще всего используется графическое представление в виде линейчатых диаграмм, а именно диаграммы Ганта. Диаграмма Ганта – работы перечислены на вертикальной оси, даты приведены на горизонтальной оси, а длительности работ показаны в виде горизонтальных полос, расположенных в соответствии с датами начала и окончания. Линейчатые диаграммы сравнительно легко читаются и часто используются для представления информации заинтересованным сторонам. Другой распространенный вариант представления плана работ – канбан-доска. Слово "Канбан" в переводе с японского обозначает «визуальный, карточка, доска». На ней задачи отображаются в виде карточек, а весь процесс выполнения разбивается на этапы. По мере выполнения карточки перемещают слева направо. В большинстве случаев для составления календарного плана проекта используется специальное программное обеспечение, например, Microsoft Project, Oracle Primavera, OpenProj, Trello и др. Конец формы |