🔝В проектных сообществах, что наших, что зарубежных, среди Топ-5 проблем, беспокоящих руководителей проектов обязательно окажется Scope Creep.
Хмм...
Прочитаем средневзвешенное по нескольким AI определение:
Scope creep — это непрерывное, неконтролируемое расширение объема работ проекта без соответствующей корректировки сроков, бюджета, ресурсов или целей.
Хоть убейте, не понимаю, а в чем здесь проблема?
Это же - наша обычная жизнь, изменений много, все неконтролируемые и перпендикулярны твоим целям и срокам, просто случаются - и всё :)
Пример 1:
🏪 Ты пошел в ближайший магазин за хлебом, по дороге позвонили из дома и говорят: "о, раз ты в магазин пошел - купи еще и молока (пива)"
Проблема? Повод для паники? Уверен, что ты в моменте отлично знаешь, как на этот звонок отреагировать
Пример 2:
🛠Ты стартовал ремонт квартиры. У тебя есть выделенный бюджет и дедлайн по срокам. Вы договорились с бригадой на деньги и сроки, процесс пошел.
И вот обнаруживается в ходе работ скрытый дефект (сняли полы, а там …), который требует доп. работ, а как следствие, затрат бюджета и времени.
Разве это катастрофа?
Пример 3, прямо из ИТ:
💻 ИТ-команда делает доработку приложения, внедряете крутое улучшение функционала и клиентского пути.
За неделю до внедрения прибегает Лидер Продукта и говорит: "конкуренты внедрили киллер-фичу, нам вот с этим внедряться вообще бесполезно. Давайте допилим так и так".
Достаточно распространенная ситуация - не повод ни писать заявление об уходе, ни считать лидера продукта идиотом, ни впадать в депрессию.
🍃А еще мы живем в динамичном мире, с беспрецедентной скоростью изменений -в общем в любой момент может произойти то, что потребует той или иной корректировки планов.
❓Так если изменения - обычная ситуация, то что не так?
В самом деле, может ли считаться проблемой, что в Москве в любой день с весны по осень может пойти дождь, а зимой - снег?
✍️ Любая теория проектного управления содержит описание процесса управления изменениями, который в таких случаях и надо применять.
А если по простому - то это изменение надо просто правильно в проекте обработать.
То есть:
1️⃣На берегу или хотя бы при первом изменении скоупа договариваемся с Заказчиком, что каждое новое или измененное требование перед взятием в работу оценивается, согласовывается и фиксируется в некотором специальном реестре.
Каждое! Даже незначительное и даже которое проще сделать, чем описать.
2️⃣Согласовываем в команде и с Заказчиком хотя бы минимальный процесс ведения этого реестра в деталях.
Например: сначала обсуждаем изменение и потом вносим в реестр или сначала вносим - потом обсуждаем.
А так же формат запроса на изменение, кто может подать, какая периодичность, время реакции и т.д.
3️⃣ Реестр с изменениями выкладываем в общий проектный доступ.
Приблизительный формат такого реестра кидаю в первый комментарий.
Плюсы:
🎯Каждое изменение и его влияние на проект согласовано Заказчиком и исполнителем.
🎯Какое-нибудь изменение может быть снято Заказчиком или отнесено на поздние фазы - после того как Заказчик осознал его влияние на проект.
🎯Минимизированы риски претензий (сделали не то, не так, не вовремя)
🎯Ретроспективно и в любой момент времени доступно понимание почему мы сейчас здесь.
🎯Упрощен процесс внесения изменений в договор/контракт
Минусы:
Не вижу. Только трудозатраты на ведение реестра - правильнее взять на себя РП.
Итого,
проблема Scope Creep-то где? В чем?
Ах проблема именно тогда, когда реестр не ведется и требования заходят бесконтрольно?
Так это проблема в менеджере, а не в каком-то там Scope Creep 😀
Я чего-то не правильно понимаю?
Напишите в комментах, помогите разобраться ✍️
P.S. Картинку взял тут