style="font-size:15px;"> – отложить (временно).
– Отложено. Если задачу отложили (на этапе «Решение»), она попадает в блок/статус «Отложено» это временное состояние, из него задача попадает на обсуждение с заказчиком. Почему именно на обсуждение, все просто, все данные по задаче есть, нужно только понять, будем делать и когда, если нет и задача нужна, повторно отклоняем. Вечно отклонять не стоит, это будет говорит, что она не нужна, введите число отклонений, среднее число три раза (статистика из практики), после чего задача закрывается с пометкой – «Не будет реализовано».
– Корректировка плана. На этом этапе нужно внести корректировки в план работ, так как задача принята и на ее реализацию нужно время. Если задача небольшая и запаса времени достаточно, чтобы реализовать без перерасчета сроков, то добавляем в план, или если задача большая и нет возможности реализовать без изменений графика, то планируем работы на ближайший этап. Если нужна реализация в ближайшей сборке, то нужно определить вместо какой задачи поставить обсуждаемую.
– Реализация. Изменение внесено в план и является частью проекта. Работать нужно с ним, как с обычной задачей в плане проекта. Дальше идет реализация.
– Проверка результатов. После реализации задачу проверяет руководитель проекта, соответствует ли реализованное поставленной задаче и нет ли проблем в работе. Если есть проблемы, то проектная команда исправляет, а руководитель проекта повторно проверяет.
– Сдача заказчику. Осталось сдать задачу заказчику и получить подтверждение, что она реализована и принята. Не забудьте получить от заказчика подтверждение в виде подписи в документе «Сопроводительное письмо» или, если проект маленький, то хотя бы в виде письма, что задача принята.
Если задачи приняты, то работы по реализации изменений считаются завершенными, задача/-и закрыты.
Давайте посмотрим схему работы с изменениями, по которой работает большое количество компаний.
Рисунок 3 – Некорректная процедура управления изменениями
Как можно понять из схемы, то изменение приняли, не проверили как оно повлияет на текущий функционал, цену, время работы. Могу сказать, что встречаются компании, где нет и третьего шага. Этот подход ухудшает или разрушает проект со стороны архитектуры и кода, он увеличивает его стоимость, а значит уменьшает доход от проекта.
Запросы на изменение могут стать подавляющим большинством среди общего объема задач, если не будет надлежащей организации и управления. Внедрение управления изменениями может помочь проектной команде обратить внимание на запросы на изменения и измерить целесообразность каждого из них. Эта стратегия управления также может помочь отслеживать все изменения, которые были утверждены в отличие от тех, что были отклонены. Без надлежащих стратегий управления изменениями объем проекта может легко
