Методы и инструменты управления проектной деятельностью



В статье рассматривается актуальные проблемы управления проектной деятельностью и способы их решения.

Ключевые слова: управление проектами, верификация, валидация, agile, мотивация.

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

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

Верификация подтверждает, что продукт создан согласно требованиям.

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

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

Верификацию — подтверждение соответствия продукта утверждённым требованиям, обычно выполняют инженеры или тестировщики.

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

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

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

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

Традиционный подход к формированию команд проектов включает:

1. формирование команд под проект;
2. расформировывание сложившейся команды после окончания проекта;
3. развитие навыков подчинения руководителю;
4. развитие зрелости и эффективности руководителей проектов;
5. планирование работы ресурсных пулов.

Если использовать философия управления проектами Agile, то подход меняется:

1. формирование команд вокруг продуктов, а не проектов;
2. стабильные, сильные команды, которым передаются проекты на реализацию;
3. развитие навыков работы в команде;
4. развитие зрелости и эффективности команд;
5. планирование работы целых команд.

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

1. индивидуальные награды рушат взаимопомощь; Нет смысла помогать коллеге, если считаешь себя несправедливо обделенным премией;
2. если сумма значительна, результаты подделывают; сотрудники ищут пути, как обойти ограничений, чтобы не попасть под штрафы;
3. к бонусам привыкают и не воспринимают как вознаграждение;
4. инфляция вознаграждения из-за мотивации на сверхусилия; Для того чтобы финансовая премия мотивировала, ее нужно постоянно увеличивать;
5. система бонусов на статистических данных игнорирует неявный вклад;
6. провоцирует зависть и переходы внутри организации; люди переходят туда, где бонусы больше, если это возможно.

Решение проблемы при использовании APM (agileprojectmanagement) — нефинансовая мотивация:

1. естественное желание сотрудника — делать востребованный продукт;
2. сотруднику нужна обратная связь по итогам его работы;
3. лучшая обратная связь — довольные клиенты;
4. денежное вознаграждение — гигиенический фактор;
5. денег должно быть достаточно.

Большинство проблем проектной деятельности решается децентрализацией управления. При применении традиционного управления проектами:

1. работы различных подразделений координируются через менеджера проектов;
2. взаимодействие отделов или управлений происходит через руководителей департаментов;
3. зависимости между подразделениями оформляются в виде задач и ставятся в планы соседних подразделений с низким приоритетом.

APM предполагает:

1. независимые кросс-организационные команды с общими планами и одним ответственным руководителем;
2. команды могут приносить ценность независимо;
3. прямые горизонтальные связи между рядовыми участниками различных команд.

В традиционном управлении проектами проблемы решаются следующим путем:

1. при появлении проблемы усиливается контроль за исполнением процесса;
2. для усиления контроля увеличивается степень бюрократизации процесса;
3. при появлении проблемы производится поиск и наказание виновного.

Гибкие подходы предполагают следующие действия при появлении проблемы:

1. при появлении проблемы ищутся ее корневые причины;
2. ищутся способы противодействия корневым причинам;
3. для избавления от проблем проводятся эксперименты;
4. в случае успеха эксперимента проводятся улучшения.

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

Повсеместное применение KPI не всегда эффективно, лучше работают опережающие показатели — индикативные метрики. [3] В традиционном варианте применения показателей оценки работы:

1. индивидуальные KPI сотрудников;
2. бонусная часть зависит от KPI;
3. сотрудники придумывают способы обойти KPI.

В гибком варианте предполагаются следующие принципы:

1. Команда объединяется вокруг общей цели и понимания ее контекста;
2. Команда мотивирована возможностью принимать решения самостоятельно;
3. Команда мотивирована возможностью применить свои знания и повысить свой профессиональный уровень.

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

Чаще всего происходит следующее:

1. менеджеры заинтересованы в точном соблюдении сроков и бюджета;
2. менеджеры сопротивляются изменению объема работ;
3. качество продукта приносится в жертву при риске нарушения сроков или бюджета.

В гибком вариант рекомендуется следующая фокусировка:

1. менеджеры и команды заинтересованы в поставке ценности бизнесу и конечному пользователю;
2. менеджеры и команды приветствуют изменение объема работ, увеличивающее ценность для пользователя;
3. качество продукта держится стабильно высоким, так как это снижает затраты на дальнейшую поддержку.

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

1. долгие релизы
2. изменение требований по ходу релиза приводят к его задержке.

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

1. короткие релизы с выходом на пользователей;
2. валидация следующего релиза после обратной связи от пользователей.

Классическое управление базируется на плановой и отчетной документации:

1. коммуникация через документацию;
2. регулярная поставка улучшений документов;
3. долгое согласование документации до начала реализации.

Бюрократизация приводит к затягиванию сроков, нечеткости понимания сути продукта проекта, поэтому гибкий подход рекомендует:

1. коммуникация лицом к лицу;
2. регулярная поставка улучшений продукта;
3. переход от согласования требований к приемке улучшений продукта.

Наиболее сложной проблемой в проектах является их финансирование. В стандартном варианте делается так:

1. бюджет фиксируется под фиксированный объем работ;
2. решения о бюджетировании принимаются;
3. проект финансируется вне зависимости от того, существует ли физическая возможность реализовать его имеющимися ресурсами.

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

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

Литература:

1. Белыш К. В. Методика оценки эффективности проекта по улучшению деятельности предприятия с применением инструментов бережливого производства // 3-й Международная лин-конференция «Резервы повышения эффективности деятельности в бережливых организациях: отраслевые особенности»: сборник статей. Ижевск, 2017. С. 131–138.
2. Саматова Т. Б. Бережливое производство: анализ возможности снижения потерь // Новая наука: от идеи к результату. 2016. № 6–1 (90). С. 236– 240.
3. Управление проектами: учебник для вузов по направлениям 38.03.02 «Менеджмент», 38.03.01 «Экономика» (квалификация (степень) «бакалавр») / А. И. Базилевич [и др.]; под ред. Н. М. Филимоновой, Н. В.Моргуновой, Н. В. Родионовой.— Москва: Инфра-М, 2019.— 348 c.: ил., табл. — (Высшее образование, Бакалавриат).— Библиогр.: с. 336–340.
4. Практика даоToyota: Руководство по внедрению принципов менеджмента Toyota / Джеффри Лайкер, Дэвид Майер; Пер. с англ. — 5-е изд. — М.: Изд-во «Альпина Паблишер», 2017. — 465 c.