Я занимался администрированием баз данных в казахстанской компании «Bimash» - бизнес-партнере IBM. Очень интересный проект в масштабах государства. Необходимо было получить информацию из 12 министерств, собрать все в единое целое по различным признакам и построить на основании этих данных единый реестр по физическим и юридическим лицам Казахстана. Больше двух лет работа двигалась неспешно, конкретных результатов не было, но их быстро и не ждали. Проект таких масштабов требует огромного количества времени. За эти два года я успел хорошо изучить DB2, приобрел практический опыт работы, сдал несколько экзаменов IBM и получил сертификаты. Все было замечательно. А потом случилось то, что и должно было случиться: заказчик стал требовать результат, и начались авралы...
Следует отметить, что головное подразделение компании находилось в Алмате, а заказчик – в Астане. Руководитель проекта и все разработчики регулярно ездили в командировки к заказчику. Когда начались авралы, командировки стали практически бессрочными. Сначала не выдержал один менеджер проекта, потом другой. Оба вернулись домой в Алмату, чтобы не разрушать семью. Мне, как самому опытному из «местных», предложили руководить проектом. Ситуация была почти катастрофическая. Все программное обеспечение готово, необходимо только сделать сам реестр из имеющихся данных и рассчитать налоги. Т.е. сверить десятки миллионов записей, разложить их в нужные таблички и провести расчеты. И вроде весь этот трудоемкий процесс должен был вот-вот закончиться. Каждый день разработчики говорили, что завтра будет все готово. А завтра что-то не получалось, и все начиналось заново – доработка ПО, запуск, быстрое начало и ... утром опять те же неутешительные итоги. Заказчик прекратил финансирование и сказал, что если в ближайшее время результат не будет достигнут, то он включит нас в список неблагонадежных поставщиков и тогда фирму можно смело закрывать. А у меня практически не было представления о бизнес логике в проекте.
Несмотря на все это я решил согласиться.
Утро у всех наших сотрудников тогда начиналось с совещания у очень большого начальника – представителя заказчика. Перекличка – все ли на месте, доклад что сделано (чаще, что не сделано), крик, ругань, план на 24 часа и вперед за работу.
В успех не верил никто.
Три дня как под копирку – совещание, попытки найти новые решения методом мозгового штурма, неудачи и снова неудачи. За это время я успел вникнуть в проблему, изучить технические средства, которые используются для ее решения. Очень высоко оценил уровень наших специалистов, потому что понял какая колоссальная работа была проделана за последний месяц. Особенно на фоне результатов за предшествующие полтора-два года. Но это никак не изменяло безрадостную ситуацию в целом по проекту. Стало понятно – дальше так продолжаться не может. Нужен принципиально другой подход, другие решения.
Ночью я практически не спал, думал, что же можно сделать. От решения проблемы отвлекали назойливые мысли о том, что по-хорошему всем этим заниматься надо было минимум год назад, когда еще было время для проб и ошибок. Общее представление о задаче у меня уже сформировалось. Нарисовался один вариант, который должен был отработать с производительностью в 1000 раз большей, чем при построчной обработке с помощью программ. Однако у этого варианта были определенные ограничения. И вот утром, идя на работу, я встретил нашего бизнес-аналитика Рашида. Студент 3-го курса, умный и талантливый парень. В отличие от меня он представлял, что и как мы делаем в деталях. Я быстро изложил ему свою идею, объяснил, какие есть ограничения, и попросил подумать, что можно сделать таким способом. Рашид обещал все проанализировать и дать ответ. Вся надежда была на него.
На совещании как обычно пришлось объяснять, что результатов нет, работаем, когда закончим неизвестно, задача нетривиальная. Вроде бы вины за собой я не чувствовал, но все равно было стыдно и противно. После совещания я толком ничего не делал. Не было никакого желания. Я ждал заключение Рашида – реально или нет решить задачу, используя новый подход. Очень хотелось подойти и спросить – получится или нет. С трудом заставлял себя отказаться от этого, потому что понимал – буду только мешать. И вот где-то ближе к обеду Рашид сообщает, что задача теоретически решается предложенным мной методом. Нужно было написать две небольших программки – одну могли сделать разработчики, а другую мы с Рашидом. Снова появилась надежда.
Где-то к 12 ночи свою часть разработчики уже выполнили и были готовы алгоритмы для второй части. Мы с Рашидом начали писать скрипты и тут же тестировать их на реальных объемах. После реализации первых шагов алгоритма стало видно, что производительность даже выше ожиданий. Идея материализовывалась. Внутренние ощущения не передать словами. Вероятно, именно этот позитив помог к 8 часам утра завершить задачу. И это несмотря на то, что работать без сна пришлось фактически сутки.
Еще почти полгода мы находили и исправляли ошибки, вносили изменения с учетом дополнительных требований. Но этот день стал переломным для проекта. Мы показали результат!
С тех пор было многое – заказчик опять начал платить деньги, за пару лет ежегодный бюджет проекта увеличился в пять раз, появилось много новых проектов, наша компания вошла в TOP-100 бизнес-партнеров IBM по СНГ в 2005 году. Пару раз пришлось спасать другие проекты в условиях кризиса. Я уже переехал из Казахстана в Россию и теперь работаю здесь. Но этот день я запомнил навсегда, как первый опыт антикризисного управления. Сначала я был бесконечно рад тому, что мы справились с поставленной задачей, и чувствовал себя настоящим героем. В последствии я не один и не два раза анализировал эти события. И постепенно, это вместе с новым опытом привел к осознанию того, что все проблемы были связаны с неправильными подходами к управлению проектами. Я понял, какое важное значение имеют очень простые вещи – планирование, управление рисками, ресурсами, финансами, концентрация на продукте… Постоянный промежуточный результат. Тогда такие авралы никогда не наступят и не нужно будет что-то придумывать на лету, сидеть ночами и делать что-то на скорую руку.
Источник фото: Freeimages.com
"...сверить десятки миллионов записей, разложить их в нужные таблички и провести расчеты..."
"...Нарисовался один вариант, который должен был отработать с производительностью в 1000 раз большей, чем при построчной обработке с помощью программ..."
Знакомая проблема. При построчной обработке, время выполнения даже таких простых операций, как удаление дубликатов, или удаление из списка А записей, содержащихся в списке B, пропорционально квадрату количества строк, и при десятках миллионов записей оказывается нереально долгим. Особенно в те годы.
Решение: хеширование записей с целью уйти от попарного сравнения строк. Время выполнения операции в этом случае пропорционально количеству записей, а не их квадрату, и не улетит в бесконечность при росте количества строк хоть до миллиардов.