Материал опубликован с разрешения компании
Автор оригинала: Bob Becker (все
статьи)
Перевод на русский язык: Егор
Демьянов
Оригинальный документ располагается здесь.
Многие команды разработчиков излишне рьяно берутся за дело. Они принимаются за разработку раньше, чем потратят достаточно времени и сил на проектирование модели данных, составление исчерпывающего набора бизнес-правил, планирование процедур загрузки. Они устремляются вперед на всех парах, а в результате получают в хранилище неверные или неполные данные, переделывают свою работу, и доставляют сами себе хлопоты.
У других команд противоположные проблемы. Они являются приверженцами тщательной предварительной проработки всех критичных задач. Они нацелены на качество, полноту и согласованность данных. Тем не менее, эти команды часто увязают в вопросах, которые должны были быть решены уже давным-давно. Как правило, это тупиковое положение становится очевидным в самый неподходящий момент: когда сроки уже поджимают, а решения, которые должны быть уже приняты и находиться в стадии реализации, остаются непринятыми.
Самые серьезные проблемы сопряжены со сложным выбором, и среди членов команды есть несогласные даже с самыми удачными решениями. Простые проблемы уже давно решены, а вот с более сложными задачами все не так легко. Кроме продолжительного времени, затрачиваемого на исследования, профилирование данных, обсуждение архитектуры и неформальных разговоров, ничто не делает команду хотя бы на шаг ближе к принятию правильного решения. Проект застревает на перекрестке, и не может сдвинуться ни в каком направлении. В этот момент страх одолевает всеми членами команды. Давление нарастает.
Один полезный способ, помогающий двигаться вперед, заключается в привлечении арбитра - авторитетного человека не из проектной команды. После выявления самых сложных вопросов назначается совещание с участием арбитра и других заинтересованных лиц. Все участники совещания должны быть согласны с тем, что решение по вопросу должно быть принято на совещании. Арбитр ограничивает время обсуждения каждого вопроса. В последний раз обсуждаются все за и против, и если не удается придти к консенсусу между членами команды, то окончательное решение принимает арбитр.
Другой подход - отложить неразрешенные вопросы на потом, чтобы вернуться к ним после дополнительного исследования и обсуждения, и нахождения правильного решения. Недостатком этого подхода является то, что не всегда бизнес-требования позволяют отложить проблему; иногда это оказывается просто попыткой оттянуть неминуемое, причем без каких-либо плюсов.
Существует тонкий баланс между планированием и разработкой. Цель – найти приемлемые решения (не обязательно самые лучшие), так чтобы можно было перейти от планирования к разработке. Хотя могут еще оставаться моменты, которые можно было бы обдумать дополнительно, разработка часто оказывается более эффективной в нахождении проблемных мест, чем любое количество обсуждений. В сущности, для многих действительно сложных проблем правильное решение может быть получено только путем проб и ошибок.
Очевидно, что мы не защищаем бессистемный подход к созданию хранилищ данных. Но надо признать, что иногда требуется быть прагматичным и двигаться вперед, приняв неидеальное решение (которое, возможно, придется переделывать), чтобы достичь поставленных целей.
Если вы нашли в сети интересные ссылки на ресурсы по технологиям
хранилищ данных, OLAP, CRM или data mining, и хотите поделиться
ими с другими, присылайте их.
Я с удовольствием размещу их на этом сайте.
RSS