Как проджект менеджеру работать с проектом по Fixed Price

Минимизация рисков — одна из главных задач PM-а при обсуждении и взятия в работу проекта. Именно поэтому опытные менеджеры много раз подумают, прежде чем сотрудничать с клиентом по Fixed Price. Этот формат по праву считается одной из профессиональных вершин в умении проджекта предложить оптимальное решение, которое устроит клиента, руководство и команду, и при этом сведет любые риски к минимуму. Давайте вместе разбираться, что такое фиксированный прайс и как с ним правильно работать PM-у.

Что такое Fixed Price

Fixed Price — фиксированный проектный треугольник: конкретный скоуп, время выполнения и бюджет. При этом определены четкие критерии качества оценки проекта и все риски «ложатся на плечи» подрядчика. Например, если команда что-то не успела, то доделывает бесплатно и даже возможна выплата штрафов за срывы сроков.

По сути, когда клиент подписывает договор на фиксированный прайс, он покупает предсказуемость вроде «проект будет стоить 100.000$ вне зависимости от возможных рисков». Если же происходит что-то не по плану, это уже проблема подрядчика. Поэтому в цену проекта изначально стараются включить все возможные риски, и в задачу PM-а входит выявить их и правильно просчитать.

Когда PM-у стоит брать проект с фиксированным прайсом

При анализе Fixed Price Project необходимо учесть коммерческую и технические составляющие. Обе равноценно важны, но с точки зрения проджекта рассматривать для управления проект с фиксированным прайсом имеет смысл, если:

1. Можно детально описать и зафиксировать скоуп на уровне подробных User Srories. Оптимально, если перед подписанием договора присутствует предпроектное исследование (дискавери фаза) для выявления максимального количества «подводных камней».
2. PM и команда могут точно оценить скоуп проекта: технология знакома, присутствуют все необходимые специалисты или их легко подключить, нет рисковых интеграций с непредсказуемыми последствиями.
3. Project Manager сможет полностью контролировать процесс разработки и делать ее силами собственной командой без подключения сторонних девелоперов, в том числе и со стороны клиента.

Если все три пункта выполняются и с коммерческой составляющей все в порядке, такой Fixed Price Project потенциально рабочий, если учтены все риски. Именно поэтому опытные менеджеры настаивают на проведении обязательной Discovery-фазы в жизненном цикле конкретного FP-проекта.

Как работать на каждом этапе Fixed Price Project

Главное отличие FP-проекта от других моделей — сильный акцент на анализе и планировании, более жесткие рамки и повышенный контроль за процессом разработки со стороны менеджера. В остальном Fixed Price Project похожий на остальные форматы.

Жизненный цикл FP-проекта состоит из 5 основных блоков:

1. Анализ и планирование.
2. Итеративная разработка и тестирование.
3. Регрессия и стабилизация.
4. Приемочное тестирование — UAT.
5. Релиз и пост-релизная поддержка.

Пункты «Регрессия и стабилизация» и «Приемка (UAT)» можно выполнять параллельно с некоторым сдвигом. 

Анализ и планирование

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

Основные шаги, которые должен выполнить Project Manager на этапе анализа и планирования:

1. Описать и зафиксировать скоуп с максимально возможной детализацией.
2. Оценить проект: техническая реализация, стоимость, сроки.
3. Разработать план выполнения каждого этапа разработки, согласовать с командой.
4. Проработать риски, предположения: что может пойти не так и что делать, если это произойдет.
5. Согласовать критерии качества по проекту, методику и время на UAT.
6. Создать план по развертыванию готовой системы (Deployment Plan), согласовать его с клиентом: сколько времени отводится, кто и за что отвечает.
7. Зафиксировать все договоренности документально.

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

Итеративная разработка и тестирование

С точки зрения управления проекта — один из самых сложных этапов для PM-а. На практике именно на процесс разработки приходит большая часть рисков, в том числе и не определенные при анализе и планировании.

Основные задачи проджекта во время создания и тестирования IT-продукта:

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

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

Мониторинг и корректировка

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

Плановое = (Общая оценка проекта / Количество рабочий дней в проекте) * Номер текущего дня * 100%

Фактическое = (Общая оценка закрытых задач за день / Общая оценка проекта) * 100%

С учетом полученных данных PM вносит изменения в изначальный план при необходимости. При этом обязательно нужно на старте работ договориться с клиентом, какой % отклонения считать приемлемым.

Контроль изменения скоупа

Изменение скоупа в процессе разработки — стандартная история. Клиент может к вам обратиться в любой момент с просьбой внести изменения. При этом он может думать, что такая возможность изначально подразумевалась в оценке проекта. Задача менеджера вместе с командой разобрать запрос и понять, на сколько это реально выполнить, как это впишется в рабочий план, бюджет. 

Алгоритм действий по контролю изменения скоупа:

1. Принять от клиента запрос.
2. Внести его в реестр изменений по проекту.
3. Вместе с командой проанализировать запрос и понять, является ли он с формальной точки зрения изменением к скоупу: сравнить с бэклогом, с предположениями.
4. Оценить запрос с технической точки зрения: влияет ли на текущий или будущий скоуп и как именно (сроки, бюджет).
5. Утвердить с клиентом итоговое решение по его запросу: вносить или нет изменения. Тут главная задача PM-а — добиться четкого ответа от клиента и все задокументировать. Это поможет отстоять вашу позицию в случае возникновения спорных вопросов, особенно если поменяются сроки и бюджет проекта.

Репортинг

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

Что должно быть в проектном отчете:

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

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

Регрессия и стабилизация

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

Обычно эта фаза идет перед приемкой, цель — подойти к фазе UAT со стабильным релиз-кандидатом. При оценки сроков и бюджета на этот этап обязательно учесть хотя бы один цикл регрессии и время на устранение дефектов с повторной проверкой. После этого можно переходить к следующей фазе Fixed Price Project — приемочному тестированию или UAT.

Приемочное тестирование — UAT

UAT проводит клиент, при этом сам процесс — это не техническое тестирование по аналогии с QA. Здесь основной акцент не на функциональности, а на выполнении бизнес логики — клиент должен понять, закрывает ли получившийся продукт его бизнес-потребности.

Общая схема организации UAT:

1. Сформулировать критерии входа и выхода.
2. Разработать сценарии приемки.
3. Проход по каждой отдельной истории.
4. Регистрация и приоритизация запросов.
5. Устранение дефектов и внесение изменений.

После последнего шага снова возврат к пункту 3 — проход по сценариям — и так по кругу, пока клиент не скажет переходить к релизу продукта. Критерии входа и выхода могут быть разнообразными. Например, фаза UAT может быть начата при условии, что после проверки X% тест-кейсов в системе остаются неустраненными 0 дефектов уровня blocker, до 3-х — critical и не более 10 — high.

Релиз и пост-релизная поддержка

Основа проведения релиза — Deployment Plan, в котором описаны технические шаги и зоны ответственности организации процесса по развертыванию системы. План должен быть детально описан и обязательно согласован с клиентом. Оптимально, если присутствует еще и Rollback Plan, чтобы была возможность вернуть обратно в случае возникновения ошибок и проблем с развертыванием. Опытные менеджеры также советуют еще провести Dry Run — предварительно «прогнать» систему по Deployment Plan в тестовом окружении, которое похоже на продакшн.

Если говорить про пост-релизную поддержку, то здесь лучше заранее забюджетировать необходимую команду и четко договориться о бесплатно устраняемых severity-дефектах. Такой подход позволит проще организовать техподдержку и четко определить границы, что именно входит в стандартный пакет услуг, а что за дополнительную плату. Как только релиз прошел успешно и оговорены условия по пост-релизной поддержке, Fixed Price Project можно считать закрытым.

Бонус: что делать, если FP-проект нужно взять, но менеджер не готов

Fixed Price Project для компании несет в себе больше рисков, чем другие виды проектов. Поэтому при всех равных, опытные менеджеры постараются взять вариант без фиксированного прайса. Но бывают ситуации, когда с финансовой точки зрения или каких-то договоренностей для компании конкретный FP-проект значительно привлекательней других — это PM не может игнорировать. В этом случае в задачи проджекта входит оценить количественно риски, дать начальству информацию для решения и в случае принятия проекта — минимизировать число потенциальных проблем и негативных исходов.

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

Информацию руководству по спорному FP-проекту лучше передавать в таком формате:

• кратко про проект и клиента;
• сроки;
• бюджет;
• количественная оценка рисков;
• маржа при оптимистическом и пессимистическом сценарии.

Далее, если руководство примет решение взять в работу Fixed Price Project, менеджер минимизирует риски для компании. Детально разделяет скоуп и зоны ответственности между клиентом и командой, документирует зависимости на заказчика, делает как можно больше предположений. Все это позволяет уменьшить не только количество рисков, но и возможность возникновения негативных последствий в случае провала FP-проекта.

Выводы

Именно проджект-менеджер отвечает за то, возьмут ли проект в работу, и сможет ли команда Delivery работать без стресса. Поэтому вы должны быстро оценивать, планировать и управлять ожиданиями клиентов. Как дальше работать с проектом по Fixed Price (и брать ли его вообще), вы должны определиться на этапе пресейла.

Чтобы осилить такие компетенции, мало прочесть статью — нужны опыт бывалых прессейл и деливеров менеджеров, разбор реальных кейсов в зависимости от клиента и компании. Это вы получите на практическом курсе по Presale в IT.

Мы с Ольгой Гром (Delivery Manager в Master Of Code Global) научим вас планировать проект так, чтобы Delivery-команда смогла его осуществить в пределах установленного плана, даже в условиях Fixed Price.