Управление проектами. Правильный путь для начинающих

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

– Обеспечение качества – оценка эффективности реализации проекта и выделение параметров эффективности, которые характеризуют качество проекта.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

– принять в работу,

– отклонить,

– отложить (временно).

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

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

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

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

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

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

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

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

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

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

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

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

В рекомендациях (PMBOK) предлагают управлять рисками в 4 простых этапа:

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