Собственно, ситуация была вполне понятная и вполне объяснимая. Никто и никогда, создавая какой-либо новый проект с весьма туманными на момент старта перспективами, не будет закладывать в функциональность бешеную нагрузку: это просто невыгодно. Поэтому обычно составляется реальный бизнес-план, определяется планируемая загрузка с предполагаемым ростом, под эту загрузку проектируется соответствующая структура. В «Рексофте» так и сделали, в результате чего OZON.ru счастливо проработал три года.
Впрочем, в процессе эксплуатации системы периодически вылезали некоторые «косяки». Например, требовался ручной ввод номера заказа – нечто вроде прототипа штрихкода. Этот номер содержал кучу цифр с тире, и вводить их было крайне затруднительно – отгрузка отнимала очень много времени. Владимир Долгов, когда увидел эти страдания, полез в Интернет и там отыскал некое устройство, сканер, которое включалось в разъем клавиатуры, считывало баркод и передавало его по системе вместе с кодом Enter, – таким образом процедура очень сильно упростилась.
Но проект рос очень активно (тем более что в его раскрутку вкладывались весьма значительные деньги), и это обстоятельство – чем дальше, тем более жестко – требовало переработки и масштабирования практически всей IT-структуры. Заметно прибавившиеся и постоянно накапливающиеся проблемы с производительностью как витрины, так и бэк-офиса говорили о том, что пришла пора менять всю систему, иначе под угрозой оказывается существование всего магазина.
Одно было понятно совершенно точно: механизмом OZON.ru отныне должен заниматься собственный IT-отдел, тем более что таковой уже существовал.
На повестке дня оказался следующий вопрос: какое из двух стратегических направлений стоит выбрать? Первый путь – заказать у «Рексофта» модернизацию всего программного механизма и далее развивать его собственными силами. Второй путь – начать все с нуля, то есть всю функциональность модулей OZON.ru разработать собственными силами с привлечением современных программно-аппаратных решений.
Оба этих пути имели свои плюсы и минусы. Первый вариант позволял не делать резких движений, однако предполагал существенные затраты и, с точки зрения руководства, стратегически был неправильным. Второй вариант был чреват серьезными потрясениями и вынуждал разработчиков частично проходить тот путь, который в «Рексофте» уже преодолели в течение последних нескольких лет. Однако с точки зрения руководства, такой подход был стратегически верен: новый IT-отдел должен сам принять решение о том, какие платформы будут использоваться, он должен создать новый механизм и сопровождать его.