Неконтролируемые change requests — частая причина проблем на проекте. По ходу работ клиент приносит все новые и новые изменения, РМ на них соглашается и, в результате, оказывается в проигрышной ситуации.
О секретах change менеджмента спросили Александра Крючкова, РМ-а с 17-летним опытом управления проектами, спикера курса Supreme PМ.
А ментор курса, Виолетта Савечина, поделилась собственными кейсами, как change management помог ей парировать дополнительные требования заказчика, угрожающие срокам и стоимости проекта.
Откуда приходят изменения?
В нынешних «гибких» проектах, изменения — привычная составляющая процесса, но некоторые из них способны сильно повлиять на сроки и стоимость, поэтому эту часть всегда нужно держать под контролем.
Основные источники изменений на проекте — корректировка и уточнение требований, технические ограничения и смена состава стейкхолдеров со стороны заказчика.
Корректировка и уточнение требований
Заказчик на старте проекта не всегда полностью представляет, что получится на выходе и как готовое решение будет использоваться в бизнесе. В фазе исполнения, когда клиент уже видит первые демо-показы функционала, представление о решении становится более четким. Поэтому у клиента возникает все больше новых пожеланий и доработок в системе.
Здесь РМ-у нужно четко следовать задокументированным ранее договоренностям, держать в уме основную цель и ценность проекта, не уходя в перфекционизм и вечное улучшение уже созданного.
Технические ограничения
Иногда изменения связаны с техническими ограничениями и возможностями решения. Клиенты с техническим опытом могут озвучивать не бизнес-требования, а уже готовое решение.
С первого дня РМ-у нужно работать над тем, чтобы заказчик воспринимал проектную команду как опытных специалистов и прислушивался к их советам и предложениям.
Когда заказчик озвучивает невыгодное для проекта решение, необходимо сразу открыто объяснять в чем сложность или особенности реализации. А затем совместно с клиентом искать решение, учитывая интересы всех сторон.
Смена команды со стороны заказчика
В крупных энтерпрайз проектах состав заинтересованных лиц клиента со временем может поменяться. Проекты в энтерпрайз длятся не один год, соответственно, велика вероятность продавать проект одним людям, а реализовывать уже с другими.
Виолетта Савечина, ментор курса Supreme PM:
Недавно столкнулась с ситуацией, когда в рабочую группу со стороны заказчика пришли новые люди. Каждый имел свой взгляд на решение задач, поэтому добавлял свои требования, не всегда приоритетные для проекта на текущем этапе. Некоторые запросы даже противоречили первичным требованиям проекта, зато влекли за собой существенное увеличение стоимости и сроков.
Со сменой стейкхолдеров меняются и требования. Поэтому, в Fixed Price проекте очень важно документировать любые договоренности и фиксировать скоуп перед подписанием контракта. А на старте проекта, одной из первых задач будет — составить матрицу заинтересованных сторон (RACI матрицу), чтобы определить, кто имеет право «финального решения» относительно скоупа и его изменений.
К чему приводит бездумное следование пожеланиям заказчика?
Вряд ли вы ставите на проекте задачу, сделать как можно больше фич и попасть в книгу рекордов Гиннесса. Или воплотить абсолютно все пожелания клиента. Однако бывает, что в желании удовлетворить заказчика, РМ безоговорочно принимает любые запросы и требования.
Если изменениями не управлять, рано или поздно к вам придет клиент и спросит:
— Дорогой РМ, у нас же релиз через 2 недели, правильно?
А РМ ответит:
— Какие 2 недели?? У нас еще 3 месяца работы, потому что, посмотри сколько изменений! Ты каждый спринт приходишь с каким-то запросом: двигаешь кнопки, меняешь payment системы, просишь другой дизайн и т.д.
После таких слов клиент, мягко говоря, огорчится, возникнет конфликт. И тут бывает очень непростая ситуация, когда РМ-у нечем доказать весь этот объем изменений от заказчика. Или нечем доказать быстро.
Менеджер, конечно, может поднять какие-то имейлы, записи звонков, и потратить на это несколько дней. И возможно, докажет недовольному клиенту и руководству, что действительно изменений было много, и РМ не виноват в срыве дедлайна. А возможно и нет.
Прямое решение задач «в лоб», без анализа запросов, чревато постоянными изменениями. Команда создает фичу за фичей, не учитывая предполагаемые последствия. Позже потребуется неединоразовое изменение кода, что прямо повлияет на сроки и стоимость.
Как правильно обрабатывать изменения?
Посмотрим на примере, как выглядит жизненный цикл любого запроса от клиента. Допустим, вы делаете проект на 20 предполагаемых спринтов.
На 10-м спринте приходит клиент и говорит:
— Ребята, у нас есть форма регистрации пользователя. Здесь должна быть вот такая разметка и дизайн.
Что делать РМ-у, если изначально запроса на этот дизайн не было в бэклоге? Самое первое — внести запрос в реестр изменений.
Внести в реестр
Реестр изменений, когда он есть и нормально ведется, позволяет за одну минуту снять множество вопросов, потому что по нему формируется отчетность о состоянии скоупа.
В реестре можно быстро посмотреть и показать клиенту количество и статусы запросов:
- сколько поступило;
- какие запросы на этапе анализа;
- сколько утвердили или отклонили.
И главное, как утвержденные запросы повлияли на дату релиза.
Виолетта Савечина, ментор курса Supreme PM:
Я когда-то пришла на проект, который стартовал без детализации скоупа и зафиксированного бейзлайна. Заказчик просто сформулировал общую цель продукта.
Прописали концепцию, — и команда начала работать.
На этапе промежуточных демо-показов, стали происходить конфликты, потому что стейкхолдеры со стороны клиента не могли согласовать требования между собой. Команда показывала работу, а заказчики спорили друг с другом — действительно ли это то, что им нужно.
При каждом новом шаге и демо-показе готового функционала, клиент генерировал большой объем доработок и изменений, в которых нельзя было отказать, так как не был зафиксирован бейзлайн проекта.
Приходилось несколько раз переделывать один и тот же функционал из-за того, что требования постоянно менялись и нигде не было зафиксировано, что же мы, собственно, должны клиенту.
В итоге, мы записали все требования, которые на тот момент знали или предполагали, а затем утвердили их с клиентом. Все, что не входило в этот документ, скоупом не считалось, а любые дополнительные запросы фиксировались в реестре изменений.
И только тогда начался какой-то процесс change management, потому что было от чего оттолкнуться. Когда нужно было доказать заказчику, что его запрос — это изменение, мы обращались к документу с четким перечнем фич. Если указанной фичи в списке не было— значит это был оверскоуп.
После внесения в реестр, ВА или РМ анализирует, будет запрос изменением или нет. Анализ проводят по формальным признакам, например, противоречит ли запрос клиента зафиксированным элементам бэклога или предположениям. Дальше оценивают влияние изменения на проект.
Оценить change request
Любое уточнение или изменение скоупа в большинстве случаев повлияет на сроки и бюджет проекта, поэтому изменениями нужно управлять на любом проекте — не важно, какой у вас контракт, Time and Materials или Fixed-Price.
Надо понимать, что клиент не всегда осознает влияние на сроки и скоуп. Клиент может прийти с запросом, который кажется ему абсолютно очевидным, и для него будет открытием, что это добавляет какую-то дополнительную работу.
Заказчик может сказать, что, например, интерфейс администратора есть в любой системе. Поэтому неважно, договаривались мы или нет, просто добавьте пожалуйста, интерфейс бесплатно.
В реальной ситуации большое влияние имеют ваши отношения с клиентом и его склонность к манипуляциям. Но формальный дисклеймер о том, что все, что есть в согласованном документе — это в скоупе, остальное — change request, очень помогает договориться.
Вы вносите запрос в реестр, а затем на встрече с клиентом РМ или ВА может сказать: — Дорогой клиент, твой запрос — это изменение, потому что мы не нашли никаких упоминаний об интерфейсе администратора в нашем бэклоге и в описании скоупа.
Потом РМ сообщает, сколько будет стоить создание интерфейса. Клиент высказывает свое мнение, по каким-то изменениям вы спорите, по каким-то получаете решение — делаем/не делаем.
Изменение может влиять не только на будущий, но и на уже реализованный скоуп. Возможно, вам придется переделать три готовых user story. А возможно, запрос влияет на будущий скоуп, поэтому нужно оценить не только сам запрос, а еще и сделать переоценку других user story и, вообще, поменять половину бэклога. Это все тоже нужно учитывать.
При обсуждении каждого изменения, обязательно проверяйте его на согласованность с бизнес-целями релиза/проекта и соответственно расставляйте приоритеты работ.
Бизнес-целью может быть, например, получение финансирования под проект. И тогда нужно успеть к определенной дате встречи с инвесторами, чтобы показать прототип приложения. Или заказчик подписал контракт с новым клиентом, мы делаем кастомизацию продукта под этого клиента, а ему обязательно нужны вот эти фичи. Всегда есть какой-то бизнес-контекст, который позволяет установить приоритетность.
Если вы с клиентом качественно управляете скоупом и у вас есть хороший ВА, он может сказать заказчикам:
— Ребята, это изменение скоупа. И кроме того, что оно займет дополнительное время, оно еще и не соответствует вашим целям на этот релиз. Вы сейчас концентрируетесь на автоматизации продаж, а это — вообще про закупки. Давайте отложим.
В этом случае, клиент не будет думать, что вы заполняете его жизнь бюрократией, а скажет вам спасибо. Потому что вы подсказали ему, на что не нужно тратить время.
Например, по запросу о новом дизайне для формы регистрации пользователя, после анализа можно сказать клиенту следующее:
— Дорогой клиент, спасибо, что прислал нам шаблон для формы регистрации пользователя. Два месяца назад мы уже реализовали эту страницу, и дизайн у нее был другой, так что — это явный запрос на изменение.
Реализация нового дизайна займет 2 дня, поэтому нужно будет на 2 дня сдвинуть дату релиза. И тебе нужно заплатить дополнительно 400 долларов.
Если ты с этим согласен, мы берем в работу это изменение. Если нет — тогда оставляем дату релиза как есть, потому что сроки тебе важнее. А это изменение откладываем до следующего релиза, а может быть вообще выкидываем.
Договориться с заказчиком
Виолетта Савечина, ментор курса Supreme PM:
У нас был Fixed Price проект, в котором на старте требования были одни, а затем, по разным причинам, большинство требований поменялись. Когда заказчик выставлял изменения более-менее равнозначные по объему, — мы шли навстречу. Но были изменения, которые ни в каком виде ранее нигде не озвучивались и представляли собой существенный блок работ, затрагивающий не только текущую фичу, но и уже законченный функционал.
Все время, пока шел процесс сбора и формирования требований, я вела реестр изменений, фиксировала и анализировала каждый запрос.
Когда стало понятно, что мы финализируемся по требованиям, собрали встречу с Заказчиком, чтобы обсудить ситуацию с изменениями на проекте.
Мы проговорили по реестру:
- как звучало требование на этапе продажи;
- насколько изменение увеличит объем работы;
- как сдвигается срок запуска проекта.
Вместе с заказчиком мы прошлись несколько раз по этому списку, немного поспорили, пошли на взаимные уступки. Глобальный вопрос, который интересовал заказчика, был таким: «Что нужно сделать, чтобы запуститься?»
После анализа стало ясно, что есть два реальных изменения, но без них мы не запустимся. И есть часть задач, от которых Заказчик отказался в рамках проекта.
Проект был Fixed Price, поэтому мы предложили:
— Давайте мы делаем эти два больших изменения в счет тех задач, от которых вы отказались. А остальные некритичные запросы вынесем на этап развития.
Заказчик согласился.
Вовремя зафиксированные изменения и задокументированный бейзлайн проекта, позволили обосновать нецелесообразность большой части изменений. Это помогло не увеличивать сроки работ и вынести некритические доработки на будущее развитие проекта.
Когда change management не нужен
Подход «просто берем и делаем» работает только там, где изначально было оговорено, причем не только в контракте, а еще 20 раз устно и подтверждено имейлами, что ни вендор, ни РМ не несут ответственности за изменение сроков и бюджета.
Если у вас такой проект, в котором вы вообще не договаривались ни о каком скоупе, то, наверное, управлять изменениями ни к чему. Условно говоря, продали agile-команду и начали работать тоже по Agile. Заказчик клятвенно пообещал, что не будет упрекать вас, если вы не успели в срок, после того как он постоянно менял скоуп.
Менеджер в таком проекте фактически выполняет роль координатора команды, скрам мастера, но это не РМ в смысле ответственности за проектный треугольник (скоуп-время-деньги).
С другой стороны, любому клиенту важно понимать, когда будет готова определенная фича или релиз и сколько денег на это потребуется. Заказчик не хочет оказаться в ситуации, когда все надеются, что релиз через 2 недели, а на самом деле — через 3 месяца и об этом стало известно только сейчас.
Правильная работа с изменениями помогает избежать таких ситуаций, поэтому получается, что change management нужен в любом проекте, даже если это не Fixed Price.
Управляя скоупом, РМ спасает проект от срыва сроков и превышения бюджета, защищает клиента от напрасной траты денег, а себя и команду — от стресса и переработок.
Научиться работать с изменениями, прочитав одну статью, наверное, не очень возможно. Зато вполне реально улучшить свои управленческие навыки на практическом курсе Supreme PM.
В программу курса включены темы, нужные каждому РМ-у, чтобы действительно управлять проектом, процессом и даже другими менеджерами.