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

Как правило, мы подключаемся к проекту, если готовые системы не могут полностью решить его задачи. Эта история началась для нас с выбора: стоит ли вообще идти как аутсорс-команда в разработку кастомного бэкофиса для маркетплейса или лучше отказаться? Почему мы раздумывали? Все это происходило в 2020-м пандемийном году, и на тот момент у нас еще не было большого опыта разработки кастомных интеграций с нуля, плюс риски пандемии, но в то же время расцвет e-commerce давал нам пищу для размышлений. Кастомный бэкофис нужно было разработать для стартапа – онлайн-платформы стриминг-шопинга. Это был совсем нестрандартный маркетплейс, отличавшийся от Ozon, Wildberries и других популярных ecom-площадок. Ведущие в режиме live показывали и объясняли «фишки» разных товаров, а покупатели могли приобрести их здесь и сейчас. Признаюсь, согласился я на фразе «Да что тут делать? Всего три таблички» — нам предстояло собрать в базе данных информацию о продавцах, товарах и заказах, и развернуть веб-приложение, которое позволит реализовывать процессы, связанные с этими тремя сущностями. Спойлер: на этом все не закончилось, но мы смогли найти достойные решения.

Вот что в итоге мы интегрировали с бэкофисом:

1. Отдельный выделенный кол-центр

2. CloudPayments

3. amoCRM

4. sms.ru

5. Отдельный B2B-портал для продавцов

6. Само приложение для покупателей на стримах

7. СберЛогистику (ex. Shiptor)

8. Boxberry

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

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

А это модель данных бэкофиса:

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

1. Админка может быть автогенерируемой

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

Чтобы избежать лишних расходов, мы отказались от разработки отдельного фронтенда и использовали библиотеку для автогенерируемых интерфейсов Sonata Admin Bundle на фреймворке Symfony. Отдельный «фронт» удорожал бы проект как минимум в 1,5 раза; по нашим подсчетам, эти средства ушли бы сперва на проектирование и дизайн, а затем на привлечение отдельного фронтенд-разработчика и тестировщика. А для создания автогенерируемой админки нужен всего один разработчик и минимальное количество часов работы. С тех пор мы практикуем такой бережный подход к разработке и ресурсам и на других проектах. Подобные решения есть на других технологических стеках. Преимущества таких автогенерируемых решений для нас как разработчиков в том, что это готовые, быстро настраиваемые и при этом протестированные временем варианты. Пользователи при этом получают гибкий функционал управления веб-приложением, и, не имея навыков разработчиков, могут самостоятельно править контент или менять некритичные настройки.

2. Если отдельные приложения под iOS и Android — это дорого, максимально оптимизируем веб-интерфейс под смартфоны

Оказалось, чтобы продавать в режиме Live, информацию о товарах часто нужно подгружать незадолго до стрима. Например, иногда продавцам нужно было выгодно продать на стриме остатки. В таких случаях фото и описания товаров они выкладывали прямо из торговых залов со своих смартфонов в разработанный нами B2B-портал. Портал соединялся по API с бэкофисом. С одной стороны, если бы у нас было отдельное приложение, пользователю было бы проще им пользоваться, т.к. у большинства людей сформировались основные паттерны работы с приложениями. С технической точки зрения приложение бы упростило работу с привычным функционалом, например, передавать фото в товарный каталог можно было бы прямо с камеры мобильника. Или можно было бы ускорить загрузку нужных страниц, например тех, где пользователь заполнял товарные атрибуты. Но мы упирались в отсутствие бюджета на отдельные приложения под iOS или Android.

За счет чего урезали финансы и ресурсы в этой части?

Отказались от разработки приложений под разные устройства в пользу более универсального решения — мобильной версии B2B-портала. Постарались сделать его как можно более удобным и легким. Таким образом сократили количество разрабатываемых сущностей и не стали тратить время на релиз приложений в сторах. При этом мы не экономили на качестве разработки и уделяли много внимания тестированию. В том числе много тестировали «в полях», когда команда выезжала «на места» к продавцам и операционным сотрудникам в другой город и проверяла работу портала на боевых задачах.

B2B-порталу не нужен был свой отдельный бэкенд, поскольку он соединялся по API с бэкофисом и вся «подкапотная часть» лежала там и не требовала дополнительных синхронизаций. Соответственно, мы существенно экономили на разработке еще и бэкенда.

Примеры некоторых экранов B2B-портала:

3. Если на рынке начал действовать новый закон — готовьтесь потратить время и разобраться, чтобы потом не тратиться на штрафы

В любом проекте есть ситуации, где тотальная экономия может обернуться боком, приведу пример, с чем мы столкнулись и на этом проекте. Пока мы разрабатывали бэкофис, вышел закон, обязывающий продавцов маркировать некоторые товары: сигареты, обувь, одежду и белье, парфюмерию и другие. Таким образом в бэкофисе появлялся еще один дополнительный атрибут — «маркировка». Сложность в том, что в e-commerce невозможно заранее знать код маркировки, если вы продаете штучный товар. Например, если мы продаем одежду, на каждую рубашку будет отдельный код маркировки. Но в момент, когда мы продаем товар, мы еще не знаем, какой код мы реализуем. Считать остатки в таком случае очень сложно. Поэтому проще сначала продать товар, а определенный код маркировки присвоить уже при комплектации.

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

Итак, нам нужно было учитывать такие моменты, как «Поступление денег от клиента» → «Комиссия за получение денег от Cloudpayments» → «Комиссия за доставку» → «Комиссия мерча» — все это пока без маркировки. Чтобы правильно внедрить маркировку в процесс, предстояло понять, на чьи плечи и в каких ситуациях — пост-/ или предоплата — ложится обязанность по погашению кода маркировки товара: на продавца или на маркетплейс, и когда правильно отправить данные о маркировке в бэкофис и внешние системы. В итоге архитектуру учета разрабатывали совместно с юристами и бухгалтерами маркетплейса. Мы вместе перелопатили практически всю имеющуюся на тот момент информацию, потратив не один день только на то, чтобы разобраться с логикой процесса и юридическими тонкостями, и только после этого выдали самое оптимальное для бизнеса решение, которое позволило избежать штрафов от регуляторов в будущем.

4. Отлаженные по-новому процессы помогают сократить затраты на часы разработки и сберечь ресурсы команды

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

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

Поэтому мы перестроили процесс работы в команде и ввели не совсем типичный для разработки флоу работы с задачами. Баги и эпики мы вынесли на одну доску в Jira. Вот как это выглядело.

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

Если это баг, то PM валидирует его (не дубль ли, точно ли это баг, а не фича и т.д.). Затем отдает в анализ для сбора фактуры по проблеме: воспроизвести, понять, что сработало не так, есть ли ошибка в приложении, частота и т.п. Аналитик/QA собирает фактуру и отправляет в приоритезацию — баг подтвержден, чтобы решить, насколько срочно это нужно чинить. Здесь важно, что у нас появилась дополнительная проверка на случай ошибки и закрытия бага, так он может снова вернуться на анализ, а не просто потеряться. После того как баг обрастает фактурой, он снова возвращается на PM и дальше уходит либо в бэклог, либо в работу.

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

***

Бэкофис стал для нас большим стартом в разработке кастомных систем с множеством интеграций. На сегодня мы внедрили 250+ сервисов и пришли к выводу: любому продукту в B2B всегда необходимо интегрироваться; неважно, это кастомная сложная интеграция под требовательного клиента или простой виджет, SDK или API, которые помогают клиентам произвести настройку самостоятельно.

Буду рад вашему отклику в комментариях или ЛС: был ли у вас опыт разработки интеграций или вы передавали их на аутсорс, и как у вас обстоят дела с процессами, когда вы работаете с командами на аутсорсе.

PS: Что стало со стартапом

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

Почему продажи в стримах не летят в России? Обсудил c Артемом Прокопенко, экспертом по коллективным механикам в продажах и социальной коммерции, сооснователем нескольких IT-компаний, в том числе Coverse.

«На мой взгляд, все совпало. Трансформация e-com отрасли произошла благодаря маркетплейсам. В пандемию уже никакой, даже самый сильный, e-com не мог конкурировать с маркетплейсами. Кроме того, лайвстриминг не лег на российскую ментальность. Россияне не демонстрируют такую сильную приверженность селебрити, и у нас не развита культура подражания лидерам мнений (KOL) как в Китае. Кроме того, растущее качество экспозиции товаров на маркетплейсах требовало этого и от селлеров на стримселлинговых площадках. Представить товар на себе, как девушки в контейнерах Манилы, переодеваясь тут же во время стрима за занавеской — не сработает для нашей искушенной аудитории. Нужно уметь представлять товар. А чтобы стримселлинг-площадка взлетела — нужен массовый навык. Представитель селлера должен не бояться работать вживую с такой же живой реакцией аудитории. Ну и последняя причина на мой взгляд: целенаправленно смотреть стрим про товары, занимая свое время, готова не такая большая часть российской аудитории. Подобная механика представляется больше развлекательной для российских пользователей и не несет ценности. В Китае — это наблюдение и подражание KOL, в ЮВА — зачастую единственный способ демонстрации товара (с фото на маркетплейсах все совсем плохо).

В России основа при выборе товара в онлайне – количество и качество отзывов, плюс качество экспозиции: фото и видео, инфографика, описание».