PMsoop: Глава №24: Changes management

В ролях – Менеджер Проекта, Заказчик

Артефакты – changes и другие

Суть – Когда и как мы реализуем запросы на изменения требований в течение проекта

Итак, ещё раз про Changes management, с подробностями и разъяснениями.

Пункт 1. Ченджи – это хорошо!

Бояться запросов на изменения в течение проекта – не надо. Ченджи – на самом деле есть гуд! Потому что ченджи – признак «живого», нужного проекта. Попробую пояснить. Как было замечено в Главе №0, проект начинается с идеи. Далее, по мере обсуждений и размышлений Заказчик излагает своё видение конечного продукта в виде требований. Однако, требования нельзя «потрогать», с ними нельзя «поиграться» как с реальным продуктом. А, как известно, не у всех людей воображение развито достаточно, чтобы представить себе весь продукт целиком во всех возможных вариантах использования. В требованиях даже «картинки», если и есть – статичны. В то же время, визуальный и кинетический (потрогать, поиграться) каналы восприятия являются самыми используемыми для большинства населения нашей планеты. Короче, гарантировать, что требования на 100% отражают именно то, что хочет Заказчик – нельзя.

В качестве примера из жизни – крайне редко ваше представление о том, что вы хотите сделать, соответствует готовому продукту. Идя на пикник, человек представляет себе полянку с костром – абстрактную. Придя на место, в процессе обустройства полянки и разведения костра, эта абстрактная картинка конкретизируется и становится реальностью. Теперь сравните, что вы представляли изначально, и что есть в результате. И найдите 10 отличий

Если идея «живая», продукт релаьно нужен Заказчику – он продожает обдумывать её реализацию и после утверждения требований и старта разработки. Возможны ситуации, когда ещё до показа первой версии Заказчику в голову может прийти некоторое важное уточнение функциональности – ничего необычного в этом нет.

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

С каждой новой версией продукта вы показываете Заказчику новую функциональность – а значит, он может увидеть и «пощупать» продукт с новых сторон. И снова придумать массу улучшений… И это тоже хорошо.

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

Пункт 2. Только в рамках бюджета!

Мы договорились, что сам факт того что Заказчик засыпает нас ченджами на всём протяжении разработки – это хорошо. Однако, нужно ли все эти ченджи реализовывать, и если да – то когда и как?

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

Кроме получения вознаграждения за выполненную работу, утверждение бюджета на ченджи несёт в себе дополнительный смысл – ограничивает Заказчика от бесконечного перфекционизма. Некоторые Заказчики имеют свойство уделять большое внимание доведению продукта до совершенства (в их понимании). При этом часто одни и те же функциональные элементы продукта могут переделываться по нескольку раз, а «перекраска» кнопочек и оформления становится ежедневной рутиной. С точки зрения бизнеса (да и вообще, создания новых продуктов) можно с уверенностью сказать, что ни один новый продукт не бывает совершенным. Момент выпуска нового продукта «в массы» следует выбирать тогда, когда его запуск будет наиболее выгоден с точки зрения маркетинга (для принципиально новых продуктов – чем раньше, тем лучше), необходимым условием является только стабильная работа ключевого (инновационного) функционала этого продукта. Занимаясь «перфекционизмом» Заказчики могут упустить время для успешного запуска своего продукта, либо «проспать» выход аналогичного продукта конкурентов. Так как, в идеальном случае, менеджер проекта «играет на стороне Заказчика» – помочь Заказчику отделить ненужный перфекционизм от необходимых улучшений может быть и его задачей.

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

Пункт 3. О здравом смысле и учёте особенностей проектов

Из каждого правила есть исключения. Которые, впрочем, только подтверждают правило.

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

Правильным подходом является чёткое разъяснение Заказчику сути уступок, на которые мы идём, и акцентирование стандартных правил работы. Например:

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

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

Кстати, обычной ошибкой молодых/неопытных менеджеров проектов является предоставление Заказчику уступок без его уведомления о том, что это уступки. Заказчик, что логично, воспринимает такой подход как стандартную практику для всех проектов. И когда в продолжение проекта, либо в следующих проектах, менеджер начинает «закручивать гайки» – Заказчик воспринимает это негативно.

И ещё один момент – про различие акцентов в проектах типа fixed cost и time&material. Для fixed cost проектов при согласовании/утверждении ченджей акцент делаем на изменение бюджета проекта (мы же не хотим работать бесплатно?), затем на сроки. В проектах типа time&material Заказчик и так оплачивает все трудозатраты, поэтому акцентируем изменения в сроках в первую очередь.

Пункт 4. Заметки по очередности реализации изменений

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

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

В первую очередь, хочу вспомнить правила распределения реализации функционала продукта по версиям. Правило №1 – функции, которые определяют архитектуру всего приложения, следует реализовывать чем раньше, тем лучше. Проще говоря, сначала надо заложить фундамент, а потом строим стены. Правило №2 – в первую очередь нужно реализовать те функции, которые наиболее важны Заказчику, то есть обеспечивают реализацию бизнес-идеи проекта. Чем раньше Заказчик сможет «пощупать» ключевой функционал – тем раньше он его утвердит либо придумает что-то кардинальное.

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

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

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

1. Рассмотрите чендж с разработчиками и оцените масштаб переделок (грубо)

2. Рассчитайте соответствующее изменение к бюджету и срокам проекта (умножив данные от разработчиков на 1,5 – 2 чтобы учесть дополнительные затраты на обновление требований, плана проекта и т.п.)

3. В максимально ясной и корректной форме изложите полученные данные Заказчику

4. Если Заказчик подтверждает готовность к таким жертвам – остановите разработку

5. Проведите полное перепланирование работ, как будто проект начинается заново

6. Утвердите с Заказчиком новый бюджет и сроки

7. Стартуем работы

То есть, при получении кардинальных ченджей, надо сначала объяснить Заказчику суть кардинальности, и если он согласен с дополнительными трудозатратами – надо фактически стартовать проект заново.

Кстати, в подобных случаях, иногда, можно поступить и другим образом. Необходимое изменение реализуется «на костылях», то есть способом, требующим минимальных трудозатрат (и минимума изменений в архитектуре) на данном этапе. При этом обычно страдает производительность и стабильность конечного продукта. Такой подход применим в случае, если мы хотим показать Заказчику работу этой функции для утверждения «так верно», с целью предотвращения дальнейших изменений. Короче, делаем что-то вроде прототипа. И, в дальнейшем, мы рассчитываем на оптимизацию архитектуры при рефакторинге кода в конце проекта. Если точнее, то поступать таким образом можно, если:

1. Нет уверенности, что Заказчик окончательно определился, что он хочет, есть высокие шансы, что когда он увидит результат – решит оставить всё как было

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

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

Пункт №5. Общий цикл

Наконец, ещё раз «нарисую» общий цикл работы над чеджами:

1. Получаем информацию от Заказчика

2. Оцениваем критичность изменений

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

4. Обсуждаем изменения бюджета и сроков с Заказчиком

5. По утвержденным ченджам – просим Заказчика определить приоритеты и желательные сроки реализации

6. Утвержденные изменения вставляем в план работ

7. Обновляем схему платежей – добавляем затраты на ченджи

8. Обновлённый план работ и схему платежей утверждаем с Заказчиком

9. Приступаем к реализации согласно ПП