Текст бизнес-книги "Управление проектами. Правильный путь для начинающих"

Автор книги: Петр Дикий

Раздел: О бизнесе популярно, Бизнес-книги

1.5.3. Этап «Исполнение»

Этап выполнения работ (исполнения) – самая практическая и часто самая захватывающая часть проекта. На этом этапе проектная команда приступает к разработке конечного результата проекта – продукта. Это самый большой и трудоемкий этап, так как именно здесь все планирование реализуется в полном объеме и именно тут все начинают понимать необходимость качественного планирования и подготовки. Из-за сложностей работ этого этапа проекта некоторые стратегии управления используются для отслеживания и управления несколькими факторами, которые работают одновременно.

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

1.5.3.1. Тайм-менеджмент

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

Навыки управления временем могут положительно повлиять на конечный результат проекта, не забывайте об этом.

1.5.3.2. Управление затратами

Это процесс управления всеми расходами, связанными с проектом. Еще управление затратами это:

– Знание, когда, где и в каких объемах расходуются средства компании/проекта.

– Прогноз для чего, когда, где и в каких объемах необходимы дополнительные ресурсы.

– Умение обеспечить максимально высокий уровень отдачи от использования ресурсов на реализации проекта.

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

– обязательства,

– бюджетные затраты,

– фактические затраты.

1.5.3.3. Обязательства

Это плановые, будущие затраты, которые возникают при заключении договоров, контрактов, заказе каких-либо товаров или услуг. Обычно это происходит заранее согласно плану проекта.

1.5.3.4. Бюджетные затраты

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

1.5.3.5. Фактические затраты

Это отчет, содержащий информацию о фактических расходах проекта. При этом они могут произойти:

– Во время выполнения работ проекта.

– В момент выплаты денежных средств.

– В момент списания денежных средств со счета.

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

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

Вы можете спросить: «А как тогда это все оценить и учесть в стоимости проекта?». Давайте поймем, что нужно для прогнозирования и учета:

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

– Собрать объективные данные по стоимости разработки (включая продолжительность), ФОТ, налоги и прочие внутренние расходы компании на разработку проекта.

– Зафиксировать способ финансовых расчетов с заказчиком, поставщиками и субподрядчиками.

– Согласовать и подписать ТЗ с заказчиком.

– Установить, нужны ли выезды к клиенту, какая продолжительность и частота (включая выезды на внедрение и показы). К моменту запуска проекта вам будет приблизительно понятен портрет клиента и его сложность, вы сможете спрогнозировать стоимость данного пункта.

– Установить, нужно ли разовое привлечение сторонних специалистов и их стоимость.

– Посчитать расходы на указанное выше уже эффективное управленческое решение, осталось добавить сверху риски и можно спокойно переходить к следующему этапу.

1.5.3.6. Управление качеством

Качество проекта (Project Quality) – это совокупность характеристик продукта, относящихся к его способности удовлетворять установленные или предполагаемые потребности.

Управление качеством проекта (Project Quality Management) – одна из основных функций проектной команды и руководителя проектов. Представляет собой процесс управления и улучшения качества продукта для удовлетворения потребностей и требований, ради которых проект был запущен. Процесс управления качеством может помочь команде в определении целей в области качества, определить потенциальные риски и препятствия, которые могут привести к плохому качеству, если их не решить.

Замечу:

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

2. Оценка должна строиться на данных, которые будут собираться во время аудита. Аудит (audit) – системное исследование, проводимое для определения, насколько эта деятельность эффективна и приведет ли она к запланированным целям, то есть – к результату.

Процесс управления качеством следует разделить на три этапа:

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

– Обеспечение качества. Регулярная оценка эффективности реализации проекта с выделением параметров эффективности, то есть эффективность работы системы менеджмента и процессов на соответствие стандартам работы и принятому плану. Рекомендуемая структура отчетности в области качества менеджмента:

1. Основание проведения аудита (цель) и объем проверки (границы).

2. Мероприятия по улучшению.

3. Список замечаний, несоответствий (включая их источники) и претензий.

4. Способы разрешения спорных вопросов и конфликтов.

5. Выводы и рекомендации (анализ опыта и извлеченные уроки), включая сводную оценку качества результатов проекта.

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

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

В любом случае каждую запись о проблеме нужно оформить правильно. Такую запись обычно называют «Баг-репорт» (Bug Report), в каждой компании свои стандарты оформления репортов, но в любом случае они должны позволить вам:

1. Зафиксировать и описать путь воспроизведения проблемы, описать саму ошибку/проблему, приложить изображения проблемы (если нужно и возможно).

2. Воспроизвести проблему (это не всегда возможно, но необходимо стремиться).

3. Установить ее важность (определить приоритет проблемы).

4. Понять в чем проблема и устранить.

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

1.5.3.7. Управление изменениями

Данная стратегия включает в себя все процессы и процедуры для интеграции и управления изменениями в проекте. Она помогает руководителю проектов отслеживать и контролировать изменения в рамках проекта, появляющиеся на протяжении его жизненного цикла. Все процессы и процедуры связаны между собой и могут быть представлены, как единый процесс, его называют «Управление изменениями».

Изменения – изменение утвержденного ранее содержания, сроков, ресурсов, а также установленных процедур из-за воздействия разных объективных или субъективных факторов при разработке и реализации проекта. Изменения могут вноситься в различные части и на любом этапе жизненного цикла проекта. Инициатором изменений может выступать любой участник проекта, чаще всего это:

– заказчик (может влиять на конечные характеристики проекта);

– аналитик/архитектор/руководитель проекта в зависимости от структуры компании исполнителя (может влиять на первоначальную документацию);

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

Основные причины возможных изменений в проекте:

– случайности в проектных решениях;

– непродуманные решения;

– совершенствование средств, методов, материалов;

– отставание от графика;

– изменение цен (работы, материалы).

А виды изменений обычно разделяют на:

– Внутренние. Зависят от параметров самого проекта (сроков, поставок, графиков, финансирования и прочего).

– Внешние. Зависят от глобальных факторов, внешних для проекта (политика, право, экономика, технический прогресс и прочего) и независящих от проекта.

Замечу:

Внутренние и внешние изменения могут изменяться в очень большом диапазоне и все изменения в проекте в итоге влияют на «магический треугольник управления проектом». А значит в любом случае будут возникать дополнительные затраты, изменения сроков и качества работ.

Стратегия состоит из прогнозирования, планирования, осуществления, контроля и регулирования изменений.

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

Давайте рассмотрим правильную процедуру управления изменениям в проекте.

Рисунок 2 – Правильная процедура управления изменениями

Опишу шаги на схеме:

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

– Запись в реестре изменений. Все запросы на изменение нужно занести в специальный документ «Реестр заявок на изменение» (или просто «Реестр изменений»). В нем нужно зафиксировать запрос, дату поступления, состояние заявки, статус, сроки реализации, комментарий и поле для подписи клиента (при наличии физического контакта с запросившим изменение).

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

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

Приведу пример из жизни:

На проектах, которые я делал, заказчики часто присылали в процессе работы какие-то замечания, «хотелки», мелкие доработки и переделки. Это может быть как изменение цвета элемента или изменение положения, так и дополнительный макет страницы, которая из простой становится адаптивной. Я начинал считать и показывать заказчикам, что это требует дополнительного времени (да, по Agile я мог добавить это), а значит будут дополнительные расходы. Они, в свою очередь, начинали долгие разговоры/переписки и не всегда в спокойном тоне, что их не так поняли, что мы сделали не то, договаривались о другом, что были устные договоренности и так далее. Были случаи, когда выходили на моих руководителей (владельцев бизнеса) и жаловались им. Зная, что такое может быть, в начале работы в компании и перед запуском проектов я общаюсь с руководством и доношу свою позицию – все договоренности должны быть зафиксированы и согласованы заказчиком хотя бы в письме. Это давало возможность устранить конфликты внутри компании (часто верят больше заказчикам), иметь четкую позицию в переговорах с аргументами в виде согласованных материалов, а значит прийти к согласию с заказчиками на выгодных условиях. Если этого не учитывать и не делать, то для исполнителей, то есть для меня и команды, это станет большой проблемой и финансовыми потерями для компании.

– Решение. По результатам обсуждения предлагаемого изменения должно быть принято одно из пяти решений:

1. Одобрить. Принять в работу и произвести предлагаемое изменение.

2. Отклонить. Признать нецелесообразным отдавать в работу.

3. Отложить. Запрос на изменение имеет смысл, однако временно будет отложен и рассмотрен позднее.

4. Доработать. Запрос на изменение имеет смысл, но нужно или что-то продумать лучше, произвести дополнительную оценку и анализ последствий.

5. Эскалировать. Запрос на изменение имеет смысл, но оценивать и принимать решение могут только вышестоящие специалисты.

– Отложено. Если задачу отложили (на этапе «Решение»), она попадает в блок/статус «Отложено» это временное состояние, из него задача попадает на обсуждение с заказчиком. Почему именно на обсуждение, все просто, все данные по задаче есть, нужно только понять, будем делать и когда, если нет и задача нужна, повторно отклоняем. Вечно отклонять не стоит, это будет говорит, что она не нужна, введите число отклонений, среднее число три раза (статистика из практики), после чего задача закрывается с пометкой – «Не будет реализовано».

– Корректировка плана. На этом этапе нужно внести корректировки в план работ, так как задача принята и на ее реализацию нужно время. Если задача небольшая и запаса времени достаточно, чтобы реализовать без перерасчета сроков, то добавляем в план, или если задача большая и нет возможности реализовать без изменений графика, то планируем работы на ближайший этап. Если нужна реализация в ближайшей сборке, то нужно определить вместо какой задачи поставить обсуждаемую.

– Реализация. Изменение внесено в план и является частью проекта. Работать нужно с ним, как с обычной задачей в плане проекта. Дальше идет реализация.

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

– Сдача заказчику. Осталось сдать задачу заказчику и получить подтверждение, что она реализована и принята. Не забудьте получить от заказчика подтверждение в виде подписи в документе «Сопроводительное письмо» или, если проект маленький, то хотя бы в виде письма, что задача принята.

Если задачи приняты, то работы по реализации изменений считаются завершенными, а задачи закрываются.

Давайте посмотрим схему работы с изменениями, по которой работает большое количество компаний.

Рисунок 3 – Некорректная процедура управления изменениями

Из схемы видно, что изменение приняли без проверки его влияния на текущий функционал, цену и время работы. Это однозначно ухудшит и/или разрушит проект со стороны архитектуры и кода, приводя к увеличению его стоимости или вообще к закрытию.

Замечу:

– Встречаются компании, где нет даже третьего шага.

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

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

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

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

1.5.3.8. Управление рисками

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

Анализ различных определений риска позволил выявить следующие признаки:

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

2. Субъективность – риск всегда субъективен, поскольку без субъекта, который знает, что такое несчастье, что можно считать злом, что таковым не является, откуда исходит вред, представления о риске невозможны. Таким образом, риск – понятие, присущее человеку. Оно исходит из его ценностей, способностей и возможностей.

3. Действие – любое действие может привести к возникновению риска, поэтому он всегда связан с действием. Если нет действий, то нет и рисков.

4. Прогностический характер – возможность осуществить прогнозирование последствий от деятельности, связанной с рисками.

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

6. Возможности – деятельность по достижению цели направлена на использование существующих возможностей.

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

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

Замечу:

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

Ранее я говорил про реагирование на риски, но не уточнял, какие бывают способы/стратегии. Так как руководителю проектов в работе придется определять, как нужно реагировать на риски, как выбрать наиболее подходящий вариант для вас, компании и проекта, то, думаю, стоит рассказать о них детальнее с разбивкой на две группы – «Стратегии реагирования на риски и угрозы» и «Стратегии реагирования на позитивные риски».

Стратегии реагирования на риски и угрозы:

– Уклонение. Уклонение от рисков предполагает изменение плана управления проектом или технического задания таким образом, чтобы исключить угрозы, вызванные негативными рисками, оградить цели проекта от последствий рисков или ослабить цели, находящиеся под угрозой (например, расширить рамки расписания или уменьшить объем проекта за счет урезания функционала или упрощения).

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

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

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

Замечу:

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

Стратегии реагирования на позитивные риски:

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

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

1. Партнерство с совместной ответственностью за риски.

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

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

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

Отдельно идут еще две стратегии:

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