Внутренняя кухня платформы Docpart

Мы создаем интернет-магазины автозапчастей уже почти 14 лет. За это время рынок менялся не один раз: появлялись маркетплейсы, менялись требования клиентов, изменялось законодательство в сфере торговли, налогов и бухгалтерии, росли ожидания по скорости, удобству и надежности сайтов. Все это время мы развиваем платформу Docpart — CMS для интернет-магазинов автозапчастей, которая устанавливается на хостинг владельца магазина и становится основой его бизнеса.

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

Откуда берутся требования и идеи

Разработка Docpart никогда не велась в вакууме. Мы не создаем функции «потому что так принято» или потому что это модно. Основной источник идей — это постоянное общение с владельцами интернет-магазинов автозапчастей. Мы запускаем магазины для клиентов, сопровождаем их после запуска, видим их реальные бизнес-процессы, проблемы и точки роста.

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

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

Команда и формат работы

Сегодня над Docpart работает команда из 10 человек. Это разработчики, специалисты по архитектуре, тестированию и поддержке. Часть команды работает в офисе, часть — удаленно. Такой формат позволяет нам сохранять живое взаимодействие внутри команды и при этом привлекать специалистов независимо от их географии.

Работа строится вокруг общего кода платформы. У нас есть единый git-репозиторий, в котором хранится вся история развития Docpart. Это не просто технический инструмент, а основа дисциплины разработки. Любые изменения — от небольшой правки до крупного функционального блока — проходят через систему контроля версий. Это позволяет видеть, кто и зачем вносил изменения, быстро находить причины проблем и при необходимости откатываться к стабильным состояниям.

Как появляются доработки

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

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

После согласования подхода задача уходит в разработку. Чаще всего работа ведется итеративно: сначала создается базовая версия функционала, затем она дорабатывается, расширяется и оптимизируется.

Тестирование как обязательный этап

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

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

Только после этого изменения готовятся к выпуску. Стабильность и предсказуемость работы платформы для нас важнее скорости внедрения любой новой функции.

Релизы и обновления

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

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

После выхода релиза мы внимательно следим за обратной связью. Если появляются вопросы или нестандартные ситуации, они оперативно анализируются и при необходимости выпускаются корректирующие обновления.

Небольшой фрагмент git-репозитория Docpart

Поддержка и сопровождение

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

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

Почему мы уделяем так много внимания архитектуре

Docpart — это долгоживущий продукт. Мы изначально понимали, что платформа для интернет-магазинов автозапчастей не может быть «быстрым решением». Магазины работают годами, обрастают данными, интеграциями, бизнес-логикой.

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

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

Баланс между универсальностью и индивидуальностью

Одна из сложнейших задач при разработке Docpart — найти баланс между универсальной платформой и возможностью индивидуальных доработок. Интернет-магазины автозапчастей сильно отличаются друг от друга: по ассортименту, по логистике, по модели работы с клиентами.

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

Почему мы решили рассказать об этом

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

Docpart для нас — это не просто программный продукт. Это платформа, которая развивается вместе с рынком автозапчастей и вместе с бизнесами наших клиентов. Именно поэтому мы считаем важным делиться не только результатами, но и процессом, который за ними стоит.

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