Изменения, доработки, поправки — это камень, о который ломаются косы. Плохое управление изменениями в 100% случаев приводит к срыву сроков и превышению бюджета.
Безусловно, ничто в мире не совершенно и достичь такого управления изменениями, которые было бы идеальным, решало бы все проблемы сроков — невозможно. Скорее даже опасно, так как это может привести к излишней бюрократии и к потери времени уже с другого конца. Поэтому работа с изменениями — это системная работа, поиск баланса, целесообразности и здравого смысла.
Изменения должны вносится итерациями. В зависимости от проекта, это может быть раз в неделю, раз в 10 дней, раз в 20 дней или в любой иной срок, но системно. Если проект скоротечный или того требует ситуация, то изменения могут вноситься часто, но всегда только группой задач единовременно.
Проблема в том, что если мы начинаем вносить изменения бессистемно, то соответственно рушится и вся архитектура проекта. Одно небольшое изменение может затрагивать массу разнообразных частей проекта и ошибки начинают расти как грибы. В запущенном виде остановить эту проблему, помогает только полная переработка проекта с нуля.
Поэтому если вы получили от клиента небольшую правку, на внесение которой вам потребуется всего минута — бейте себя по рукам, оденьте смирительную рубашку, отойдите от компьютера, но не вносите изменение сразу же. Задайтесь сначала вопросами:
- На что это повлияет?
- Какие части проекта будут затронуты?
- Какие еще проблемы это вскроет?
- Сколько потребуется времени с учетом ответов выше?
- Сколько эта работа будет стоить?
- А нужна ли эта правка? Она целесообразна?
После чего все равно не вносите правку, а ждите пока накопится целая пачка изменений.
Процесс внесения изменений
- Получаем от клиента комментарии, предложения, замечания или вырабатываем собственные предложения по изменениям.
- Формируем лист изменений состоящий из двух разделов:
- изменения связанные с текущей и запланированной функциональностью или изменения связанные с ошибками исполнителя;
- изменения не связанные с текущей функциональность, которые приводят к увеличению сроков работы и к стоимости.
- В листе изменений отмечаем к чему приведет каждое изменение:
- к увеличение срока и на сколько;
- к увеличению стоимости и на сколько;
- если необходимо записываем на что повлияет изменение в плане функционала, к каким проблемам может привести.
- Отправляем лист изменений клиенту на утверждение.
- После получения положительного ответа применяем все изменения единовременно.
- После внесения изменений, в листе отмечаем все сделанные задачи и проставляем дату окончания работы над этими изменениями.
Точные формулировки
Формулировка изменений должна быть конструктивной. Чтобы было понятно что и как нужно сделать. Изменения в виде «ничего не работает», «там что-то сломалось», «это нужно как-то изменить», «это работает медленно», «это работает неправильно», «поменять шрифт», «поиграть с цветами» — такие правки не должны приниматься.
Нужны четкие формулировки: «такая-то страница загружается слишком медленно в течение 10 секунд, нужно чтобы загружалась за 4 секунды, для этого необходимо внести изменение в конкретный модуль так-то и так-то». Или «увеличить шрифт заголовка на два пункта». И еще «Изменить цвет фона на оранжевый, если это будет не сочетаться с общим набором цветом, изменить на желтый, если и желтый не подходит, оставить все как есть для последующего обсуждения». Вот как нужно ставить задачи.
Целесообразность
В проблемных проектах чуть ли не половина изменений сначала вносится, а потом происходят откаты к предыдущей версии, так как оказалось, что изменение было не нужно или оно приводит к усложнениям, к плохой работе, к бессмысленности.
Любое изменение, если это не явное исправление ошибки, нужно рассматривать с позиции здравого смысла и ставить под сомнение.
Лучшее изменение — это отсечение функций, повышение надежности, повышение качества, повышение безопасности. Если изменение связано с добавлением нового функционала — это красный флаг. Сопротивляйтесь.
Карта изменений или Roadmap
Карту изменений или Roadmap — это один из самых лучших инструментов по работе с изменениями, позволяющий оценить сразу массу параметров: будущие временные затраты, бюджет изменений, необходимость и порядок доработок.
Когда на руках есть карта изменений с задачами расписанными по версиям на далекое будущее вперед (год, два, пять лет) — это позволяет оценивать ситуацию в полном объеме и принимать стратегические решения, грамотно расставляя приоритеты функций. Выкидывая лишнее и распределяя силы на всю дистанцию.
Roadmap также страховка от очень эмоционального клиента, желающего внезапно вносить правки. Когда он видит план изменений, наступает спокойствие и умиротворение.