Игнорирование масштаба проекта

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

Использование только своих любимых системных архитектур

Никто не может быть экспертом по всем вопросам. СУБД, работающие в среде дистанционной обработки данных, отличаются от тех, которые работают в средах клиент/сервер, средах с разделением ресурсов или распределенных средах. Одна или две системы, в которых вы эксперт, могут не подходить для полученного вами задания. Но все равно нужно выбрать самую лучшую архитектуру, даже если это означает передачу задания кому-либо другому. Лучше совсем не получить задание, чем получить его и сделать такую систему, которая не нужна клиенту.

Мнение, что клиенты знают, чего хотят

Обычно клиенты приглашают вас спроектировать для них базу данных, когда сталкиваются с трудностями, а имеющиеся у них методы не работают. Клиенты часто уверены, что им известно, в чем состоит проблема и как ее решать. По их мнению, все, что они должны сделать, — это рассказать, что именно вам следует делать.

Однако давать клиенту в точности то, что он просит, — это рецепт заведомой неудачи. Большинство пользователей и их менеджеров не владеют знаниями и квалификацией, нужными для точного определения проблемы, поэтому у них нет шанса найти самое лучшее решение.

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

Отказ от консультации с другими специалистами

Никто не совершенен. Даже самый лучший проектировщик или разработчик может пропустить важные моменты, которые являются очевидными для любого, кто взглянет на ситуацию с другой точки зрения. И действительно, если вам приходится выставлять свой проект на суд общественности, это вас дисциплинирует и, возможно, помогает избежать многочисленных неприятностей, с которыми в противном случае вы бы наверняка столкнулись. Перед тем как разрабатывать приложение, обязательно покажите проект компетентным профессионалам.

Отказ от создания документации

Если вы думаете, что ваше приложение настолько совершенно, что за ним не придется смотреть, то сильно ошибаетесь. Единственное в этом мире, в чем можно быть абсолютно уверенным, — это то, что все течет, все изменяется. Это следует учитывать. И если тщательно не документировать, что было сделано и почему сделано именно так, а не иначе, то через шесть месяцев вы уже не сможете этого вспомнить. Кроме того, если вы перейдете в другой отдел или получите огромный выигрыш в лотерею и уволитесь, не оставив документацию по своему проекту, ваш преемник наверняка не сможет внести никаких изменений в ваше творение, чтобы оно соответствовало новым требованиям. И тогда ему, возможно, придется выбросить приложение и начать все с самого начала. Документируйте свою работу не просто в достаточной степени, а с большим запасом. Делайте документацию более подробной, чем это нужно с точки зрения здравого смысла. И если через шесть или восемь месяцев вы вернетесь к проекту, то будете рады, что вся нужная информация задокументирована.

Отсутствие бета-тестирования

Приложение, работающее с базами данных, чтобы быть полезным, должно быть сложным. В то же время сложное приложение не может не иметь ошибок. Даже если вы будете проверять свое приложение всеми способами, до которых только сможете додуматься, все равно в нем останутся незамеченные сбойные участки. Бета-тестирование — это передача приложения тем людям, которые не разбираются в нем так хорошо, как вы. Вот они-то наверняка столкнутся со всеми неприятностями, которые вам никогда не встретятся по той причине, что вы слишком много знаете о своем приложении. И все ошибки, выявленные бета-тестерами, вам нужно будет исправить, причем еще до того, как продукт станет использоваться официально.

Отсутствие обратной связи с клиентами

Вначале вы, возможно, будете склонны слушать только нанявших вас менеджеров. Сами же пользователи не будут иметь ни малейшего влияния на вашу работу. С другой стороны, может существовать уважительная причина также игнорировать и менеджеров. Ведь они обычно даже представления не имеют о том, что в действительности нужно пользователям. Из этого автоматически не следует, что вы лучше самих клиентов знаете об их реальных нуждах. Конечно, сотрудники, занятые вводом данных, не очень значимы в организации, а многие менеджеры имеют лишь смутное представление о некоторых вопросах, за которые отвечают. Но если вы изолируете себя от любой из этих двух групп, то тогда наверняка создадите систему, которая не решит ничьих проблем. И пусть приложение будет прекрасно работать, но если оно решает не те проблемы, что нужно, такое приложение ни для кого не будет представлять ни малейшей ценности.

Применение только своих любимых сред разработки

Вы, возможно, потратили месяцы или даже годы на то, чтобы стать специалистом в использовании конкретной СУБД или среды разработки приложений. Но ваша любимая среда, не важно какая, имеет как достоинства, так и недостатки. Время от времени вам будут попадаться задачи-разработки, которые предъявляют высокие требования именно к тем областям, в которых ваша любимая среда разработки находится отнюдь не на высоте. Так что вместо того, чтобы придумывать не самое лучшее решение, лучше остановиться и подумать. У вас есть два варианта. Первый состоит в том, чтобы освоить более подходящий инструмент, а затем использовать его. Второй вариант — это чистосердечно заявить своим клиентам, что их задачу лучше решать с помощью инструмента, в котором вы явно не эксперт. Затем предложите им нанять того, кто сможет продуктивно работать с этим инструментом. Такое профессиональное поведение заставит клиентов еще больше вас уважать. (Но, к сожалению, если вы работаете не на себя, а на фирму, то тогда есть опасность, что вас могут просто сократить.)

Проектирование таблиц базы данных отдельно друг от друга

В результате того, что объекты данных и их связи друг с другом определены неправильно, в базе имеются такие таблицы, благодаря которым в данных постоянно появляются ошибки, и это может свести на нет ценность любых результатов. Чтобы спроектировать добротную базу данных, необходимо проанализировать общую схему объектов данных и тщательно проследить их связи друг с другом. Обычно существует не менее одного правильного проекта. Необходимо определить, какой из них вам подходит, учитывая при этом потребности вашего клиента, как нынешние, так и будущие.

Учет только технических факторов

Разработчики приложений часто рассматривают свои будущие проекты только с точки зрения технической выполнимости и потом оценивают требуемые усилия и время исходя из одного этого фактора. Однако на проект могут оказывать влияние и такие вещи, как максимальная стоимость, имеющиеся ресурсы, требования расписания и организационная политика. На практике они могут превратить технически выполнимый проект в сплошной кошмар. Перед тем как начинать разработку проекта, изучите все сопутствующие ему факторы. Возможно, вы решите, что нет смысла заниматься этим проектом, и намного лучше прийти к этому заключению в самом начале, чем тогда, когда на проект уже затрачены большие усилия.

Применение только своих любимых сред

В этой главе...

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