VII. Первый проект
Первый проект, как первая жена, первая машина, и так далее, запоминается надолго. Самые очевидные, академические ошибки допускаются в первом проекте. Все последующие посвящены уже отработке частных случаев.
Когда получаешь задание, не всегда удается ясно представить себе масштабы того безобразия, в которое ты ввязываешься. Частично это проходит с опытом. Но в отношении некоторых вещей опыт бессилен, обычно, когда включаются случайные факторы или речь идет о поведении клиента. Другими словами, почти невозможно заранее угадать, завершится проект через несколько месяцев или не завершится никогда. Даже руководители не всегда это знают. Они могут утверждать прямо противоположное, чтобы не деморализовать команду. Не верьте. Они тоже ничего не знают.
Тем чудесным январским днем, когда в моем почтовом ящике обнаружилось письмо с коммерческим предложением на создание некоей диковинной системы, я и не подозревала, что работа над ТЗ займет у меня четыре месяца вместо запланированного одного, а сам проект, хотя и закончится формально через семь месяцев после начала, однако будет требовать постоянно к нему возвращаться, что-то доделывая, подчищая, обрабатывая напильником.
Нам заказали систему документооборота между небанковской кредитной организацией и Регулятором, которому в очередной раз вздумалось что-то отрегулировать. Что конкретно, разобраться было трудно. Одно только описание этого процесса оказалось разбросанным по нескольким нормативным документам, поправки к которым пеклись, точно блины на масленицу.
До того проекта мне не приходилось даже работать с правовой системой. Я понятия не имела, где найти свежие выпуски изменений в законодательстве и вообще в глаза не видела ни одного закона. Само собой, юридического образования у меня тоже не наблюдалось. Вспоминая это сейчас, я понимаю, какой авантюрой был тот проект, и каким неутомимым оптимизмом должны были обладать люди, принимающие в нем решения, чтобы доверить мне, сотруднику без опыта, такую работу сразу после испытательного срока. Единственным аргументом в их пользу можно считать тот факт, что других аналитиков в компании просто не было.
Представителем заказчика выступал джентльмен с украинской фамилией Ткаченко, который руководил каким-то отделом кредитной организации. От нас он находился на расстоянии нескольких сотен километров. Поскольку руководство не нашло в себе сил обеспечить наше непосредственное общение, мы улаживали дела по телефону и почте. Причем делали это регулярно и с полной ответственностью как в течение первого месяца работы, так и после срыва всех запланированных сроков, в чем надо отдать должное нам обоим.
Организация, где работал Ткаченко, по своим оборотам и количеству клиентов была далека от сотни крупнейших Российских банков, но успела наплодить с десяток отделений в разных городах. Наша система должна была обеспечивать связь всех отделений с центральным, куда направлялись потоки документов, чтобы затем объединяться в один общий поток. После объединения данные специальным образом дробились на куски, упаковывались в посылки и по защищенным каналам передавались Регулятору. От нас требовалось создать такие условия, при которых данные соответствовали бы по своей структуре и содержанию действующему законодательству, а попадут ли они живыми и невредимыми в конечный пункт, за это мы несли ответственность только на участке передачи между региональными отделениями и их «головой». Разбор ответов на посылки тоже входил в наши обязанности, из них же узнавали о том, насколько правильно выполнена остальная часть работы.
Прочитав коммерческое предложение, присланное Гошей, я основательно задумалась. Если бы тогда в моем арсенале был опыт объектно-ориентированного анализа и моделирования, то первым делом родилась бы приблизительная схема будущей системы. Но язык моделирования еще не был мне знаком, объекты смутно припоминались из курса обучения в ВУЗе, анализ же производился интуитивно.
Тем не менее, схему мы нарисовали. Ковыряя ручкой ни в чем не повинный лист бумаги, Гоша изложил мне свое вИдение и понимание того, что нужно построить. Написать по нему код смог бы только телепат. Впрочем, работа программиста предполагает наличие определенных телепатических навыков, хоть они и требуют точные спецификации и страшно злятся, когда задача описана нечетко.
Снабженная рисунком и объяснениями, я удалилась в свою нору. Еще полдня раздумий позволили сформулировать вопросы к заказчику, их было около двадцати. Несколько проектов спустя я уже знала, что информацию нужно подавать порциями, и не переходить к следующему вопросу до тех пор, пока не будет решен текущий. Но в первом проекте собираешь все грабли, разбросанные на твоем пути и спрятанные в укромных уголках – для особенно талантливых. Поэтому я с чувством выполненного долга отправила письмо и принялась за изучение инструкций Регулятора, добытых хитроумными способами через организацию, сопровождающую нашу правовую систему.
Грандиозность задуманного открылась мне после знакомства с двумя структурами, предназначенными для хранения интересующих нас данных. Одна содержала с полтора десятка полей, а вторая – порядка восьмидесяти. Каждая запись в таблице с такой структурой описывала одну-единственную банковскую операцию, которых за день происходят тысячи. Все их нужно было проверить, отправить, собрать, разобрать, порубить, завернуть и поднести расфасованными конечному пользователю. Шерсть вставала дыбом от ужаса.
Ткаченко разговаривал со мной по телефону эротичным баритоном, а по почте присылал те фрагменты своей оперативной памяти, в которых содержались мысли по проекту. Знаки препинания в его письмах часто бывали расставлены весьма вольно, а иногда и совсем отсутствовали. Не всегда удавалось точно определить границы слов и предложений. Дешифрируя его потоки сознания, я жалела, что в ВУЗе нам не преподавали криптоанализ. Однако безусловно положительной его чертой как заказчика была готовность в любое время и столько, сколько потребуется, уделять внимание нашей совместной работе – отвечать на мои вопросы, искать и присылать информацию, выдвигать свои предложения, указывать на ошибки.
Третьей стороной в проекте были разработчики информационной системы «Asoft», которую использовала организация Ткаченко. Нам предстояло скоординировать усилия, чтобы получать из огромного массива данных только те, которые нам нужны, и в том виде, который способно обрабатывать программное обеспечение «СОИ». И пока я занималась непосредственно заказчиком, Гоша окучивал «Asoft», чтобы затем объединить результаты.
IX. Пользовательский интерфейс
Кажется, это был первый и последний крупный проект, в котором мне пришлось заниматься проектированием пользовательского интерфейса. Я не дизайнер, лишена художественных способностей начисто, и рисовать формочки ввода данных для меня скука смертная. Тем не менее, пришлось потратить два или три дня и мужественно изобразить макеты наших будущих форм, ибо на клиента они действуют анестезирующе. Увидев что-то, отвечающее своим представлениям, заказчик начинает думать, что так оно и будет реализовано, в результате чего успокаивается, расслабляется, и с ним можно успешно работать дальше. Далеко не всегда он осознает, что это лишь картинка, не подкрепленная даже реально существующим элементом интерфейса, а тем более – теми функциями, для выполнения которых он предназначен. Некоторым достаточно увидеть форму на экране, чтобы решить, что система готова, и вообще непонятно, чем мы тут еще занимаемся.
Довольно скоро «СОИ» отошло от практики включать в ТЗ макеты элементов интерфейса, отдав его полностью на откуп программистам. Это было сделано для того, чтобы не увязать в несущественных деталях на этапе согласования требований, а также не ограничивать заранее процесс разработки, требуя точного соответствия тому, что нарисовано в ТЗ, даже если реальные функции программы диктуют внести изменения.
В общем и целом, распределение обязанностей в проекте соответствовало специфике деятельности компании. Программистов не заставляли ставить задачу самим себе или тестировать ими же написанный код, тестировщики не занимались исправлением ошибок, а от меня не требовалось мыть полы или договариваться с клиентом о сроках выполнения задачи. Безусловный плюс для небольшой компании, в которых, в силу вечной нехватки квалифицированных кадров, один сотрудник совмещает в себе функции нескольких ролей, в результате не выполняя толком ни одной. У нас границы были определены четко, и ответственность каждого находилась в пределах этих границ. Меня могли съесть за плохое ТЗ, но никому не приходило в голову ругать программистов за написанный по нему код, так же как никто не трогал меня, если код не соответствовал ТЗ.
