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. Управление изменениями

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Замечу:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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