Привет! На связи Антон, техдир Metalcode.

У нашей команды 10-летний опыт разработки еком-проектов на php, битрикс. От типовых решений Аспро до сложной кастомной разработки с десятками интеграций. Хотим отрефлексировать и превратить этот опыт в полезные кейсы.

О чем этот канал?

Расскажем кому и зачем нужен стек php, битрикс в 2024.
На каких проектах применять и кого взять в команду.
Про процессы разработки и лучшие практики управления долгосрочным развитием проектов.

Отдельное внимание уделим безопасности проектов на 1С-Битрикс (важная тема учитывая опыт двух последних лет).

Постараемся сделать этот канал источником знаний про еком – предметных, связанных с конкретными решениями и технологиями. Сервисами и интеграциями. Чтобы вы могли взять и применить в своих проектах.

Кому будет полезно?

Маркетологам и менеджерам проектов – если вы развиваете проекты связанные с электронной коммерцией, интернет-магазин или маркетплейс. Взаимодействуете с разработкой, подрядчиками.

Тимлиду и техдиру – если управляете процессами разработки, ищете лучшие практики и интересуетесь опытом коллег.

Владельцу – если развиваете свою розничную торговлю и хотите лучше понимать процессы построения екома и техническую составляющую.

Чем мы можем помочь?

Мы умеем эффективно развивать еком-проекты в ограниченном бюджете. Знаем как построить команду и процессы разработки.

Предоставляем php, Битрикс-разработчиков для еком-проектов.

Аутсорс от 2500р/час по T&M
Аутстаф от 1800р/час middle bitrix

Для связи: @andreyfrolov

Переход на php8.х в Битриксе

Мы долгосрочно развиваем еком проекты, Битрикс и php входит в наш стек.

Сам переезд на php8 – тема довольно заезженная, но хочется раскрыть ее положительные стороны для команды разработки.

Если мы принимаем проект и там старая версия php, то данная задача непременно оказывается в беклоге.

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

Объясняю, почему эта задача имеет ряд положительных моментов:

1. Повышаем безопасность проекта.

Тут все в плюсе. Проблемные, уязвимые проекты никому не нужны, ни нам, ни бизнесу.

2. Усиливаем свое знание проекта.

Если удается затащить поднятие php в приоритетные задачи на старте сотрудничества – это большая удача и возможность для разработчиков глубже погрузиться в проект, разложить его по полочкам.

В php8 подрезали старые расхолаживающие косяки (работа с null, неявно объявленные статические функции и прочее, полный список легко гуглится).

Часто весь проект пронизан такими мелкими недочетами, которые теперь стали критичными. Они то и делают переезд столь болезненным. Соответственно, устраняя их неизбежно приходится разбираться как “оно” работает, часть поправить, часть переписать.

3. Возможность порефакторить.

И в новом, и в старом проекте, рефакторинг – тема больная. В идеальном мире мы имеем отдельный бек-лог с тех. долгом и даже ресурсы на его реализацию. В реальном – хватаемся за всякую возможность поработать с недостатками кода и архитектуры.

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

Плюс для того, чтобы не делать лишней работы, помогает навести порядок, убрать неиспользуемое:
- старые библиотеки
- неиспользуемые внешние модули
Как понять что оно неиспользуемое? – разбираться в проекте и зависимостях, рефакторить.

#ecom #битрикс #безопасность

Еком-система

Планирую написать несколько постов для выравнивания понимания контекста и чтобы к ним можно было делать отсылки в последующих публикациях. Информация простая, но важная.

Понятие еком-системы:

В современном екоме невозможно мыслить только понятием Интернет-магазин. Вместо него существует термин Еком-система — система состоящая из набора подсистем, объединенных между собой интеграциями для обмена данными. Так в еком-систему входит складской учет, системы управления клиентами CRM, сайт (собственно интернет-магазин), системы аналитики, экварйинги, облачные кассы и прочее.

Большие Энтерпрайз системы могут состоять из десятков сервисов.

Поэтому под проектом в екоме мы всегда подразумеваем именно еком-систему, а не отдельно взятый интернет-магазин.

Витрины

Интернет-магазин играет не последнюю роль, так как именно с ним взаимодействует покупатель. При этом часто витриной выступает не только магазин, но и мобильное приложение, и даже маркетплейсы.

По маркетлпейсам стоит сделать поправку, они требуют корректировки модели бизнеса, но с технической точки зрения они также встраиваются в еком-систему. Например, интегрируем их в складской учет 1С: отдаем в маркеты остатки по товарам, обрабатываем заказы, формируем отчеты комиссионера, передаем в бухгалтерию и так далее.

Команды в еком-системе:

Также в рамках понятия еком-системы важно отметить, что ее обслуживает несколько команд. Редко одна команда автоматизирует склады в 1С и они же развивают CRM.

Каждая команда должна учитывать общую архитектуру системы и взаимосвязи. Невозможно просто дорабатывать интернет-магазин на битриксе и не учитывать все остальное.

Резюме:

— еком-система — это набор сервисов, связанных между собой;
— архитектуру еком-системы должен строить техдир / CTO;
— каждую подсистему может обслуживать отдельная команда, но они должны быть посвящены в общий контекст, знать взаимосвязи и интеграции.

Как достигаем общего знания между командами? Напишу в ближайших постах (спойлер: чертим целевую архитектуру, готовим документацию, описываем бизнес-процессы).

Тестовый стенд

Мало того, что сама еком-система составная, для разработки нам требуется несколько ее копий. Эти копии называются стендами (или контурами).

Зачем? Чтобы сократить риски бизнеса, изменения и доработки тестируется отдельно от основного проекта, с которым взаимодействуют покупатели и бизнес.

Сейчас сложно представить проект, где разработчики меняют что-то напрямую в боевом сервисе. Зачастую у них даже нет туда доступа, так как все построено через системы доставки изменений. Об этом ниже в данном посте.

Прод и стейдж

На проекте должно быть минимум два стенда: продовый (prod) и тестовый (stage). Плюс несколько копий для разработки и тестирования.

Так приходится разворачивать копии CRM, 1С, сайта и других составляющих еком-системы, которые позволяют это делать (а позволяют обычно только системы размещенные на своих серверах). Облачные сервисы менее адаптивны в этом смысле, но иногда в них есть тестовый режим.

Для разработчиков разворачиваются только те сервисы, с которыми они взаимодействуют, а не вся еком-система.

Может ли битрикс-разработчик ограничиться только локальной копией интернет-магазина? Сильно зависит от задач. Если они не касаются других сервисов и интеграций — можно, но учитывать зависимости все равно придется.

В этом кроется несколько нюансов:

— тестовые стенды "протухают" — устаревают. Нужно следить за актуальностью.

— зачастую тестовый стенд невозможно развернуть в полном объеме (часть облачных сервисов все равно приходится либо исключать, либо очень бережно и временно внедрять боевой сервис в тестовый стенд);

— сервера для тестового стенда обычно имеют урезанные ресурсы (относительно прода) — это накладывает нюансы;

— запрещено уносить персональные данные пользователей дальше продового стенда — для решения этой задачи применяются отдельные практики (расскажу =), тоже накладывает нюансы.

Доставка изменений

И самое главное, что стенды должны быть связаны между собой системами доставки изменений. В маленьких проектах этого можно достичь небольшими ресурсами (контроль версий + миграции баз данных). Для крупных есть целый набор практик CI / CD.

В этой логике разработчики вносят изменения только на своих копиях, а дальше изменения попадают в общий "котел" — удаленный репозиторий и переносятся на проект.

Тестовый стенд выступает в роли того места, куда сливаются изменения от всех разработчиков и команд, там происходят финальные тесты.

Резюме:

— для разработки требуется несколько копий проекта, связанных между собой;
— разработчики не имею доступа к продовому стенду, делают все на своих копиях;
— тестовый стенд приходится периодически актуализировать;
— чем лучше построена система доставки изменений — тем меньше разработчики тратят времени на лишние действия и быстрее бизнес получает результаты.

В ближайших постах расскажу про цикл разработки применительно к описанной архитектуре нескольких стендов.

Интернет-магазин мертв, да здравствует еком-система!

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

Я техдир в Metalcode, без ложной скромности скажу, что набегает 10-лет опыта в разработке и не понаслышке знаю про эти самые еком-проекты и процессы.

https://vc.ru/dev/990657-kak-ustroen-ekom-razbiraem-bazovye-principy-ekom-sistemy

Выпустили сайт Metalcode

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

Расскажу про процесс отдельным постом, пока хочется подробнее про сам металкод.

Кто мы?

Энтузиасты, разработчик, проджект и дизайнер, которые в 2015 собрались в компанию. Рассказывал, что мы до сих пор вовлечены в клиентские проекты и почти не жалеем об этом.

Раньше мы были ARTWOT, сейчас ребрендились в Metalcode. В рамках которого оставили фокус на одном, очень понятном стеке php,bitrix, чтобы бустануть рост за счет горизонтального масштабирования.

Для кого?

У нас в фокусе малый и средний бизнес. Клиенты с оборотом до 2млрд. Еком-проекты работающие на битриксе, laravel или платформе ensi.

Есть опыт работы с продуктами питания и сроками годности. Умеем автоматизировать склады в 1С. Точно построим качественную интеграцию с 1С УТ.

Выстроим не раздутую еком-систему, процессы разработки или просто усилим команду на проекте через аутстаф.

Много лет (реально много, около 8 лет) техподдержки интернет-магазинов на битриксе в опыте.

Клиенты

— Мы партнеры со Спорт Фермой: запускали еком в России и ОАЭ. Строили еком-систему.

— Ведем разработку для ХК Авангард: магазин мерча и бекенд для мобильного приложения.

— Развиваем шинного диллера (NDA): интеграция с поставщиками и кабинеты оптовиков.

— Развиваем проект для российского производителя холодильного оборудования.

Чуть больше на сайте. Готовим кейсы, пока будем писать на VC.

Разработка в Metalcode — это:

— собранная как пазл распределённо-удалённая команда;

— высокий уровень самостоятельности команды;

— прямой доступ к разработчикам для ускорения коммуникации;

— экспертиза в e-commerce-проектах;

— прозрачный процесс работы с отчетностью.

Открыты к сотрудничеству @andreyfrolov

Защищаем персональные данные

⚡️ Сегодня интернет-магазин собирает много персональных данных покупателей. Системы аналитики берут всё от контактов, до адресов доставки, истории просмотров и прочего. Всё до чего могут "дотянуться".

Тема защиты персональных данных (ПД) обширная, обрастает все большим количеством законов и можно без преувеличения назвать ее одной из повесток ИТ. Поэтому есть целые комплексы мер и практик по защите ПД.

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

Процессы разработки требуют несколько копий еком-системы — стендов.

⚡️ При этом часто вижу, что пользовательские данные таскают по всем копиям, вплоть до локальных для разработчиков. Это чревато последствиями и доводит ИБ-эшников до сердечного приступа.

Ситуация интересна тем, что здесь присутствует конфликт интересов.

С одной стороны, мы хотим максимально обезопасить проект и оставить данные пользователей только на продовом стенде (не допустить их переноса на любые копии проекта).

С другой стороны разработчики не должны работать с пустой базой, где нет ни пользователей, ни заказов, ни прочих связанных сущностей. Так они могут упустить критически важные моменты.

В этом случае нас спасает практика применения обфускаций.

Обфускация данных — замена исходных данных фиктивными, для защиты конфиденциальной информации. В электронной коммерции применяется для маскировки персональных данных покупателей.

Существует два основных подхода реализации обфускаций:

— ручной - написание скриптов, которые работают с базой и маскируют данные;

— использование специализированного ПО.

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

Бизнес-требования или ТЗ

Описывая кейсы по металкоду, поймал себя на мысли, что мы 100 лет (не меньше) работаем с бизнес-требованиями и почти никогда с финальным ТЗ.

Что понимаю под этими терминами:

— ТЗ (техническое задание) — четко сформулированное решение, с описанием логики и технологий.

— бизнес требования — обобщённое описание целей и проблем бизнеса, которые нужно решить. Вполне может присутствовать описание требуемой функциональности, без конкретики, какими инструментами это будет реализовано.

То, чем именно оперирует команда, что и в каком виде ей прилетает от заказчика — определяет формат работы.

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

Соответственно от заказчика получаем описание проблем-задач в виде бизнес-требований, которые перекладываем в конкретные решения, оцениваем, планируем и внедряем.

Заказчиком выступает не один человек, а руководители (либо менеджеры) направлений в компании: маркетинг, продажи, smm, склад.

Поэтому в нашем случае очень важно уметь работать с бизнес-требованиями, собирать их с департаментов и превращать в конкретные решения.

Где может отсутствовать такой процесс? Например при формате работы по аутстафу, когда весь процесс на стороне заказчика, от исполнителя нужны только руки.

Команды, которые "как бы аутсорсеры", но требуют от заказчика исчерпывающего ТЗ, мотивируя тем, что без него результат не определен (другими словами ХЗ) — вызывают грусть.

Хорошая статья на эту тему от коллег на VC >>

Интернет-магазин peak-sport.ru - официальный в России магазин спортивного бренда Peak.

Наша команда провела редизайн страницы оформления заказа. На изображениях прошлый дизайн и новый дизайн.

- Добавили выбор местоположения;
- Выделили партнёрские службы доставки с расчётом стоимости и выбором ПВЗ;
- Добавили возможно применить промокод на скидку;
- Реализована проверка заполнения обязательных полей, таких как ПВЗ, конаткты покупателя. Без них заказ не оформится, а подскажет покупателю, что осталось заполнить.

Этапы работы:
Проектирование
Дизайн
Разработка
Тестирование и запуск новой версии страницы.

Общий срок работы от проектирования до релиза - 10 дней.

Смысл работы команды металкода - помогать бизнесу строить и развивать свой еком: устойчивый, масштабируемый, удобный для покупателей.

Ключевое здесь Помогать.
Своим опытом и накопленной экспертизой.

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

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

Результатом стратсессии будет план действий по решению выявленных проблем и независимый взгляд со стороны на текущую ситуацию.
Вы сами решаете как использовать результаты нашей встречи.

Какая моя выгода за бесплатную работу?
Благодаря вам я собираю ещё больше опыта в решении проблем в екоме и развиваю свою насмотренность.

Возможно вы станете клиентом Metalcode и мы вместе приступим к выполнению плана.

Для записи пишите мне в личку "Нужна стратсессия" @andreyfrolov