🗣 «Как продвигается разработка, Глеб?» — спросил Дмитрий, на совещании, посвящённом обсуждению текущего состояния проекта.

«Я не так далеко продвинулся, как ожидал, — признался Глеб. — Сейчас я работаю над добавлением новой функции поиска в каталог, и это занимает гораздо больше времени, чем я предполагал».

Дмитрий был удивлён. «Я не помню, чтобы мы обсуждали новую функцию поиска в каталоге на недавнем совещании совета по управлению изменениями. Заказчик подал этот запрос через процесс управления изменениями?»

«Нет, он обратился ко мне напрямую с этим предложением, — ответил Глеб. — Мне следовало попросить его оформить официальный запрос на изменение, но всё выглядело настолько просто, что я сказал, что поработаю над этим. Оказалось, что не всё так просто. Каждый раз, когда мне кажется, что я закончил, я понимаю, что упустил изменение, которое должно быть в другом файле, поэтому мне приходится исправлять это, собирать компонент и заново тестировать его. Я думал, мне хватит шести часов, но я уже потратил на это три дня. Я знаю, что задерживаю следующую сборку. Мне закончить с этой функцией или заняться тем, над чем я работал раньше?»

👉 Многие разработчики сталкивались с изменениями, которые казались простыми на первый взгляд, но оказывались более сложными, чем ожидалось. Разработчики иногда не выполняют или не могут выполнить реалистичные расчёты затрат и других последствий предложенного изменения. И когда разработчик соглашается добавить улучшение, запрашиваемое пользователем, требования изменяются «в обход», а не утверждаются соответствующими заинтересованными лицами.

Такие неконтролируемые изменения — распространённая причина хаоса в проекте, нарушения графика, проблем с качеством и ухудшения отношений ❌

В ближайшее время мы рассмотрим эффективные методы управления изменениями, следите за обновлениями 😉📲