Второй частью серии кейсов про доработку, развитие и продвижение Интернет-аптеки хотелось бы сделать описание некоторых организационных моментов работы. Первую часть кейса, в которой обсуждаются идеи по доработке Интернет-магазина аптеки, их реализация, и что это дало - можно почитать тут.
Как нам кажется, данный кейс был бы полезен Интернет-маркетологам, владельцами Интернет-магазинов, а особенно Интернет-аптек в том случае, если они планируют развивать свои проекты и выбирают подрядчиков для этого. Есть моменты, на которые нужно обратить внимание, о них ниже.
Наш клиент, крупная сеть, аптеки которой расположены в Санкт-Петербурге, Архангельске и других городах, имел достаточно сложную организацию 1С инфраструктуры и выгрузок в Интернет-магазин. Там и различные склады, остатки на них, десятки тысяч позиций для выгрузки, отображение остатков в Интернет-магазине для различных аптек (когда пользователь может видеть, где он может забрать 100% от своего заказа, а где, например, только 75%).
Все это требует высокого уровня компетенций как 1С специалиста клиента и его маркетологов, так и аккаунт менеджера проекта и разработчика Битрикс с нашей стороны. Вместе в плотной связке мы можем достигнуть наибольшей эффективности.
Опишем ниже подводные камни, с которыми нам пришлось столкнуться, и, которые вы могли бы учесть в своем проекте:
Документация и описание структуры баз данных, архитектуры выгрузок и всего проекта в целом. У клиента всего этого не было. Надо понимать, что проект разрабатывался и доделывался различными командами до нас. Те, кто с этим сталкивались, сейчас, наверное, поморщились :) Да, там было множество костылей с неясными взаимосвязями. И конечно, первая рекомендация здесь (что мы и сделали) - это тщательное изучение проекта, составление схем и описание архитектуры, для того, чтобы сократить количество времени и багов в будущей разработке. Без такой работы разработчику приходится при реализации задач прямо на ходу разбираться с тем, как построен проект. Это всегда увеличивает срок разработки и уровень напряжения. Клиенту же приходится по ходу реализации проекта постоянно включаться в него, давать ответы, поднимать какую-то информацию. Лучше постараться выполнить эту работу (по возможности) предварительно, до начала работ. Это конечно не исключает дальнейшие трудности в работе с чужим кодом, множеством костылей, но по крайней мере сокращает количество этих трудностей. Если вы владеете или управляете Интернет-магазином аптеки и планируете работы с новыми разработчиками, обратите на это внимание.
С командой 1С, маркетологами и теклидами клиента мы создали общий Телеграм чат. Не новинка, все так делают. Но хотелось бы тут отметить, что это действительно важно в подобных проектах и на этот момент коммуникации обратил внимание всяк, собирающий с этим работать :) Это помогало оперативно обмениваться информацией о работе выгрузок остатков, вносить правки и корректировки. Особенное внимание надо обратить на коммуникацию Битрикс разработчика (или разработчика платформы, на которой построен сайт аптеки) и 1С специалиста, если выгрузки остатков идут из 1С. В больших проектах история изменений может быть долгой и объемной, и если она нигде не описана, то работать можно только на основе этой коммуникации).
И, конечно, не забудьте иметь 2 тестовых стенда для разработки. Один из них основной, другой посредник между боевым сервером (так мы называем продакшн) и тестовым стендом. Это особенно помогает при тестировании серверных настроек и того, как они влияют на результат работы.
Пункт для новичков, если вы занимаетесь вопросом недавно - прежде чем обновить версию движка сайта (если он построен, например на том же Битриксе) убедитесь, что ранее там не были реализованы кастомные решения. Все это вполне вероятно перестанет работать, если вы обновите платформу. К этому надо быть готовыми. В нашем случае мы провели обновление на тесте, протестировали сайт после обновления и обнаружили часть поломок, которые смогли оперативно устранить.
Нагрузка на сервера. Однажды утром мы проснулись и увидели, что сайт Интернет-аптеки не работает, а потом снова работает, а потом снова не работает. Показатели нагрузки выдали нам интересные графики, где систематически по ночам нагрузка взлетала так, что сайт падал. Да да, те кто сталкивался с этим, уже произнесли про себя слово “Дос”. Или быть может “Парсер”. В любом случае сайт подвергался внешней угрозе, что в итоге приводило его к падению. В нашем случае самым эффективным решением было усилить сервер так, чтобы его ресурсов хватало. Реализовав такой апдейт, мы “перешагнули” проблему.
Такими мы увидели подводные камни, о которых мы хотели бы написать отдельный кейс. Спасибо за внимание, продолжение этого кейса следует.
Кстати, вот здесь наш Телеграмм канал “Тусовка владельцев сайтов”. Там публикуется полезное инфо для тех, кто управляет сайтами и интернет-магазинами. Если вам хотелось бы, чтобы мы подключились к созданию, доработке или продвижению Вашего интернет-магазина, нас можно найти здесь: Honey Hunters Digital.