ИТ-сообществоDEVAN

Управление изменениями на проекте

0
162
Управление изменениями на проекте

Любые изменения в требованиях должны быть зафиксированы и проконтролированы. В этой статье описан вариант процесса управления изменениями требований на проекте.

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

Что будет на проекте, если не управлять и не контролировать изменения?

  1. Рамки проектного треугольника будут расползаться
  2. Заказчик может утверждать, что ничего такого он не говорил
  3. Команда будет делать двойную работу, если требования в постановках будут просто меняться без контроля

Основы управления изменениями на проекте

Планируйте изменения

Надо принять факт, что изменения будут. Их надо измерять, оценивать и контролировать.

Если наш проект по итеративной методологии (Waterfall), когда неопределенность в задачах и проекте минимальна, то необходимо закладывать буфер на изменения к каждой задачи. Я бы рекомендовал в размере 50% от ее оценки, но тут каждый менеджер проекта сам решает, сколько.

Для инкрементной (Agile) методологии, когда сроки выполнения являются сильно неопределенными, надо заранее договариваться с Заказчиком, о том, что сдвиг рамок проекта будет и это нормально (как и изменения) при условиях высокой неопределённости.

Контроль изменений

Основные элементы системы контроля изменений:

  1. Идентификация изменений
    Выявление потенциальных изменений, которые могут повлиять на проект. Это могут быть как изменения, предложенные Заказчиком, так и внутренние запросы на изменения
  2. Оценка изменений
    Каждое изменение должно быть оценено с точки зрения его влияния на проект: время, бюджет, ресурсы, риски. И очень важно оценить, насколько изменение согласуется с целями проекта.
  3. Одобрение или отклонение изменений
    Принятие решений о том, внедрять ли изменения. Это может включать согласование с командой проекта, руководством и Заказчиком.
  4. Внедрение изменений
    После одобрения изменения необходимо спланировать его внедрение. Обновить документацию и перераспределить ресурсы.
  5. Мониторинг изменений
    После внедрения необходимо отслеживать результаты и убедиться, что ошибок не возникает и Заказчик удовлетворен изменением.
  6. Документация изменений
    Все изменения должны быть задокументированы. Как это можно делать, описано в этой статье

ЗНИ – запрос на изменение

Семь принципов эффективного управления ЗНИ

1. Получение запроса на изменение

Канал для запроса: Все изменения в требованиях должны поступать через коммуникационный канал (например голосом, через email или Telegram). Очень важно, чтобы этот запрос был как-то задокументирован.

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

2. Оценка и согласование

После получения запроса, необходимо:

  • Оценить влияние изменений на проект (сроки, бюджет, ресурсы).
  • Обсудить с Заказчиком последствия и возможные риски, предложив альтернативы при необходимости.
  • Заключить письменное согласование изменений, например, через подписание обновленного документа или электронной почты с подтверждением со стороны клиента.

3. Договаривайтесь с Заказчиком на берегу

У Заказчика явно есть свой процесс ЗНИ (хотя бы в голове), поэтому договариваться о том, как управлять изменениями, надо заранее.

4. Используйте систему контроля изменений

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

5. Минимизируете изменения

  • Следите за тем чтобы вы и команда была сфокусирована на целях проекта.
  • Ограничьте и избегайте по возможности любые ненужные (которые отклоняют от цели проекта) изменения, предложенные Заказчиком и командой.
  • Поощряйте любые запросы на ЗНИ, которые носят не обязательный характер и запланированы на следующий релиз или позже :).

6. Общайтесь со стейкхолдерами

Коммуникации важны (и точка). Необходимо четко доносить про изменения своей команде и команде Заказчика.

7. Управляйте рисками

Риски, которые несут в себе изменения на рамки проекта надо учитывать и транслировать команде/Заказчику. Любое изменение на проекте, должно отвечать бизнес-целям проекта.

Система управления управлениям изменениями в постановках

Ниже будет приведен пример шаблона постановки и система внесений изменений в требованиях и постановке. Я привожу пример для Jira/Confluence, аналогично можно адаптировать под любую другую систему управления разработкой.

Шаблон поставки анализа требования, для разработчика

  1. Ссылка на требование в Jira:
  2. Вставляем через макрос в Jira
  3. Требование от Заказчика:
Описание требованияПользовательская историяОбраз результатаКритерий приемкиКомментарии от команды
  1. Постановка для разработчика:
  2. Постановка должна быть конкретной и достаточной для понимания разработчиком

Процесс фиксации изменений в требованиях

  1. Старые требования — зачеркиваем, в комментариях к тексту, указываем причину (в confluence – выделяем кнопкой текст и добавляем комментарий через add inline comment).
  2. Новые требования пишем жирным зеленым цветом, в комментариях к тексту (как в этом примере), указываем: кто внес изменения и когда, кто инициатор изменения и почему, кто согласовал изменения (РП, Заказчик).
  3. Согласование со стороны РП проекта и команды Заказчика должно быть зафиксировано каким-то способом, например через email. Скрин прикладывается в комментариях к постановке.
  4. В комментариях к родительской задаче или эпику (ФТ) Jira указываем, что внесли изменения в постановке Confluence. Разработчик это увидит, если нет. То все увидит обновления в Confluence.

В ответ на исправления, разработчики аналогично могут писать свои вопросы по постановке, через add inline comment.

Я думаю, что такой систему управления изменениями на проекте, будет достаточно, чтобы минимизировать риски, при работе с ЗНИ на проект.

При написании статьи частично использовалась книга, автора “Грег Хорин – Управление проектами с нуля”.

i
Автор

ingeniare

Ответы (0 )