Реестр ценности требований

Как донести до пользователей понимание проблем старой системы и сформировать запрос на изменение? Чтобы исключить саботаж и повысить вовлеченность?

На этапе обследования собираются требования. Затем формируется реестр функциональных разрывов. После этого начинается приоритизация.

Обычно приоритет определяется по нескольким критериям:

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

Подход логичный и понятный.

Но в нем есть один серьезный недостаток.

При принятии решений мы оцениваем ценность для бизнеса, однако редко оцениваем ценность для конечных пользователей.

В результате возникает парадоксальная ситуация.

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

Причина проста.

Мы управляем требованиями, но не управляем восприятием этих требований людьми.

Размышляя над этой проблемой, я пришел к идее инструмента, который условно назвал «Реестр ценности требований».

По своей сути это расширенная версия реестра требований.

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

Например:

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

Предпоследний пункт особенно важен.

Некоторые требования могут давать сравнительно небольшой экономический эффект, но существенно повышать готовность сотрудников работать в новой системе.

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

С точки зрения бюджета такая доработка может быть небольшой.

С точки зрения принятия изменений — огромной.

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

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

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

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

По сути, такой реестр становится связующим звеном между управлением требованиями и управлением изменениями.

Он помогает отвечать не только на вопрос:

«Что нужно реализовать?»

Но и на вопросы:

«Кто получит от этого пользу?»

«Насколько значима эта польза?»

«Поможет ли это требование людям принять изменения?»

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

Потому что изменения принимают не организации и не бизнес-процессы.

Изменения принимают конкретные люди.

И чем раньше они увидят личную пользу от внедряемой системы, тем выше вероятность успешной трансформации.