четверг, 10 сентября 2015 г.

Так ли страшны изменения, как их малюют?

Изменения требований - самый страшный враг менеджера проекта. Изменениями пугают маленьких программистов: "будешь плохо себя вести - придется все переделывать". Попробуем разобраться, насколько изменения требований опасны для проекта.


Изменения требований сами по себе не страшны. Страшны связанные с ними изменения в работающую систему. Действительно, изменения требований обладают очень разрушительной силой. Большие изменения вносятся долго, нудно и дорого, очень непросто отследить все последствия. Исследования показывают, что если изменения затрагивают более четверти когда, то дешевле сделать все заново.
Забавный факт: если кода еще нет, то изменения требований нам не страшны. Чем больше написано кода - тем дороже могут обойтись изменения.
Поэтому в индустрии разработки принято защищаться от возможных изменений на самых ранних этапов. Главной защитой от возможных изменений является Утвержденное Техническое Задание.

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

Беда в том, что на момент начала проекта у нас часто недостаточно информации обо всех деталях. Многое становятся ясным только в процессе выполнения проекта, или даже после установки решения заказчику.
Если целью проекта является успешное решение проблем заказчика (а не просто освоение бюджета), а на момент старта проекта нам недоступна вся необходимая информация, то следует признать, что изменения в требованиях неизбежны. Даже если составить подробное техзадание, можно быть уверенным, что оно не включает в себя всех нужных деталей.
Что же делать?

Во-первых, стоит смириться, с тем что война с изменениями не приводит к результату и учитывать это в своих планах. Во-вторых, нужно обратить внимание что не все изменения "одинаково опасны". Большие изменения могут оказаться фатальными для проекта, а маленькие обычно ничему не мешают. Это значит, что совсем без защиты от изменений не обойтись, но бороться с мелочами не стоит.  Чтобы повысить вероятность успешного завершения проекта в условиях неопределенности в исходных данных, нам нужно:
1. Научиться не бояться маленьких изменений в требованиях.
2. Минимизировать вероятность появления больших изменений.

Продолжение следует.

Комментариев нет:

Отправить комментарий

Эволюционная разработка программных систем

Программный продукт — это место где разработчики виртуально встречаются с пользователями. И часто с этой встречи обе стороны уходят разоч...