Делюсь своим опытом организации процесса управления изменениями RFC (Request for Change) и подключения к нему заказчика. Это помогает не разочаровываться в продукте, сравнивая ожидания с реальностью, и исключает ситуации, когда задачи приходят со сроками «вчера». В тексте вы найдёте пошаговую инструкцию по подготовке к запуску процесса управления изменениями, а также лайфхаки для решения возможных проблем. Статья будет полезна тем, кто работает на переднем крае команды разработки: руководителям проектов, аналитикам и Product owner.
Меня зовут Дмитрий Летяго, я системный аналитик в Outlines Tech. В профессии уже семь лет: работал в ритейле, промышленности, занимался госпроектами. Сейчас развиваю банковские проекты и веду личный блог, для которого снимаю подкасты и собираю полезности для аналитиков.
Что такое процесс управления изменениями RFC?
Управление изменениями RFC — это процесс выявления, документирования, оценки и согласования новых требований к развитию информационной системы. Он полезен командам, которые занимаются заказной разработкой для внешнего или внутреннего заказчика. Подробнее, как именно процесс проходит, написал ниже.
Преимущества управления изменениями:
— Прозрачность. Еженедельные встречи со стейкхолдерами, лидами и командой разработки, что позволяет соотносить ожидания и снимать вопросы по процессу работы. Стейкхолдеры активно включены в проект и понимают, что там происходит.
— Четкость границ. Фиксация всех «хотелок» заказчика, что не даёт финальной реализации отклониться от первоначальной задумки и критично выходить за бюджет. Это исключает ситуации, когда заказывали велосипед, а получили мопед по цене автомобиля. Вроде бы два колеса, руль, сиденье, транспорт едет из точки A в точку Б, но что‑то все равно не то.
Мой опыт управления изменениями: этапы и лайфхаки
Создаём отдельный проект в Redmine, который доступен стейкхолдерам и лидам со стороны разработки. В него заносим все RFC с хотелками заказчика. Там же все участники отслеживают состояние и прогресс.
Для ведения задач также подойдут Jira Software, Asana, 1С СППР, Trello и любой другой таск‑трекер. Главное, чтобы были функции:
создание и группировка требований (задач)
добавление атрибутов: статус, исполнитель, приоритет и т. д.
возможность добавления текстового описания и прикрепления файлов
Инициация
Начальным этапом выступает инициация изменений. Стейкхолдер заводит задачу RFC в Redmine, ставит желаемый срок выполнения, прописывает набор атрибутов в виде: трекера, темы, описания. В качестве источников могут выступать различные НПА, обратная связь от пользователей, хотелки спонсоров и так далее.
Анализ
Далее ведущий аналитик или Product Owner проводит первичный анализ (предобследование), определяет концепт реализации и оценивает верхнеуровневые трудозатраты. Все эти шаги фиксируются в описании к RFC.
Проведение CAB
Дальше набор задач с первичной оценкой попадает на CAB (Change Advisory Board) — совет по изменениям. В состав обязательно должны входить представители всех заинтересованных сторон помимо представителей разработчика.
Там принимаем решения о включении доработки в версию, постановке задачи на холд или отказе от производства.
По итогам:
каждая RFC получает статус (разработка, холд, архив);
фиксируется ответственный за доработку аналитик;
фиксируется срок предоставления постановки и срок согласования;
все решения заносятся в задаче Redmine.
Периодичность проведения CAB: раз в неделю, раз в спринт или по необходимости (когда набран бэклог RFC).
Подключайте к CAB и проекту в Redmine смежную команду, если она задействована в интеграционных доработках. Так вы будете в едином инфополе и вместе отследите изменения без нарушения коммуникации. Абзац составлен на основе опыта провалов, когда команды не могли скоординироваться ?
Бывают кейсы, когда трудозатраты отличаются от предварительной оценки. Здесь важно вовремя сигнализировать об изменениях на CAB. Частое взаимодействие с заказчиком, со стейкхолдером позволяет маневрировать между реальной ситуацией и предварительной оценкой и управлять ожиданиями заказчика.
Проработка аналитиком
Когда задача получает насыщенный атрибутивный состав, аналитик снова включается в работу. Он прорабатывает требования и готовит уже максимально формализованный документ с необходимыми артефактами. То есть на выходе после работы аналитика получается та же самая задача, только уже с атрибутами и дополнениями: прототипом, моделью бизнес‑процессов, описанием юзкейсов и контракта.
Если со стороны стейкхолдера затягиваются сроки согласования — это официальный повод для переноса производства задачи, если до старта работы такие условия были обговорены.
Но что делать с задачами, которые попадают на холд? В этом случае формируем бэклог RFC, который полезно раз в две недели пересматривать на CAB. Пример: к таким задачам относится работа, которая требует реализации исходя из обновления законодательства. Когда срок ввода в действие нормативно‑правового акта сдвинулся на период позже.
После согласования задач можем спокойно планировать производственный процесс по спринтам и формировать программу релизов. Это уже тема отдельной статьи. Главное — не забывать фиксировать все шаги и еженедельно организовывать CAB для обсуждения задач.
Здесь я делюсь файлом с полным жизненным циклом RFC и алгоритмом действий, в том числе при выходе из сроков.
Вместо вывода
Конечно, внедрение нового всегда сопровождается скепсисом и сопротивлением со стороны участников. Однако результат того стоит: как только процесс встанет на рельсы, снимется масса неопределенностей и сложится благоприятная атмосфера для долгосрочного сотрудничества с заказчиками.
Буду рад ответить на вопросы в комментариях и обсудить ситуации на проектах.
