Десять самых распространенных ошибок
В этой главе…
- Мнение, что клиенты знают, чего хотят
- Игнорирование масштаба проекта
- Учет только технических факторов
- Отсутствие обратной связи с пользователями
- Применение только своих любимых сред разработки
- Использование только своих любимых системных архитектур
- Проектирование таблиц базы данных отдельно друг от друга
- Отсутствие просмотра проекта в целом
- Отсутствие бета-тестирования
- Отказ от создания документации
Если уж вы читаете эту книгу, то вопросы, связанные с созданием реляционных баз данных, вас обязательно интересуют. Скажем прямо, никто не изучает SQL только ради удовольствия. Этот язык используется для создания приложений, работающих с базами данных, но перед тем как появится возможность создать какое-нибудь из этих приложений, для него уже нужно создать базу. К сожалению, многие проекты терпят неудачу еще до того, как для приложения напишут первую строку кода. Если в основе базы данных заложены неправильные принципы, то как бы хорошо ни было написано приложение, оно все равно обречено на неудачу. В последующих разделах приводятся десять самых распространенных ошибок, допускаемых при создании баз данных. Этих ошибок следует избегать.
Мнение, что клиенты знают, чего хотят
Обычно клиенты приглашают вас спроектировать для них базу данных, когда сталкиваются с трудностями, а имеющиеся у них методы не работают. Клиенты часто уверены, что им известно, в чем состоит проблема и как ее решать. По их мнению, все, что они должны сделать, – это рассказать, что именно вам следует делать.
Однако давать клиенту в точности то, что он просит, – это рецепт заведомой неудачи. Большинство пользователей и их менеджеров не владеют знаниями и квалификацией, нужными для точного определения проблемы, поэтому у них нет шанса найти самое лучшее решение.
Перед вами стоит задача – тактично убедить клиента, что вы эксперт по анализу систем и что вам необходимо провести такой анализ, чтобы вскрыть реальную причину проблемы. Ведь реальная причина обычно скрыта за более очевидными симптомами.
Игнорирование масштаба проекта
В начале разработки проекта ваш клиент рассказывает, что именно он ждет от нового приложения. К сожалению, клиент почти всегда забывает что-то сказать, причем его забывчивость чем-то одним, как правило, не ограничивается. В процессе работы неожиданно возникают и добавляются в проект новые требования. И если вам за проект установлена не почасовая оплата, то этот рост его масштабов может привести к тому, что когда-то прибыльный проект станет убыточным. Все, что вы обязуетесь сделать, должно быть зафиксировано в письменном виде еще до начала работы над проектом. А что касается новых требований, появляющихся во время работы над проектом, то их надо подкреплять дополнительным временем и бюджетом.
Учет только технических факторов
Разработчики приложений часто рассматривают свои будущие проекты только с точки зрения технической выполнимости и потом оценивают требуемые усилия и время исходя из одного этого фактора. Однако на проект могут оказывать влияние и такие вещи, как максимальная стоимость, имеющиеся ресурсы, требования расписания и организационная политика. На практике они могут превратить технически выполнимый проект в сплошной кошмар. Перед тем как начинать разработку проекта, изучите все сопутствующие ему факторы. Возможно, вы решите, что нет смысла заниматься этим проектом, и намного лучше прийти к этому заключению в самом начале, чем тогда, когда на проект уже затрачены большие усилия.
Отсутствие обратной связи с клиентами
Вначале вы, возможно, будете склонны слушать только нанявших вас менеджеров. Сами же пользователи не будут иметь ни малейшего влияния на вашу работу. С другой стороны, может существовать уважительная причина также игнорировать и менеджеров. Ведь они обычно даже представления не имеют о том, что в действительности нужно пользователям. Из этого автоматически не следует, что вы лучше самих клиентов знаете об их реальных нуждах. Конечно, сотрудники, занятые вводом данных, не очень значимы в организации, а многие менеджеры имеют лишь смутное представление о некоторых вопросах, за которые отвечают. Но если вы изолируете себя от любой из этих двух групп, то тогда наверняка создадите систему, которая не решит ничьих проблем. И пусть приложение будет прекрасно работать, но если оно решает не те проблемы, что нужно, такое приложение ни для кого не будет представлять ни малейшей ценности.