День 1999. #УрокиРазработки
Уроки 50 Лет Разработки ПО

Урок 16. Не задокументировав и не согласовав содержимое проекта, нельзя узнать, увеличивается ли его объём. Окончание
Начало

Это входит в рамки проекта?
Поскольку объём так или иначе будет меняться, в каждом проекте должен быть определён практический процесс управления изменениями. Простое добавление требований в список без их анализа может только навредить. Формальный процесс внесения изменений не должен начинаться, пока команда не установит базовые границы определённого объёма работы. До этого момента требования и объём проекта динамично меняются. Во время выполнения каждого этапа работы контроль над изменениями должен становиться всё более строгим, чтобы повысить вероятность достижения базовых целей в соответствии с графиком.

Когда кто-то предлагает новое требование, следует задать вопрос: «Вписывается ли оно в объём?» Есть три возможных ответа.

1. Да, требование явно вписывается в рамки проекта. Предлагаемый функционал необходим для достижения целей в текущем цикле разработки. Поэтому мы должны добавить это требование в список.

2. Нет, требование явно выходит за рамки проекта. Оно не способствует достижению бизнес-целей в текущем цикле, поэтому его не нужно принимать в реализацию прямо сейчас, но можно рассмотреть в дальнейшем или отклонить.

3. Требование не вписывается в текущие рамки проекта, но относится к категории желательных. Спонсор проекта должен принять бизнес-решение: следует ли увеличивать объём проекта ради реализации новых возможностей. Если запрошенное изменение представляет определённую ценность для бизнеса, то правильным будет увеличить объём проекта. Но если объём увеличивается, придётся изменить и что-то ещё: сократить другие функции, изменить расписание, увеличить стоимость и т.п.

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

Например: «Система должна поддерживать документы Microsoft Word». У читателей могут быть очень разные представления о том, какие именно функции подразумеваются под поддержкой. Владелец продукта строит планы на основе своей интерпретации слова «поддерживать», а позже обнаруживает, что клиент, запросивший эту функцию, имел гораздо более широкие ожидания. Это ведёт к разбуханию проекта? Или просто является уточнением первоначального ожидания? Тщательное описание требований перед принятием обязательств помогает избежать таких проблем.

Мудрые подрядчики предусматривают дополнительное время на разрешение непредвиденных обстоятельств, стараясь учесть возможность некоторого разбухания проекта и расплывчатости требований. Однако увеличение цены проекта, вызываемое такой предусмотрительностью, может оттолкнуть потенциального клиента. В контрактах должно быть чётко указано, как следует оценивать увеличение объёма работ и кто будет за это платить. Чем чётче вы определите, что включено, а что нет, тем легче будет впоследствии разрешить споры о реализованных и нереализованных функциях.

Итого
Изменения случаются, но чрезмерные изменения предполагают, что изначально никто не проработал задачу должным образом. Чёткое определение запланированного объёма работ позволяет команде сосредоточиться на создании ценного результата в рамках графика и бюджетных ограничений и принимать важные бизнес-решения, когда поступают запросы на изменение.

Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 2.