Здравствуйте, коллеги! Продолжаем с вами изучать область знания Управление жизненным циклом требований свода знаний по бизнес-анализу BABOK версия 3.0. Задача Оценка изменения требований. Мы уже с вами подробно поговорили про трассировку требований, когда устанавливается взаимосвязь между различными требованиями или какими-то другими артефактами, компонентами решений, зачем это нужно. Мы с вами поговорили про поддержание требований в актуальности, в целостности и подготовке их для повторного использования. Мы обсудили важную задачу приоритизации требований – когда необходимо каким-то образом ранжировать, упорядочивать то, в какой очередности мы работаем с требованиями.
Наконец, задача 5.4 Оценка изменения требований. Поскольку с изменениями сталкивается практически любой аналитик, в своде знаний по бизнес-анализу есть специальная задача на эту тему, которая называется «Оценка изменения требований». Давайте пока посмотрим, о чем она. Назначение задачи – оценка последствий предлагаемых изменений. Нам необходимо понимать, к чему приведут предлагаемые изменения и зачем они нужны. То есть оценка последствий изменения требований и дизайна решений, чтобы определить, повысит ли предлагаемое изменение ценность решения, и если да – то какие действия необходимо предпринять. То есть в принципе мы можем мерить по разным показателям: как изменение влияет на объем, на стоимость и т.д., но главная вещь, относительно чего мы мерим – это ценность. Увеличивает ли ценность решения это изменение или нет? Если оно не увеличивает ценность, то зачем оно нужно? Вот про это мы сейчас подробно и поговорим.
Давайте посмотрим на окружение задачи 5.4 Оценка изменения требований. На вход (так же, как в задачах 5.1, 5.2 и 5.3) идут «требования» и «дизайны». Но есть еще дополнительный вход «предлагаемые изменения», что логично. В качестве дополнительных источников, которые нам необходимо использовать при выполнении задачи 5.4 Оценка изменения требований, служат: стратегия изменений, знание бизнес-домена, подход к управлению, регуляторная информация, архитектура требований (поскольку изменение требований чаще всего затрагивает трассировку и изменяет связи, нужно понимать архитектуру требований), границы решения.
В качестве результата у нас получается оценка изменения требований и оценка изменения дизайна. Мы не меняем ничего в требованиях и дизайнах, мы оценим это изменение. Прежде, чем что-то поменять, необходимо это оценить. Про это задача «оценка изменения».
Давайте посмотрим те элементы (составляющие части) этой задачи, которые BABOK предлагает учесть. Это формализация оценки изменений. На практике есть разные подходы к управлению изменениями требований. Наиболее формализованный подход – когда составляется «запрос на изменение». Есть запрос на изменение, в котором указывается предмет этого изменения, автор, дата, предметная область, требования, к которым относятся это изменение. Указывается, как это изменение повлияет на параметры проекта. Возможно, указана даже группа лиц, принимающих решения по данному изменению, какое принято решение и с какой-то мотивировочной частью.
Не всегда это настолько формализовано. Иногда это бывает упрощенно (в устном формате). Поэтому аналитику необходимо соблюсти какие-то формальности. Об этом необходимо позаботиться на этапе «Определение подхода к бизнес-анализу». Когда мы изучали область знания «Планирование и мониторинг бизнес-анализа», там было много активностей, связанных с выработкой всякого рода подходов: к управлению формации, к управлению работами по бизнес-анализу. Уже на этом этапе необходимо позаботиться о формализации подхода к управлению изменениями, оценке изменений (как части этого общего), и, в том числе, процедуре согласования, утверждения этих изменений.
Недостаточно просто написать запрос на изменение или описать изменение. Необходимо провести определенный перечень действий, для того, чтобы это формализовать (согласовать, утвердить, оценить, возможно, отправить на корректировку). Это целый процесс, который должен быть всеми его участниками признан как легитимный.
Формализация оценки изменений и оценка воздействия изменения. Мы должны обязательно констатировать: какую выгоду несет это изменение и какие затраты? Каково соотношение между выгодой и затратами? Каков график реализации? Сколько времени займет? Как повлияет на общее расписание проекта? Какова срочность? Насколько это изменение срочно?
Одним из элементов этой задачи по бизнес-анализу является принятие решения по данному изменению. В качестве последнего шага мы должны принять решение – что мы делаем с этим изменением: принимаем, отвергаем, принимаем с корректировкой и т.д. Возможны разные комбинации.
Чаще всего в бизнесе идет формальный запрос на изменение. Есть отдельная карточка – запрос на изменение. В ней указываются следующие параметры: автор изменения (надо понимать, кто инициировал данное изменение), дата, приоритет данного изменения (с точки зрения автора этого изменения).
Выгоды. Выгоды можно сформулировать по-разному и это можно специфицировать в документе. Например: мы сокращаем время выполнения работы, мы достигаем какой-то новой функциональности с сохранением всех остальных параметров (за те же самые деньги делаем больше, приносим большую ценность).
Затраты – не бывает так, чтобы изменение не требовало затрат. Скорее всего, затраты будут, это необходимо обязательно отметить.
Влияние на параметры проекта. Поскольку мы вносим какое-то изменение в требования, скорее всего у нас какие-то параметры нашего проекта пострадают – либо сроки, либо бюджет, либо объем, а, может быть, и качество результата. Если мы предлагаем повысить качество результата с сохранением сроков, бюджета и объема. Это повышение ценности – мы повышаем качество результата.
Есть ли какие-то альтернативы? Хорошим тоном считается хотя бы краткое рассмотрение альтернатив данного запроса на изменение. Поскольку когда лицо, принимающее решение, приносит запрос на изменение без альтернатив – это «предложение, от которого нельзя отказаться». Следует указать некоторые альтернативы с каким-то уровнем детализации.
Ответственные по данному запросу на изменение – это могут быть люди, которые ответственны за формализацию, за оценку и так далее.
В каком статусе находится запрос на изменение – утвержден, согласован, в разработке и т.д. У нас есть статус требования, а у запроса на изменение – тоже свой отдельный статус.
Блок решение – мотивировочная часть (почему и какое решение принято, возможно, с выбором каких-то вариантов решения из справочников).
Таким образом, оценка изменения требований – чаще всего формальный процесс. О нем необходимо позаботиться заранее. Лучше всего прописать в документах, которые упорядочивают работу на проекте. Это может быть устав проекта или процедура управления изменениями на проекте, которая в себя включает формат запроса на изменение, журнал изменений (перечень всех изменений, которые у нас накопились на проекте). Руководитель проекта обычно подобные документы ведёт. Их может вести и бизнес-аналитик, если эти изменения касаются именно требований. Возможно, он отвечает за часть этого процесса, связанную с оценкой усилий на это изменение.
Давайте посмотрим на то, какие заинтересованные стороны участвуют в задаче 5.4 «Оценка изменения требований». Это покупатель, который дает нам обратную связь, эксперт предметной области, который нам обеспечивает нам экспертизы по влиянию этих изменений (мы можем что-то не знать, а он, как эксперт, знает, как это изменение повлияет на ценность окончательного решения). Эксперт может одобрить или сообщить нам что-то, что мы не знаем, а это будет иметь критически важное значение.
Конечный пользователь («end user») – при оценке изменения требований он тоже может нам дать ценную обратную связь на тему, как это изменение повлияет на его действие с решением (как в положительную, так и в отрицательную сторону).
Операционная поддержка оценивает со своей точки зрения – насколько это изменение влияет на поддержку. Может быть прекрасное решение, но его будет очень трудно поддерживать или, наоборот, его будет поддерживать гораздо легче, или стоимость поддержки изменится.
Руководитель проекта играет важную роль, потому что изменения влияют на план и требуют дополнительной работы. Руководитель проекта обязательно должен зарезервировать ресурсы для реализации это изменения.
Регулятор не дает нам уклониться от стандартов, нормативов внутренних или внешних.
Спонсор утверждает все эти изменения, потому что изменения обычно требуют дополнительного финансирования. Обычно в проектной практике готовятся запросы на изменения, накапливаются, обосновываются и подаются на рассмотрение управляющего комитета во главе со спонсором, который принимает решение: выделяется дополнительное финансирование или нет, или решение временно откладывается.
Тестировщик может нам помочь консультациями на тему – как изменения влияют на его работу, с его точки зрения.
Методов в оценке изменения требований достаточно много: бизнес-кейс по обоснованию ценности изменения (когда мы пишем обоснование, что это изменение принесет нам такую-то ценность). То есть не просто констатируем, а уже пишем подробно развернутое обоснование.
Другой метод – анализ бизнес-правил как оценка изменений бизнес-правил.
Это может быть анализ документов, финансовый анализ, и оценка (estimation) тоже нам нужны для оценки объема и финансов изменения.
Если во время изменения требований возникают разные вопросы и инциденты, для их разрешения существует метод отслеживания элементов (чтобы ничего не пропало, чтобы мы всем управляли).
Безусловно, при изменении требований необходимо учитывать риски. Потому что может быть очень хорошее изменение, которое вроде как «к добру ведёт», но несёт в себе значительные риски. Именно поэтому управление и анализ рисками здесь обязательно задействуем.
Поскольку нам надо плотно общаться с заинтересованными сторонами для обсуждения изменений требования – для этого существуют методы интервью и воркшопы. Таким образом мы вырабатываем базис для изменения требований.
Лекция посвящена задаче «Оценка изменения требований» (5.4) из свода знаний BABOK.
Назначение задачи — оценить последствия предлагаемых изменений в требованиях и дизайне решений, чтобы понять, повысят ли они ценность решения, и определить дальнейшие действия.
Входные данные задачи: требования, дизайны и непосредственно сами «предлагаемые изменения». Для оценки также используются: стратегия изменений, знание домена, архитектура требований и границы решения.
Результат (выход): документированная оценка изменения требований и дизайна, на основе которой будет приниматься решение.
Основные элементы задачи:
1. Формализация оценки: Обычно реализуется через документ «Запрос на изменение» (ЗнИ), который содержит: автора, дату, описание, приоритет, выгоды, затраты, влияние на параметры проекта, альтернативы, статус и решение. Важно, чтобы процедура работы с такими запросами (согласование, утверждение) была определена заранее.
2. Оценка воздействия изменения: Анализ соотношения выгоды и затрат, влияния на расписание, срочности.
3. Принятие решения: Финальный шаг, на котором изменение принимается, отклоняется или отправляется на доработку.
Участники (Заинтересованные стороны):
• Покупатель и Пользователь: Оценивают влияние на ценность и удобство использования.
• Эксперт предметной области: Помогает оценить влияние на бизнес-логику.
• Руководитель проекта: Оценивает влияние на план и ресурсы.
• Спонсор: Принимает решение о финансировании изменений.
• Операционная поддержка и Тестировщик: Оценивают влияние на поддержку и качество.
• Регулятор: Контролирует соответствие нормам.
Методы оценки: Для выполнения задачи используются бизнес-кейсы, анализ документов, финансовый анализ, оценка (эстимация), управление рисками, интервью и воркшопы для обсуждения с заинтересованными сторонами.
1. Управление изменениями — неотъемлемая часть работы бизнес-аналитика, формализованная в BABOK в виде отдельной задачи.
2. Ключевой принцип оценки изменений — это анализ соотношения полученной выгоды (ценности) и затраченных ресурсов (время, бюджет, риски).
3. Эффективное управление изменениями требует предварительной настройки процессов (до появления первого запроса на изменение), чтобы процедура рассмотрения была прозрачной и быстрой.
4. Оценка изменения — это командная работа, требующая вовлечения всех ключевых ролей проекта для всестороннего анализа последствий.
5. Документирование изменений (ведение журнала изменений, запросов на изменение) является критически важным для отслеживания эволюции проекта и прозрачности принимаемых решений.
1. В чем заключается основное назначение задачи «Оценка изменения требований» (5.4) по версии BABOK?
2. Чем отличается формальный подход к управлению изменениями (с запросом на изменение) от неформального, и почему аналитику важно соблюдать формальности?
3. Перечислите основные параметры, которые должны быть указаны в типовом «Запросе на изменение» (карточке изменения).
4. Какие заинтересованные стороны участвуют в оценке изменения и какова роль руководителя проекта в этом процессе?
5. Какие методы бизнес-анализа рекомендуются для выполнения задачи по оценке изменений требований?
