Комплексное управление изменениями
Изменение — это любое отклонение от ранее одобренного базового плана. Оно может повлиять на основные ограничения проекта: расписание, содержание и стоимость, а также на качество и на удовлетворенность заказчика. В лучшем случае изменения затронут какой-то один план, но чаще всего — все. Например, есть проект длительностью два месяца и стоимостью 10 000 руб. Заказчик вносит корректировки и добавляет к проекту дополнительную работу длительностью две недели и стоимостью 3000 руб.
После согласования новых сроков и стоимости меняются базовые планы проекта, в содержание добавляется работа. Из-за этой корректировки обновится и расписание: проект будет длиться два с половиной месяца. Изменится базовый план по стоимости: она вырастет до 13 000 руб. В этом примере поменялись все три базовых плана.
Именно поэтому управление изменениями называется комплексным: корректировка одного из базовых планов обычно влечет изменение остальных. Современное программное обеспечение по управлению проектами, например Microsoft Project, связывает эти планы воедино, так что как только меняется один, автоматически обновляются и остальные. Это удобно.
Откуда берутся изменения
Существуют следующие источники:
- смена целей и приоритетов у бизнеса заказчика;
- несработавшие предположения, возникшие проблемы, вопросы и т.д.;
- новая информация, которая появилась уже в ходе работы над проектом;
- смена или добавление новой заинтересованной стороны;
- изменения в законодательстве.
Изменения в проекте — это неизбежно и нормально. Новая информация поступает постоянно, ситуация на рынке может измениться в любой момент, поэтому не получится сказать заказчику: «Подождите с новыми идеями. Сейчас проект доделаем, а потом уже обсудим». Хотя попытка сделать это — частая ошибка начинающих руководителей проектов.
Agile — как подход и мировоззрение — учит нас приветствовать изменения. И это абсолютно правильно. Если бы в проекты не вносились корректировки, то заказчики часто получали бы ненужные им продукты, которые потеряли свою актуальность еще до запуска. Например, выясняется, что конкуренты выходят на рынок с аналогичным решением через шесть месяцев, так что срок реализации проекта может потребоваться сократить, чтобы опередить их.
Или, скажем, в законодательстве появилось новое требование, согласно которому данные обо всех кассовых операциях должны в режиме реального времени отправляться в налоговую инспекцию, — это повод внести соответствующие изменения в разрабатываемую систему.
Как работать с изменениями в проекте
Схематично процесс работы с изменениями выглядит следующим образом (рис. 57).
Давайте рассмотрим его детальнее.
1. Идентификация изменения. В этом помогает форма запроса на изменение. Как правило, это простая форма, доступная через интернет (в Google Forms или любом другом аналогичном сервисе). Имя инициатора и время заполнения определяются автоматически, поэтому заполнить нужно всего одно поле — описание запроса (рис. 58).
В чем полезность этой формы?
Часто заинтересованная сторона проекта сообщает, что возникла необходимость или желание что-то в проекте изменить. Человеку пришла в голову замечательная идея, и он спешит ею поделиться. В этом случае руководитель проекта должен попросить заполнить форму запроса на изменение. Человеку нужно будет описать свою идею — и тем самым фактически расписаться в ее авторстве. И вот на этом этапе исчезает достаточно много замыслов: после изложения идеи в письменном виде она часто уже не выглядит такой привлекательной. Удобство формы также в том, что менеджер не забудет об изменениях, как часто бывает, если запрос поступил в телефонном разговоре.
2. Уточнение содержания. Когда запрос на изменение получен, нужно убедиться, что менеджер его верно понял. При необходимости следует уточнить содержание запроса у инициатора. Полученная информация также должна быть отражена в форме.
3. Оценка сложности и стоимости рассмотрения изменения и принятие решения об анализе изменения. Иногда встречаются настолько сложные запросы, что только для их оценки требуются недели. В таких случаях нужно подготовить оценку трудоемкости рассмотрения изменения и согласовать ее со спонсором проекта. Далее уже он решает, нужно ли проводить оценку.
В нашей практике нередко случалась примерно такая переписка: «Привет! Нужно добавить вот такой функционал» (далее идет описание). — «Привет! Это сложное изменение. Архитектору нужно будет потратить неделю рабочего времени, чтобы понять, сколько оно будет стоить и как повлияет на сроки». — «Хм. Я не думал, что это такая сложная штука. Тогда не нужно».
В этом случае спонсор проекта не согласовал оценку изменения, и мы сразу отправили запрос в архив. Почему не удалили? Архив нужен, чтобы указать спонсору на принятое ранее решение в том случае, если он снова придет с этой же идеей.
Если же спонсор утверждает затраты, необходимые на анализ изменения, или анализ можно провести очень быстро, то мы переходим к следующем пункту.
4. Идентификация влияния изменений на содержание проекта, сроки, стоимость и качество. Вместе с командой проекта необходимо оценить, как именно запрашиваемое изменение повлияет на содержание существующих работ проекта, расписание, бюджет и качество.
5. Оценка затрат, преимуществ и выбор альтернативы. Обычно существует несколько способов выполнить запрос на изменение. Заинтересованная сторона проекта, запросившая изменение, не всегда может предложить оптимальный вариант, и команда проекта должна подумать, как достичь такого же результата иначе и с меньшими усилиями.
Из ярких примеров: проект по доработкам внутренней системы анкетирования сотрудников. Заказчик попросил добавить возможность отправки определенного шаблона опросника выбранным сотрудникам. Подобный функционал требовал трех недель разработки. При детализации запроса выяснилось, что необходимо учитывать профессиональную позицию сотрудника, указав ее в начале анкеты: разработчик, тестировщик или бизнес-аналитик. Команда предложила добавить в опросник возможность кастомизации и импорта полей из карточки сотрудника. Подобная альтернатива предоставляла заказчику гораздо более гибкое решение, и на ее реализацию нужно было потратить всего одну неделю. Заказчик с радостью утвердил данное решение и был им очень доволен.
6. Оценка стоимости изменения. Необходимо посчитать, сколько будут стоить работы или как долго они будут выполняться при разных вариантах исполнения запроса на изменение.
7. Принятие решения о включении изменения в проект. Спонсор проекта выбирает одну из предложенных альтернатив, утверждает ее и все расходы на реализацию. Затем команда забирает изменение в работу.
8. Обновление документов проекта и внедрение изменения. Обычно изменение добавляет в проект определенные работы. Поэтому после утверждения изменения новые задачи нужно добавить в иерархическую структуру работ проекта, его бюджет и расписание. После этого можно приступать непосредственно к реализации запроса.
9. Документирование решения и информирование заинтересованных сторон. Перед внесением любых изменений нужно создать или обновить документацию, где детально будет описано, как именно работает дорабатываемая система сейчас. Это особенно важно в проектах, которые длятся много лет, иногда десятилетиями. Такая документация позволит отследить историю изменений проекта и найти причину проблем, если они вдруг возникнут.
Как организовать управление изменениями в своем проекте
Внедрять систему управления изменениями лучше в самом начале проекта. А еще лучше — обсудить ее с заказчиком до того, как приступить к работам. Необязательно использовать какой-либо сложный инструмент для документирования изменений, можно обойтись простым документом. Главное, чтобы всем сторонам это было удобно. Если менеджер планирует внедрить управление изменениями на давно идущем проекте, где все прихоти заказчика исполняются и он к этому привык (и ничего менять не хочет), единственным аргументом в дискуссии с ним будет то, что компания-подрядчик перешла на новый процесс работы с изменениями и менеджеру необходимо ему следовать.
Помните, что любые изменения в проекте могут привнести в него новые риски, поэтому не нужно забывать анализировать влияние изменений на проект и с этой точки зрения.
Скептики скажут: «И что? Теперь на каждый чих заводить форму запроса на изменение и утверждать? Часто дел там всего на пару минут». Замечание справедливое. В случае незначительных изменений следует заранее согласовать со спонсором проекта определенное количество оплаченных часов на такого рода работы, а также согласовать само определение «незначительных работ». Например, считать таковыми те, которые отнимают не более двух часов. Если сразу очевидно, что изменение небольшое, то оно делается по упрощенной схеме. При этом нужно отслеживать все запросы на мелкие изменения. В случае, если мы исчерпали согласованные часы, необходимо обговорить со спонсором новый объем времени на подобные работы.
Менеджер должен организовать работу таким образом, чтобы все изменения в проект вносились с его ведома: управлять тем, о чем не знаешь, очень сложно. Почему это важно? Общаясь с заказчиком напрямую, ваш разработчик, например, может пообещать ему что-то сделать. Возможно, он действительно может выполнить обещание, но, в отличие от менеджера, разработчик не видит всего проекта целиком. Следовательно, он не знает, как его обещание скажется на работе других команд, в каком месте их интересы пересекаются и не вызовет ли это новых ошибок. Задача менеджера — выстроить такую систему, при которой со всеми изменениями заказчик шел бы прямо к нему, а не к кому-то из команды.
Выводы
Процесс работы с изменениями помогает не допустить бесконтрольного разрастания содержания проекта (Scope creep), которое автоматически ведет к тому, что проект выходит из согласованного бюджета, сроки срываются, портятся отношения между заинтересованными сторонами. Бизнес всегда будет стремиться добавить еще несколько задач, и процесс работы с изменениями очень хорошо помогает наладить конструктивный диалог и совместное обсуждение возможных вариантов. Руководитель проекта должен быть в курсе всех запросов на изменения. Ни одно изменение не берется в работу без согласования и утверждения руководителем проекта.
