2 варианта действий, если в проекте что-то пошло не по плану

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

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

Есть понятие «базового» плана (он утверждается у заказчика) и «текущего» – с которым работает руководитель проекта и его команда. Изменения содержания проекта – один из факторов, который сильно влияет на отклонение текущего плана от базового. Это может произойти по нескольким причинам:

• изменения целей;
• изменения ожиданий заказчика;
• изменения требований к продуктам;
• неучтенные в плане проекта работы.

Здесь рассмотрим аспект, связанный с изменением требований к продукту(-ам) проекта.

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

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

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

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

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

На практике чаще всего встречаются два случая:

• Содержание проекта зафиксировано, а стоимость и срок являются изменяемыми (waterfall).
• Зафиксированы бюджет и срок, а содержание является изменяемым (на картинке это случай для Agile).

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

Рассмотрим, как осуществляется управление изменениями для обоих вариантов.

Требования к продукту могут меняться, а сроки и бюджет – фиксированы

В этом случае команда проекта и заказчик должны понимать:

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

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

Для ранжирования требований на важные и не очень можно использовать несколько подходов. На мой взгляд, одним из самых проработанных является метод Quality Function Deployment (QFD). Он был разработан в Японии в 60-е годы. Нужно было найти решение для следующих ключевых проблем:

• при разработке новых продуктов не учитывается, что ни потребитель, ни производитель четко не разделяют потребности (вопрос «что») и способы их удовлетворения («как»);
• если спросить у потребителя, чего он хочет и как это реализовать, он выдаст свою собственную версию.

Часто получается, что при разработке продукта команда проекта не выявляет потребности рынка. Будущий продукт делается исходя из понимания разработчиков о том, что было бы важно потребителю. Для решения этих (и ряда других проблем) и был придуман QFD. Один из самых известных его инструментов – так называемый «дом качества»:

Он состоит из восьми полей, в которые вносится информация:

1 — список потребностей;
2 — веса (рейтинги) потребностей;
3 — список технических характеристик продукта, удовлетворяющих потребности;
4 — реляционная матрица;
5 — веса (рейтинги) технических характеристик;
6 — таблица потребительского бенчмаркинга;
7 — таблица технического бенчмаркинга;
8 — корреляционная матрица для технических характеристик.

Как видим, в QFD при работе над требованиями предполагается использование двух списков:

• пожелания пользователей;
• технические характеристики продукта.

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

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

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

Теперь рассмотрим другой вариант проекта.

Требования к продукту фиксированы, а срок и бюджет проекта – изменяемы

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

Для работы с изменениями вводится специальный документ «Запрос на изменение». Алгоритм принятия решения выглядит примерно так:

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

Подведем итоги.

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

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