Анна Федорова - Заметки начинающего аналитика

Прочитав коммерческое предложение, присланное Гошей, я основательно задумалась. Если бы тогда в моем арсенале был опыт объектно-ориентированного анализа и моделирования, то первым делом родилась бы приблизительная схема будущей системы. Но язык моделирования еще не был мне знаком, объекты смутно припоминались из курса обучения в ВУЗе, анализ же производился интуитивно.

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

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

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

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

Третьей стороной в проекте были разработчики информационной системы «Asoft», которую использовала организация Ткаченко. Нам предстояло скоординировать усилия, чтобы получать из огромного массива данных только те, которые нам нужны, и в том виде, который способно обрабатывать программное обеспечение «СОИ». И пока я занималась непосредственно заказчиком, Гоша окучивал «Asoft», чтобы затем объединить результаты.

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

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

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