May 7th, 2010

Управление требованиями, или Когда ошибка гарантирует провал

В разработке софта (да наверное и в любой другой разработке, том же бизнес-планировании) существует постоянно забываемое правило: цена ошибки в архитектуре в 100 раз выше цены ошибки в коде. Исправить код - вопрос дней или даже часов; исправить архитектуру - значит по-сути сделать проект заново.

Но существует ошибка, исправить которую вообще невозможно. Это ошибка в исходных требованиях к продукту. Гляньте к примеру Top 10 Epic Fail in Product Launch. Если Вы выпустили Windows Vista, и она "не пошла", поскольку защищенность от вирусов и DRM оказались совсем не тем, что хотела публика - проект умер окончательной смертью. Инвестиции в него уже никак не вернуть.

Вот почему я обращаю Ваше внимание на заметку gaperton, посвященную управлению требованиями:

Термин «сбор требований», иногда встречающийся в литературе — отражает это недопонимание. Требования — не грибы, чтобы лениво разгуливая по лесу, увидев его, сказать: «О! Требование!», сорвать, и положить его в корзину. Они больше напоминают редкоземельный металл, добываемый нечеловеческим, рабским трудом в «этих проклятых рудниках» (кхе-кхе).

P.S. Заметка на самом деле совсем о другом (о том, что хорошему руководителю Скрам не нужен), но фраза мне понравилась. Жаль, конечно, что о самом "сборе требований" gaperton ничего не написал. Ну вот как научусь, сам напишу :)