Схема руководство проектом

Даже если человек не имеет никакого отношения к менеджменту, он сталкивается с проектами каждый день. Проект — это процесс получения нового продукта или уникального результата. Строительство нового жилого дома, поездка в отпуск, покупка новой пары обуви и организация ужина — всё это проекты. Проект начинается с замысла и постановки цели, а заканчивается результатами.

Структура проекта — это инструмент, который поможет достигать цели проектов с минимальными затратами времени и денег.

В статье расскажем, что такое структура проекта и для чего она нужна. На примере разберём, как пошагово разработать структуру проекта и какие методики для этого использовать.

Структура проекта — система элементов проекта, необходимых для того, чтобы эффективно им управлять. К элементам относятся:

• цели проекта и результаты, которых нужно достичь;
• бюджет проекта и график финансирования;
• команда проекта и матрица распределения ответственности между исполнителями;
• задачи проекта и график их выполнения;
• матрица рисков проекта и план их минимизации.

Задача структуры проекта — настроить все процессы так, чтобы главная цель была достигнута с оптимальным соотношением цены, времени и качества. Для каждого проекта можно сделать приоритетными только два фактора из трёх. Сделать быстро, качественно и дёшево в одном проекте не получится — нужно решить, что важнее, но при этом стремиться к тому, чтобы сбалансировать эти факторы.

Мы будем изучать структуру проекта на примере — нашим проектом будет подготовка семейного ужина. Представим, что ужин хотят устроить дёшево и быстро. Тогда снизится качество: на столе окажутся простые блюда из некачественных ингредиентов.

Если делать качественно и быстро, вырастет стоимость: придётся заказать доставку блюд из ресторана или заплатить повару. Если делать дёшево и качественно, проект потребует больше времени: все блюда нужно будет готовить самостоятельно.

Структура проекта нужна, чтобы определить приоритеты проекта и правильно сбалансировать их. Ниже на примере разберём, как составить структуру проекта в семь этапов.

Выделяют семь основных шагов для создания структуры проекта. Каждый шаг — это ответ на вопрос.

Шаг 1. Что делаем и зачем? С этими вопросами поможет разобраться интеллект-карта «Дерево целей». На ней отмечают основную цель проекта и все задачи, которые нужно выполнить, чтобы её достичь. Затем к каждой задаче прописывают подзадачи, к каждой подзадаче — подзадачи второго уровня и так далее. Получается дерево, где в центре расположено общее, а по краям частное, как на рисунке ниже.

В нашем примере конечная цель — организовать званый ужин. Задачи — приготовить все блюда, навести порядок, накрыть на стол. Следующий уровень задач — приготовить отдельные ингредиенты, помыть пол и вытереть пыль, подготовить скатерть, посуду.

Дерево целей стоит делать подробным. Тогда объяснить участникам проекта их задачи будет проще. Команда будет вовлечена в проект и сильнее мотивирована.

Шаг 2. Как сделать? На этом этапе нужно разобраться, в какой последовательности будут выполнены задачи и подзадачи. Кроме того, нужно определить взаимосвязи между ними. Например, сначала сварить яйца, потом их почистить и уже потом нарезать. Здесь пригодится составленная интеллект-карта.

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

Шаг 3. Когда сделать? На этом этапе нужно подготовить график выполнения работ со сроками. Это поможет сделать уже составленная сетевая модель.

Сначала длительность работ определяют на основе своего опыта или экспертного мнения коллег. Затем ещё раз проверяют, насколько сроки реальны: для этого сопоставляют объёмы работ с числом участников и временем, которое они будут посвящать проекту.

Может оказаться, что один из этапов проекта займёт больше времени, потому что в команде не хватает исполнителей. Лучше это выяснить в начале проекта, пока не поздно что-то предпринять: перебросить людей с одних задач на другие или договориться о сверхурочной работе.

Вернёмся к нашему примеру: подготовка ужина займёт больше времени, если всё делать самостоятельно. Если с приготовлением некоторых блюд поможет подруга, то можно закончить работу в два раза быстрее.

Шаг 4. Кто сделает? На этом этапе внутри сформированной команды выделяют роли и распределяют обязанности. Если проект несложный, всё может сделать один исполнитель. В больших проектах роли чаще всего распределены между многими участниками.

В нашем примере это выглядит так: кто-то отвечает за составление меню, кто-то — за закупку продуктов, кто-то — за приготовление блюд, а кто-то — за уборку.

Распределить ответственность важно в начале проекта, чтобы в процессе не возникло соблазна изменить правила. Если правила нигде не закреплены, выполнение проекта может оказаться под угрозой.

Для распределения полномочий, ролей и управления отношениями в команде используют матрицу RACI. По вертикали выписывают перечень задач, по горизонтали — исполнителей. На их пересечении ставят буквы, которые означают степень ответственности:

• R (responsible) — ответственный за часть задачи или подзадачу. Например, ребёнок перед сбором гостей идёт в магазин за хлебом. Он не готовит блюда, но принимает участие в организации ужина.
• A (accountable) — ответственный за всю задачу полностью. Может делегировать подзадачи R-участникам. В нашем примере это подруга, которая отвечает за сервировку стола и отправляет ребёнка за хлебом.
• C (consult) — эксперт, который консультирует команду по вопросам, связанным с его компетенцией. Допустим, друг семьи знает уникальный рецепт блюда.
• I (informed) — участники, которые должны быть в курсе статуса работ. В нашем примере это гости. Если мы будем задерживать подачу ужина, нужно будет их об этом предупредить.

Шаг 5. Сколько стоит проект? На этом этапе составляют бюджет проекта. К нему важно приступать только после качественной проработки предыдущих пунктов. Нужно ещё раз вернуться к шагам 1–3 и задать вопрос: «Сколько это будет стоить?» Когда бюджет ограничен, лучше с самого начала выстраивать процессы, ориентируясь на максимальную сумму.

Если проект начинают выполнять без проработанной структуры, он может попасть в ловушку — внезапно выяснится, что на его завершение в срок с приемлемым качеством не хватает средств.

Если есть сомнения, нужно вернуться к шагу 1 и ещё раз задать вопросы: «Нам точно нужен этот проект? Какая у него цель?» Лучше остановить все процессы на этом этапе, чем вписаться в авантюру, потратить время, деньги и силы команды, а затем остановить проект на середине из-за нехватки бюджета. Это приведёт к тому, что команда потеряет мотивацию.

Шаг 6. А что, если?.. На этом этапе составляют матрицу рисков — один из важнейших элементов проработки структуры проекта. Нужно представить, что может пойти не так, и написать план защиты от рисков. Важно описать все сценарии, которые могут негативно повлиять на проект, затянуть сроки, увеличить бюджет, ухудшить результат.

Затем получившиеся сценарии обсуждают с командой. Это повышает уровень осознанности исполнителей. Кроме того, вся команда прорабатывает резервные планы. Так в ситуации цейтнота участники не будут тратить время на поиск решения — нужно будет просто запустить нужный протокол.

Все риски нужно заранее предусмотреть в графике и бюджете проекта. Например, если дома отключат свет, к приходу гостей ужина не будет. Или если мясо в духовке сгорит, придётся покупать и готовить его заново. На этот случай нужно оставить запас в несколько дополнительных часов и тысяч рублей.

Шаг 7. Начните всё заново. Важно повторить все шаги с первого по шестой минимум три раза. На втором и третьем круге структура проекта станет более подробной и прикладной — появится больше нюансов, которые до этого не учли. После этого нужно поправить все графики, изменить очерёдность работ, уточнить бюджет, перераспределить ответственных, доработать матрицу рисков.

Материалы, которые останутся после того, как команда пройдёт все семь этапов, не нужно класть в стол. Они должны стать инструментом для управления проектом. Возможно, на одном из этапов проект свернёт в сторону. Тогда сведения, с помощью которых можно будет принять взвешенное решение о его дальнейшей судьбе, будут под рукой.

Базовые варианты схем управления проектом

   Различают следующие варианты
схем управления проектом: «Основная»
система. Руководитель (менеджер)
проекта — представитель («агент»)
заказчика, финансовой ответственности
за принимаемые решения не несет. Им
может быть любое юридическое или
физическое лицо — участник проекта,
имеющее лицензию на профессиональное
управление. В этом случае менеджер
проекта обеспечивает координацию и
управление ходом разработки и реализации
проекта, в контрактных отношениях с
другими участниками проекта (кроме
заказчика) не состоит.
   Преимущество
системы — объективность проект-менеджера,
— ответственность за результаты проекта
целиком возлагается на заказчика.
   Система«расширенного управления».
Руководитель (менеджер) проекта —
принимает ответственность за проект в
пределах фиксированной (сметной) цены.
Менеджер обеспечивает управление и
координацию процессов проекта по
соглашениям между ним, заказчиком и
участниками проекта. Как и в «основной»
системе, им может быть любое юридическое
или физическое лицо — участник проекта,
имеющее лицо — участник проекта, имеющее
лицензию на профессиональное управление
и способное отвечать по своим обязательствам
перед заказчиком. Проект-менеджер
управляет проектом, координирует
поставки и работы по инжинирингу. В этом
случае ответственность возлагается на
менеджера проекта в пределах контрактных
условий.
   Система«под
ключ». Руководитель (менеджер)
проекта — проектно-строительная фирма,
с которой заказчик заключает контракт
«под ключ» с объявленной стоимостью
проекта.

      Примечания:
   *)
Группы процессов могут совмещаться во
времени;
   **) Классификация
разработана по материалам, размещенным
на сервере компании А-Ргоjесt.

Рис. 1.1.6. Классификация процессов
управления проектами

1.2. Зачем нужно управлять проектами

   Без преувеличения можно
сказать: в сегодняшней России происходят
наиболее масштабные изменения в
экономике, управления, укладе жизни.
Эти изменения не только масштабны, но
и беспрецедентны — ни в одной другой
стране мира за столь короткий срок не
происходила коренная ломка одной
экономической системы и формирование
другой.
   Такое многообразие
процессов, происходящих при этом, можно
представить как совокупность социальных,
технических, организационных, экономических
проектов. Если научиться этими проектами
управлять, а руководители, призванные
принимать решения, будут прислушиваться
к рекомендациям профессиональных
управляющих проектами, можно утверждать:
проводимые в стране реформы будут идти
успешнее.
   Вместе с тем
понятно, насколько сложно разработать
и реализовать на практике систему
управления, адекватную жизненным
реалиям.
   Поэтому было бы
преувеличением сказать, что методология
управления проектами является панацеей
от всех сбоев в механизме реформ.

   Отметим главные области
изменений в сегодняшней России, являющиеся
предпосылками применения и одновременно
потенциальной сферой интересов изучаемой
дисциплины:
    — ликвидация
планово-распределительной системы,
основанной на принудительном и волевом
администрировании, начало формирования
правовой системы регулирования;
   —
изменение отношений собственности
(разгосударствление предприятий и
организаций, акционирование, приватизация
и др.);
   — процесс демонополизации
производителей различного рода товаров
и услуг;
   — изменение рынка —
переход к относительному балансу
предложения и платежеспособного
спроса;
   — изменение
организационных форм (в соответствии
с изменениями отношений собственности
и рынка), сопровождающееся децентрализацией
управления и постепенной передачей
определенных функций на места;
   —
изменение производственной системы,
«подстраивающейся под рынок»;
   —
изменение методов и средств управления
— в частности, переход на идеологию
программного управления;
   —
отмена государственной монополии в
области внешней торговли;
   —
формирование рынка инвестиционных
проектов, недвижимости, ценных бумаг,
подрядных и других работ;
   —
создание рынка инвестиционных компаний,
инжиниринговых и консалтинговых фирм,
предлагающих свои услуги в области
экономической, управленческой,
информационной поддержки проектов;
   —
появление в инвестиционной сфере первых
проектно-ориентированных структур,
создаваемых как на основе государственных,
так и частных предприятий и компаний;
   —
определенные изменения в психологии
управленцев;
   — развитие новых
информационных технологий;
   —
активное привлечение к реализации
инвестиционных проектов иностранных
подрядчиков и инвесторов, которые
традиционно широко используют методологию
управления проектами;
   —
создание новых рыночных структур,
работающих с проектами (инвестиционные
фонды, финансовые компании, коммерческие
банки и др.), которые строят свою работу
на проектной основе.
   Объективно
возрастает сложность управления
экономикой в связи с увеличением числа
субъектов управления, усложнением их
действий, снижением уровня профессионализма
управленческого персонала. Современная
инвестиционная политика направлена на
финансирование проектов, реализуемых
в минимальные сроки и способных принести
максимальную прибыль. В таких условиях
новый метод становится проверенным
инструментом реализации любых проектов
необходимого качества, в установленные
сроки, в рамках принятого бюджета.
   Вместе
с тем, имеется ряд ограничений, существенно
сдерживающих распространение новой
методологии как для управления крупными
проектами, так и комплексными программами.
К ним относятся: общий спад производства
и неустойчивое функционирование
экономики; недостаточная политическая
стабильность (как дополнительный фактор
риска); резкое сокращение государственных
инвестиций и спад инвестиционной
активности; устойчиво высокая инфляция;
недостаточная развитость кредитно-финансовой
и банковской систем, сдерживающая оборот
инвестиций и капиталов; отсутствие
надежной системы обеспечения гарантий
и льгот для инвесторов — в том числе
иностранных.

Соседние файлы в папке Кн-ПАС

• #
• #
• #

Как управлять проектом? Самый простой пошаговый план для новичков

Сегодня я расскажу о самом простом плане работы с проектом от его начала до его завершения. Этот план отлично подойдет для новичков. Если вы еще не освоили Agile, не знаете всех инструментов и лучших практик, но проект сделать нужно, то эта статья для вас. 

Совсем немного введения

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

Как правило, до начала процесса разработки подготавливается описание основных, самых важных компонентов и достаточно поверхностно, некоторые детали могут быть описаны подробнее, при необходимости. Детализация требований происходит параллельно с процессом программирования и фиксируется, обычно, в ТЗ, а также в виде задач для команды. Такой подход позволяет на этапе инициации проекта достаточно быстро подготовить информацию по проекту, которую можно использовать в оценке проекта, а также дает большую гибкость в реализации проекта, так как требования имеют свойство меняться в процессе (закладываем на это время в оценке).

Итак, ниже я опишу материалы, которые необходимо подготовить для проекта, а также основные этапы работы над проектам от инициализации до запуска и что вам нужно делать на каждом из них. 

Для полноценного проектирования и детализации требований продукта необходимо подготовить следующее:

• Техническое задание, где мы описываем в текстовом виде и с помощью диаграмм все требования и детали проекта.

• Прототипы дизайна, где в общем виду показать какая информация будет размещаться на основных экранах

• Смета проекта, где указаны все виды работ на проекте и их оценка в человеко-часах или в днях, а также стоимость проекта

Из второстепенных материалов:

• Роадмап проекта, где указываем календарный план работ и майлстоуны

• Устав, который часто разрабатывается вместе с контрактом на этапе инициации и где указываем правила работы над проектом (полезная вещь, особенно в неопытных командах)

Ниже я буду описывать процесс работы над проектом, где опишу немного подробнее разработку материалов:

Этап Инициации

На этом этапе идея продукта формируется в виде более подробных требований. Необходимо описать в техническом задании следующее:

• Общая информация о проекте

• Цели проекта

• Целевая аудитория проекта и ее проблемы (потребности), которые будет решать продукт

• Ожидаемые выгоды от проекта (для ЦА)

• Основные функции, которые пользователи смогут выполнять в системе. Составляется в общем виде с базовым описанием. Нужно разбить проект на компоненты, в состав которых может входить несколько функций.

• Основные экраны и информация на них (в текстовом виде), которая составляется на основе требований к функциям из пункта выше.

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

Пример прототипа

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

Пример сметы

Также можно составить Роадмап проекта на этом этапе, где указать календарный план работ и майлстоуны:

Этап Разработки

На этом этапе подготовленное ранее Техническое задание разбивается на части (функциональные компоненты, например), затем каждая часть описывается более детально, затем разбивается на конкретные задачи для команды и идет в разработку. Таким образом, пока идет проектирование и описание второй части, первая часть уже разрабатывается.

Для каждого компонента системы указывается следующее:

• Список use cases (можно постепенно дополнять use case диаграмму или сразу сделать ее в полном объеме) с описанием каждого use case

• Описание экранов (также можно постепенно составлять схему экранов или карту сайта)

• Дополнительная информация:

  • База данных для компонента (может постепенно дополняться или разрабатываться сразу полностью)

  • Остальные UML-диаграммы

  • Другая информация

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

Этап Запуска

Этап разработки завершается полноценным приемочным тестированием системы. Когда основные баги исправлены, проект запускается на сервере или (если это не серверное решение) отправляется в стор, после чего могут понадобится дополнительные настройки, которые лучше заранее расписать в ТЗ в виде требований к окружению (серверу).

Кроме того, в материалах, описанных выше, могут быть и другие составляющие или, напротив, отсутствовать некоторые из описанных, что вполне нормально и индивидуально для каждого проекта.

Это, конечно, очень упрощенное описание работы над проектом, но достаточное для понимания того, какие материалы и как нужно готовить. Самое важное при работе над проектом пользоваться не только правилами, а также и здравым смыслом.