Читать книгу Управление проектами. Правильный путь для начинающих - Петр Дикий - Страница 9

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

– отклонить,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Также можно ускорить наступление рисков или усилить их последствия. Да, это не шутка, так как в менеджменте «риск – это вероятностное событие, способное повлиять на цели». Следовательно, если руководитель проекта не работает с позитивными рисками, то он упускает возможности и, как результат, теряет время и деньги.

Чтобы прогнозирование рисков не превратилось в «гадание на ромашке», а управление рисками не свелось только к надеждам «сбудется/не сбудется» или «давайте увеличим время на 50%», проектная команда должна знать и активно применять специальные инструменты управления рисками: организационные, технические, финансовые, правовые и иные. Этому команду может научить только руководитель проекта, да и проконтролировать тоже.

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

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

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

– Анализ. Приоритизация рисков.

– Планирование. Планирование графика устранения рисков.

– Мониторинг и контроль. Поддержка плана реализации проекта и списка рисков в актуальном состоянии, контроль устранения.

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

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

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

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

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

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

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

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

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

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