Делюсь своим опытом организации процесса управления изменениями 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 смежную команду, если она задействована в интеграционных доработках. Так вы будете в едином инфополе и вместе отследите изменения без нарушения коммуникации. Абзац составлен на основе опыта провалов, когда команды не могли скоординироваться
Интересные статьи
Интересные статьи
