Неконтролируемое раздувание рамок проекта

Материал из Брацка Правки
Версия от 18:35, 26 сентября 2022; Sonya (обсуждение | вклад) (Новая страница: «Неконтролируемое раздувание рамок проекта (scope creep) -- это увеличение объёма работ без о…»)
(разн.) ← Предыдущая | Текущая версия (разн.) | Следующая → (разн.)
Перейти к: навигация, поиск

Неконтролируемое раздувание рамок проекта (scope creep) -- это увеличение объёма работ без оплаты.

Это происходит в основном по следующим причинам:

  • Нечеткая цель и задачи проекта. Невозможность проследить связь функциональных требований с целями и задачами, которые ставит бизнес заказчика, приводит к созданию решения, которое содержит многочисленные неожиданные функции, но не имеет никакого смысла для конечных пользователей, поскольку не решает их проблемы.
  • Быстрые изменения в бизнес-среде клиента. Внедрение новых норм регулирования бизнеса клиента, например, обязательно приведет к резкому росту или изменению требований в соответствующих частях его программного обеспечения.
  • Суета во время инициации проекта. Неуместное или слишком ограниченное время, выбранное для первоначального выявления требований и их документирования, может сыграть злую шутку с командой, и привести к таким ошибкам, как например, пропущенные внешние системы, с которыми должно интегрироваться разработанное решение, пропущенные процессы или нетривиальные исключения и, конечно , пропущены заинтересованные лица (stakeholders)
  • Отсутствие документации с четко определенным начальным набором требований. Даже если есть процесс управления изменениями, будущее пожелание клиента не может быть идентифицировано как запрос на изменение (change request), не сравнивая его с начальными требованиями, зафиксированными в документации.
  • Неправильная интерпретация требований. Различные программные продукты могут иметь очень похожий функционал. Члены команды, уже разрабатывавшие аналогичный функционал в прошлом, могут подсознательно предположить, что они просто должны сделать тот же функционал еще раз. Однако даже небольшая разница в начале проекта может превратиться в пропасть между разработанным решением и реальными потребностями бизнеса на этапе приемки конечными пользователями.
  • Использование модных слов (buzzwords) или терминов без объяснения. Одно и то же слово может иметь разные значения в разных предметных областях. Например, слово «кластер» может использоваться как в химии или математике, так и в музыке, и хотя они имеют схожее значение, использование таких слов без согласования их значения в рамках проекта приводит к непониманию требований проекта и целей клиента.
  • Отсутствие процесса управления изменениями. Каждое желание клиента, особенно важного для компании-разработчика, рассматривается как обязательное требование без анализа последствий и его влияния на общий график проекта.
  • Намеренное увеличение объема без увеличения бюджета со стороны клиента. К сожалению, случаи, когда клиент вбрасывает в бэклог новые функции, не редкость в наши дни. Обычно клиент хотел бы решить некоторые дополнительные проблемы без бюрократических процедур, связанных с инициацией нового проекта и утверждения бюджета. В других случаях часто добавляются новые функции, которые, по мнению клиента, малы, легко и быстро программируются. Однако все это может привести к scope creep и описанным выше последствиям.
  • Активный микроменеджмент со стороны клиента. Клиенты иногда ставят задачу непосредственно одному разработчику, обсуждая и меняя детали во время приватных Skype звонков без информирования всей команды. Такие действия могут принести хаос в процесс разработки и способствовать появлению scope creep на проекте.

Связанные лектио