ashein.comпортфолио

 

Collection Privée

08.01.2013 в 13:09 • ред. 08.01.2014 в 19:33, вер. 7 • без комментариев тэги - sales, shopping, site
Скриншот проекта
Скриншот проекта
Скриншот проекта

О компании

Компания Collection Privée (Частная Коллекция) была основана в 2009 году Антуаном Пуассонье и занималась продажей одежды и аксессуаров в России посредством флеш-распродаж. В основе их сайта лежал старый французский код, который они решили повторно использовать. Со временем организация открыла шоурум и отдельный офис в Москве, а также создала еще два интеренет-магазина. Последние фактически были копией базового сайта, но с другим оформлением и брендированием.

В августе 2012 года компания закрылась, предположительно вследствие того, что у нее закончились деньги на заработную плату собственным сотрудниками (не говоря уже о нанятом фрилансере).

Обязанности

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

  • Исправление, до- и переделывание системы статусов заказов, а также наладка взаимодействия баз данных с тем, чтобы количества товаров на сайтах и на складе всегда совпадали;
  • Починка местной системы массовой рассылки и отладка интеграции сайта со решением стороннего поставщика с тем, чтобы пользователи могли нормально отписываться от данных рассылок;
  • Отладка конфигурации системы управления учетом предприятия в том, что касается синхронизации с базами магазинов (учет от 1С);
  • Внедрение генераторов отчетов и сборщиков статистики для управленческого звена компании, чтобы те могли принимать решения на основе актуальной информации по продажам компании;
  • Интеграция со шлюзом онлайн-платежей (ASSIST в данном случае);
  • Создание отдельной секции сайта по бронированию путевок и интеграция сторонней системы бронирования в данный раздел;
  • Синхронизация базы товаров магазина с базой сторонних магазинов посредством создания соответствующих интерфейсов экспортирования;
  • Улучшение взаимодействия компании и контрагента-логиста методом внедрения стандартов по предоставлению данных для последнего.

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


TL;DR: подробнее о возможной причине распада компании см. ниже. С моей точки зрения на данный процесс сильно повлияло плачевное состояние IT-инфраструктуры.

Критика

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

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

Мне сложно описывать проблематику без специфичных терминов, поэтому вкратце о ней упоминается в технической части.

Общая мораль истории такова: не надо нанимать того или иного специалиста исключительно для того, чтобы делать что-то в императивном порядке. Не надо говорить "сделай мне это вот так". Следует давать указания, нацеленные на конечный результат, и принимать во внимание различные варианты реализации, которые вам предлагает исполнитель. Ведь существует множество неочевидных пунктов, которые вы, наверняка, не замечаете в силу того, что это не ваша специализация. Это касается и программирования, и дизайна - практически всего, чем нынче профессионально занимаются люди.

Техническое

Коротко о том, как дела обстояли в компании, и как в принципе дела делать не стоит.

  • В какой-то момент компания сменила хостера и переместила сайты во Францию. Тамошний хостер не давал к серверу никакого доступа, кроме как через FTP. Не было ни SSH, ни панели, ни кронтаба, ни просмотра логов в реальном времени. Сам сайт весил столько, что с него было просто невозможно снять дамп для создания тестовой копии. Что уж говорить о бекапах. Сложилось такое ощущение, что хостер зарабатывает технической поддержкой, поскольку только у него был нормальный доступ к серверу. Забавно также то, что сервер был выделенный, и платили за него очень немало.
  • Компания использовала 1C-Предприятие для целей учета, и данный пакет работал на основе локальной базы данных, которая, в свою очередь, синхронизировалась с магазинной. Скрипт синхронизации запускался каждую минуту, а работал около 40 секунд. Оставалось только догадываться, через сколько месяцев вся эта кухня разрослась бы перманентной синхронизации. Десинхронизация баз также была частым случаем.
  • В основе кода сайта лежал собственный простой MVC-фреймворк, однако с его использованием были написаны только старые страницы. Если судить по коду, то над "эволюцией" сайта последовательно работало человек пять. Некоторые страницы были написаны без использования локальных библиотек, "с нуля", практически нигде не было комментариев. Не было единого стандарта в написании кода, не было никакой документации. Очевидно, что все писалось без расчета на будущие доработки и на будущее вообще.
  • Когда в компании решили сделать два магазина-клона, то какой-то умной душе пришла интересная идея сделать магазин из тестовой платформы сайта. Так была потеряна инфраструктура для отладки изменений в главном магазине.
  • Сток (количество товаров на складе) на сайте отслеживался по текущим остаткам. Если был создан заказ с товарами, то эта цифра уменьшалась, если заказ отменяли — увеличивалась.Если заказ доставлен частично, то не все показатели надо было корректировать. Отмена и частичная отмена заказа, а также другие статусы заказа на сайте хранились в текстовом формате, и вся стоковая логика работала на операциях сравнения текста статусов. Эта логика дублировалась во многих частях сайта, а также в 1С, конфигурация которого была недоступна для меня. В какой-то момент несмотря на то, что система статусов и стока не поддавалась практически никакой доработке, менеджмент решил, что надо добавить новых статусов заказам. Пришлось потратить значительное время, чтобы очистить код от избыточной логики, перевести статусы из текстовой формы в списочную, а также перенести всю общую логику в триггеры базы данных. Еще больше времени было потрачено на то, чтобы обнаружить в 1С банальные ошибки, которые мигрировали с синхронизацией в магазинную базу и убивали реальные цифры стока. На мой взгляд, это была самая тяжелая проблема, которую в итоге решили. Но, к сожалению, было уже поздно, да и даже нормальное решение данной проблемы смотрелось в лучшем случае костылем.