Максименко Юрий

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

 

 

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

«Вот скажут - это ново... А это уже было в веках...» (Экклесиаст). Есть классическая книга, освещающая все эти вопросы: Фредерик Брукс «Мифический человеко-месяц или как создаются программные системы». Или, если угодно, Frederick P.Brooks, Jr. «The Mythical Man-Month. Essays on Software Engineering». Я же в этой статье рассматриваю частную проблему, но зато детальней: пишу только о базах данных. Мой опыт разработки корпоративных баз данных составил 3 года. И этот опыт, надеюсь, будет полезен моим читателям.

Первое собеседование и получение заказа

Это, без преувеличения, главный этап работы. Именно от того, как вы примете заказ и оговорите условия, зависит, как будет протекать работа над ним.

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

Я пойду дальше и стану утверждать, что на практике клиенты, даже вместе с инженерами-программистами, не в состоянии указать полно, строго и корректно точные требования к современному программному продукту, прежде чем будут созданы и опробованы какие-либо версии продукта, спецификации к которому они составляют» (Фредерик Брукс «Мифический человеко-месяц, или как создаются программные системы», глава 16).

Вот главный подводный камень, на который налетают разработчики баз данных. Все дело в том, что классическая схема выполнения работ по заказу, базирующаяся на известной схеме «Согласование ТЗ - исполнение - сдача согласно ТЗ» в случае базы данных обнаруживает полную беспомощность. Когда начнется внедрение корпоративной базы данных - требования внести изменения посыплются, как из рога изобилия. Времени на согласование доп. соглашений уже не будет - все будет требоваться сегодня, сейчас. Вы скажете - это трудности заказчика? Дорогие коллеги - это и ваши трудности. Можно долго говорить, в чем они заключаются, но я здесь отмечу главную из них - ваш престиж. Мало кому покажется убедительным, что Вы все сделали правильно, но автоматизации не получилось. «Операция прошла успешно, но больной умер».

Я выработал следующую схему выполнения заказа:

№	Название этапа	Время выполнения
1.	Ознакомление с задачей	1 неделя
2.	Выполнение пилот-проекта (муляж базы данных, позволяющий представить, как будет работать итоговая версия)	1 неделя
3.	Разработка первого варианта рабочего проекта - зависит от сложности задачи	примерно 2 месяца
4.	Испытание на одном-двух сотрудниках. Им в порядке эксперимента будет поручено работа с базой данных, в течение которого будут сделаны необходимые изменения.	2 недели
5.	Инсталляция на все рабочие места клиентской части базы данных и подключение их к серверной части. Сотрудникам предоставляется выбор: работать по-старому или на базе данных	1 месяц
6.	Внедрение. На этот период оборудование программисту спального места в офисе будет совсем не лишним.	1 месяц
7.	Настало время... разработки ТЗ. Оно будет представлять собой базу после месяца работы плюс изложенные на бумаге (наконец-то) требования к программе.	2 недели
8.	Работа согласно ТЗ	1 месяц
9.	Сдача работы	1 неделя
10.	Трогательное прощание	с 1900 до 2200

Подведем итоги. Итак, для разработки «среднестатистической» корпоративной базы данных требуется:
Период времени - суммируем в месяцах по периодам 1/4 + 1/4 +2 + 1/2 +1+1+1/2 +1 + 1/4 = 6,75 мес. Округлим - 7 мес.
Стоимость работ. Примем за n сумму, в которую Вы оцениваете месяц своего труда. Тогда стоимость Вашего гонорара (в который, естественно, не войдет новое оборудование, которое придется купить) будет равняться 7n +n =8n (я считаю, что месяц работы согл. п. 6 следует считать за два. Это месяц адской работы, в который не будет Вам покоя ни в ясный день, ни в темную ночь). Я бы рекомендовал поэтапную оплату работы.

А согласится ли заказчик на указанные сроки и суммы?

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

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

Так что все зависит от Вашей ситуации и от Вашей твердости. Есть такой путь: назвать короткие сроки и соотв. цифру. Но в этом случае - знайте, на что идете - на бесплатную работу под окрики «быстрей, быстрей!» или... на потерю авторитета.

Всегда ли заказчик прав?

Нет, конечно!

Не стоит спорить, если какое-то пожелание, кажущееся Вам нецелесообразным, не меняет идеологию программы. Проще сделать, и заказчик сам, гордясь собой, попросит убрать ненужную опцию.

Но случается, что заказчик требует построить программу так, что внедрение ее становится проблематичным.

Самый типичный и яркий пример - требование безопасности. Оно включает в себя разграничение доступа и возможность легким движением руки сделать базу неработоспособной. Остановимся на этом примере.

Поднятая тема - безопасность информации - заслуживает отдельного разговора, я готовлю статью о ней. Но сейчас рассмотрим частность: давайте подумаем над, казалось бы, ясным вопросом - всегда ли разграничение доступа целесообразно?

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

Еще раз повторюсь. Система разграничения доступа предполагает очень строгую (напоминающую военную) иерархию и регламент работы. Никогда нельзя забывать об этом!

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

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

Взгляд в будущее

Очень важно предвидеть направление развития базы данных. Практически наверняка Вы будете приглашены дорабатывать ее. Естественно, это новое соглашение, новые сроки и новые деньги. Но как Вы будете благодарны себе, если, придя дорабатывать базу, увидите, что еще при разработке Вы ввели в структуру таблиц необходимые поля и обеспечили их заполнение! Я еще вернусь к теме прогнозирования развития базы данных в следующих статьях. Но здесь приведу две рекомендации.
1. Всегда помните, что диапазон значений поля может расширится (появится новый офис и т.п.). И как частный случай этой рекомендации - старайтесь избегать логических полей в таблице. Вот пример неожиданного расширения области значений поля из моей практики. Таблица клиентов - физических лиц. Поле sex. Ну сколько может быть полов? Но через некоторое время пришлось ввести третий пол - «группа». Это было вызвано тем, что если заезжает группа из 300 человек и пакетом получает услуги, то нет смысла вколачивать их поименно.
2. Если Вы чувствуете, что по объекту, отраженному в таблице (например, по фирмам-клиентам) рано или поздно потребуется статистика, введите в эту таблицу поле типа Date/Time, отражающее дату и время создания записи, даже если пока не видите ему применения.

В чьих руках судьба проекта?

Я видел крах проектов внедрения офисных баз данных - чужих и (увы!) своих. И из этих грустных наблюдений я сделал вывод: судьба проекта - в руках рядовых сотрудников, работающих с базой.

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

Именно этим объясняется необходимость тестирования программы сначала на одном менеджере, потом на всех, но в виде ознакомления, и только потом - внедрение. При такой схеме вы гарантированы от «акций протеста» - менеджер более спокойно относится к тому, что Вы не совсем попали в предметную область: над ним не висит жестокая необходимость бороться с программой, а «товарищей по несчастью» у него еще нет.

Работа на этапе внедрения Котлы паровые зловеще гудят,
От силы паров содрогаясь...
Как тысячи змей пары те шипят,
Из труб кое-где пробиваясь...
(Из песни)

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

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

Сотрудники офиса так долго надеялись - авось обойдется! Авось руководство одумается! Не обошлось. Не одумалось. Придется работать с этой базой. И это повод все-таки приглядеться к Вашему детищу. И дать ряд пожеланий, без выполнения которых работа невозможно (и это действительно так).

На Вас (и, увы, на руководство) обрушится шквал эмоций. И не ждите, что Вам позвонят и сообщат: «когда я ввожу значение в поле ИмяПоля, выдается сообщение об ошибке Такое-То». Вам скажут: «Программа выдает фигню» (это вежливо!).

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

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

Глава 16, из которой взята эта цитата, называется «Серебряной пули нет». Так что мужайтесь.

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

В добрый час !
Статья получена: Клерк.Ру