Любые изменения в требованиях должны быть зафиксированы и проконтролированы. В этой статье описан вариант процесса управления изменениями требований на проекте.
Фактически, изменения требований в процессе работы — это нормальная ситуация. Плохо, когда изменений боятся, потому что над ними нет контроля.
- Рамки проектного треугольника будут расползаться
- Заказчик может утверждать, что ничего такого он не говорил
- Команда будет делать двойную работу, если требования в постановках будут просто меняться без контроля
1. Планируйте изменения
Надо принять факт, что изменения будут. Их надо измерять, оценивать и контролировать.
Если наш проект по итеративной методологии (Waterfall), когда неопределенность в задачах и проекте минимальна, то необходимо закладывать буфер на изменения к каждой задачи. Я бы рекомендовал в размере 50% от ее оценки, но тут каждый менеджер проекта сам решает, сколько.
Для инкрементной (Agile) методологии, когда сроки выполнения являются сильно неопределенными, надо заранее договариваться с Заказчиком, о том, что сдвиг рамок проекта будет и это нормально (как и изменения) при условиях высокой неопределённости.
Контроль изменений
Основные элементы системы контроля изменений:
- Идентификация изменений
Выявление потенциальных изменений, которые могут повлиять на проект. Это могут быть как изменения, предложенные Заказчиком, так и внутренние запросы на изменения - Оценка изменений
Каждое изменение должно быть оценено с точки зрения его влияния на проект: время, бюджет, ресурсы, риски. И очень важно оценить, насколько изменение согласуется с целями проекта. - Одобрение или отклонение изменений
Принятие решений о том, внедрять ли изменения. Это может включать согласование с командой проекта, руководством и Заказчиком. - Внедрение изменений
После одобрения изменения необходимо спланировать его внедрение. Обновить документацию и перераспределить ресурсы. - Мониторинг изменений
После внедрения необходимо отслеживать результаты и убедиться, что ошибок не возникает и Заказчик удовлетворен изменением. - Документация изменений
Все изменения должны быть задокументированы. Как это можно делать, описано в этой статье
ЗНИ – запрос на изменение
1. Получение запроса на изменение
Канал для запроса: Все изменения в требованиях должны поступать через коммуникационный канал (например голосом, через email или Telegram). Очень важно, чтобы этот запрос был как-то задокументирован.
Внедрение изменений вначале и в середине проекта, не одно и тоже. Чем позднее стадия проекта, тем больше времени, денег и трудовых ресурсов надо потратить, чтобы внести изменения в продукт.
2. Оценка и согласование
После получения запроса, необходимо:
- Оценить влияние изменений на проект (сроки, бюджет, ресурсы).
- Обсудить с Заказчиком последствия и возможные риски, предложив альтернативы при необходимости.
- Заключить письменное согласование изменений, например, через подписание обновленного документа или электронной почты с подтверждением со стороны клиента.
3. Договаривайтесь с Заказчиком на берегу
У Заказчика явно есть свой процесс ЗНИ (хотя бы в голове), поэтому договариваться о том, как управлять изменениями, надо заранее.
4. Используйте систему контроля изменений
Если вы, как руководитель проекта, не используете свою систему и правила, установленные на проекте. Не ожидайте это от вашей команды.
5. Минимизируете изменения
- Следите за тем чтобы вы и команда была сфокусирована на целях проекта.
- Ограничьте и избегайте по возможности любые ненужные (которые отклоняют от цели проекта) изменения, предложенные Заказчиком и командой.
- Поощряйте любые запросы на ЗНИ, которые носят не обязательный характер и запланированы на следующий релиз или позже :).
6. Общайтесь со стейкхолдерами
Коммуникации важны (и точка). Необходимо четко доносить про изменения своей команде и команде Заказчика.
7. Управляйте рисками
Риски, которые несут в себе изменения на рамки проекта надо учитывать и транслировать команде/Заказчику. Любое изменение на проекте, должно отвечать бизнес-целям проекта.
Ниже будет приведен пример шаблона постановки и система внесений изменений в требованиях и постановке. Я привожу пример для Jira/Confluence, аналогично можно адаптировать под любую другую систему управления разработкой.
Шаблон поставки анализа требования, для разработчика
- Ссылка на требование в Jira:
- Вставляем через макрос в Jira
- Требование от Заказчика:
| Описание требования | Пользовательская история | Образ результата | Критерий приемки | Комментарии от команды |
|---|---|---|---|---|
| – | – | – | – | – |
| – | – | – | – | – |
- Постановка для разработчика:
- Постановка должна быть конкретной и достаточной для понимания разработчиком
Процесс фиксации изменений в требованиях
- Старые требования —
зачеркиваем, в комментариях к тексту, указываем причину (в confluence – выделяем кнопкой текст и добавляем комментарий через add inline comment). - Новые требования пишем жирным зеленым цветом, в комментариях к тексту (как в этом примере), указываем: кто внес изменения и когда, кто инициатор изменения и почему, кто согласовал изменения (РП, Заказчик).
- Согласование со стороны РП проекта и команды Заказчика должно быть зафиксировано каким-то способом, например через email. Скрин прикладывается в комментариях к постановке.
- В комментариях к родительской задаче или эпику (ФТ) Jira указываем, что внесли изменения в постановке Confluence. Разработчик это увидит, если нет. То все увидит обновления в Confluence.
В ответ на исправления, разработчики аналогично могут писать свои вопросы по постановке, через add inline comment.
Я думаю, что такой систему управления изменениями на проекте, будет достаточно, чтобы минимизировать риски, при работе с ЗНИ на проект.
При написании статьи частично использовалась книга, автора “Грег Хорин – Управление проектами с нуля”.
Ответы (0 )