|
Страница 3 из 19
Непредсказуемость требований Каждый раз, когда я сталкиваюсь с проектом, в котором наблюдаются проблемы, я слышу одно и то же. Разработчики приходят и говорят: "Все проблемы из-за того, что заказчик постоянно меняет требования". В этой ситуации меня удивляет только одно - почему все этому удивляются. При разработке программных бизнес-приложений требования должны изменяться, это нормально. Вопрос только в том, что можно сделать по этому поводу. Конечно, можно считать, что меняющиеся требования - результат плохой разработки требований. Идея за разработкой требований стоит простая - получить полную картину требований до того, как начнется работа над созданием программного продукта, заставить заказчика подписаться под этими требованиями, а потом принять меры, препятствующие последующему их изменению. Вся проблема состоит в том, что даже попытка осознать варианты требований - достаточно непростая задача. Более того, как правило, она усложняется еще и тем, что организации, занимающиеся разработкой ПО, не предоставляют информации о ценах. В итоге заказчик оказывается в ситуации человека, который, может быть, и хочет, чтобы у его машины был люк в крыше, однако продавец не может сказать, сколько нужно будет доплатить за него - 10 долларов или 10 тысяч. Как вам кажется, можно ли в такой ситуации решить, стоит платить за него или нет? Оценить же длительность процесса разработки ПО тяжело по нескольким причинам. Во-первых, создание программных продуктов представляет собой работу по проектированию, которую трудно планировать и оценивать. Во-вторых, быстро меняются исходные материалы. В-третьих, очень многое зависит от конкретных людей, которые выполняют работу, а людей всегда сложно прогнозировать и подходить к ним с какими бы то ни было мерками. Нематериальная сущность программных продуктов также играет свою роль. Очень трудно оценить значимость какого-либо свойствa программы, пока вы не начинаете в действительности использовать его. Только работая с первой версией программы, вы начинаете понимать, какие свойства ценны, а какие нет. Это приводит к довольно ироническому умозаключению: все заказчики полагают, что требования можно менять. В конце концов, в слове "software" присутствует слово soft. Итак, требования не просто могут меняться - они должны меняться. Нужно положить много сил и энергии, чтобы заставить заказчика четко зафиксировать свои требования. Сделать это еще сложнее, если заказчики когда-то сами баловались разработкой ПО - тогда они знают, что изменить программу несложно. Впрочем, даже если вам удалось получить четкий список требований, все равно вы обречены. В современной экономике ценность тех или иных свойств программных продуктов меняется слишком быстро. То, что является достаточным набором требований сегодня, оказывается устаревшим уже через полгода. Даже если заказчики могут предоставить стабильный список требований, мир бизнеса от этого не замрет. А ведь многие изменения в мире бизнеса совершенно непредсказуемы (тот кто скажет, что я не прав, либо лжет, либо уже заработал миллион, играя на бирже). Все прочее в разработке программного обеспечения зависит от требований. Если у вас нет стабильного списка требований, вам не удастся составить предсказуемый план работ. |