Ћобанов-логист
Ћобанов-логист
Ћичный кабинет¬ход–егистраци€
Ќапример: Ћогистика

ћаркетплейс. јрхитектура и организаци€

ћаркетплейс. јрхитектура и организаци€


Ч ј у вас нет такого же, но с перлаЕ с перламутровыми пуговицами? 
Ч   сожалению, нет. 
Ч Ќет? Ѕудем искать. 
»з к/ф ЂЅриллиантова€ рукаї


„то такое маркетплейс?


ѕоначалу его легко перепутать с интернет-магазином. ѕон€тна€ структура сайта, обычный дизайн, и сотни тыс€ч товаров в каталоге. » вот что странно Ч у каждого не одна цена, а сразу дес€ть.


КÐ∞ÑИÑВоÑЗкÐ∞ ÑВовÐ∞ÑИÐ∞




 арточка товара на сайте-маркетплейсе.  оличество цен и кнопок У¬ корзинуФ может поставить в тупик.

¬от такой он, маркетплейс. Ќеприметный на первый взгл€д, но дь€вольски сложный внутри.


ѕринципы маркетплейса:

  • собирает на одной площадке нескольких продавцов (обычно их называют партнерами);

  • с каждой продажи оставл€ет себе процент;

  • дружелюбен к новым партнерам, обычно предлагает несколько простых способов интеграции.

ПокупÐ∞ÑВÐµÐїÐ¸ и инÑВеÑИнеÑВ-мÐ∞гÐ∞ÐЈÐ¸Ð½ÑЛ Ð´Ð¾ и Ð¿Ð¾ÑÐїÐµ пÑИиÑЕодÐ∞ мÐ∞ÑИкеÑВÐ¿ÐїÐµÐ¹ÑÐ¾Ð²



ѕокупатели и интернет-магазины до и после прихода маркетплейсов


»з этих принципов вытекают при€тные Ђпобочные эффектыї: бешеный трафик и высокие позиции в поисковиках. ќказатьс€ в выдаче выше чем производитель Ч норма дл€ маркетплейса.


ѕримеров много. —вой УAmazonФ сделали Wildberries, яндекс (сначала ћаркет, потом ЂЅеру!ї, потом снова ћаркет), goods.ru. ѕримеры поменьше, но верные той же идее: Ozon, Delivery Club, ј—Ќј.


ѕочему иде€ маркетплейсов так попул€рна?


ƒело в том что маркетинг, продажа, доставка и другие услуги не менее важны чем производство и сам товар. ¬ современном мире все это еще и очень дорого. ѕричина попул€рности маркетплейсов чисто экономическа€: производител€м и мелким ритейлерам просто не под силу строить собственные торговые механизмы. 


¬ реальном мире мелкие магазинчики вытесн€ютс€ огромными супермаркетами, в онлайне Ц маркетплейсы медленно, но верно уничтожают интернет-магазины. Ёто общемирова€ тенденци€.


¬ыживут только бутиковые компании Ц у них узка€, но супер-ло€льна€ аудитори€. ¬прочем, в пандемию даже нишевые товары от условно-массового ecco до сумок Karl Lagerfeld доступны в Wildberries.


¬ любом случае у торговой компании в 2021 году всего два пути: или влитьс€ в какой-то маркетплейс, или самой стать маркетплейсом. ¬ыбор пока есть.


Ёта стать€ Ч об архитектуре таких проектов и задачах, которые предстоит решить дл€ его запуска, основанна€ на нашем опыте работы с маркетплейсами ( ≈¬–ј« ћаркетплейс маркетплейс лекарств развитие сайта ј—Ќј ).


ќрганизаци€ данных


ѕартнеры


ћаркетплейс невозможен без партнеров. Ёто отправна€ точка дл€ круговорота ѕартнеры -> “овары -> ѕользователи -> «аказы -> Ќовые ѕартнеры.


ÐШдеÐ∞ÐїÑŒÐ½ÑЛй кÑИуговоÑИоÑВ Ð¼Ð∞ÑИкеÑВÐ¿ÐїÐµÐ¹ÑÐ∞




»деальный круговорот маркетплейса


„тобы партнеров было много, им нужны:

  1. ¬ыгодные услови€ сотрудничества.  омисси€ за заказ должна окупатьс€ оборотом, который вы дадите. ћаркетплейс должен сбалансировать комиссию заказов партнера с долгосрочной выгодой от присутстви€ его товаров на сайте.

  2. ѕон€тна€ отчетность. » маркетплейс, и партнер должны отлично Ч и одинаково Ч понимать, кому что причитаетс€. —тандартный отчет по продажам интернет-магазина дл€ такого не годитс€, нужно разрабатывать собственный. », разумеетс€, партнерам нужен способ самосто€тельно сформировать такой отчет в личном кабинете маркетплейса.

  3. ѕростое подключение. ” маркетплейса должны быть два-три типовых механизма подключени€ (например, интерфейс в личном кабинете дл€ ручной загрузки товаров и поддержка фида YML). » должна быть IT-команда (инхаус или проверенный подр€дчик), чтобы разработать интеграцию с нул€ (если сразу пон€тно, что выгода от подключени€ партнера покрывает затраты на разработку).


ёнит-экономика и монетизаци€


 то будет обрабатывать платежи?


СÑЕемÐ∞ монеÑВÐ¸ÐЈÐ∞ÑЖии 1


—хема монетизации 1


¬ариант 1. ѕлатежи принимает маркетплейс, а потом переводит деньги партнерам за вычетом комиссии и налогов. ¬ыплаты могут быть в установленные даты (как у Ozon Ч 2 раза в мес€ц) или после доставки заказа.

СхемÐ∞ Ð¼Ð¾Ð½ÐµÑ‚Ð¸ÐЈÐ∞ции 2


—хема монетизации 2


¬ариант 2. ѕлатежи принимают партнеры, а потом сами оплачивают комиссию маркетплейсу.

ќбе схемы год€тс€ дл€ полной предоплаты. Ќюансы оплаты при получении обсудим в разделе о доставке.


ѕлюсы первой схемы:

  • полный контроль маркетплейса над платежами;

  • выгоднее в реализации Ч один раз настроить интеграцию с банком дл€ приема оплаты в обход агрегаторов и пользоватьс€ годами.


ѕартнерам же удобнее втора€ схема: деньги поступают сразу же после покупки, а комиссию нужно платить когда-то потом (или платить за размещение/клики заранее). ≈сли с поиском новых партнеров проблемы, стоит попробовать второй вариант взаиморасчетов.


¬озвраты в обоих случа€х Ч процесс непри€тный. ѕри второй схеме он еще и перегружен участниками. ¬ процессе участвует покупатель, маркетплейс (как посредник, которому и предъ€вл€ют претензию в первую очередь), продавец и платежный агрегатор. 


ƒоставка


 ак и в случае с оплатой, есть две противоположных схемы оплаты:

  1. ƒоставкой занимаетс€ маркетплейс (сам или через службу доставки). ≈сли у маркетплейса нет собственного склада, то реализуетс€ классическа€ схема дропшиппинга Ч пр€ма€ поставка покупателю без хранени€ товаров на промежуточных складах.

  2. ƒоставкой занимаетс€ партнер (сам или через службу доставки)

ÐФосÑВÐ∞вкой ÐЈÐ∞нимÐ∞еÑВся мÐ∞ÑИкеÑВÐ¿ÐїÐµÐ¹Ñ



ƒоставкой занимаетс€ маркетплейс


ÐФосÑВÐ∞вкой ÐЈÐ∞нимÐ∞еÑВся пÐ∞ÑИÑВнеÑИ


ƒоставкой занимаетс€ партнер


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


¬ обеих схемах действует правило: тот, кто взаимодействует со службой доставки, тот с ней и рассчитываетс€ (в противном случае речь шла бы о трехстороннем договоре, а это слишком усложнит жизнь как маркетплейсу, так и партнерам).


¬о втором случае на сайте маркетплейса должна быть реализована интеграци€ со всеми возможными службами доставки всех партнеров хот€ бы на уровне калькул€тора цен и сроков. 


 аталог


 аталог состоит из трех частей: дерева каталога, перечн€ свойств и списка товаров.

  1. ƒерево каталога поможет составить SEO-специалист. ¬з€ть готовое дерево вр€д ли получитс€ Ч ассортимент маркетплейса шире, чем у партнеров, да и SEO-шники у каждого свои. ”дачный пример универсального классификатора публикует яндекс.ћаркет (файл категорий  market_categories.xls обновл€етс€ ежедневно): в нем ~3700 категорий, при этом корневых разделов всего 18 (немного дл€ маркетплейса, торгующего всем на свете).

  2. ѕеречень свойств основан на перечн€х партнеров. ќснован, но не равен их Ђлогической суммеї. ƒь€вол кроетс€ в различии названий свойств партнеров и Ђблуждающимиї единицами измерени€. ћожно ли объединить под Ђодной крышейї свойства разных продавцов Ђ¬есї, Ђ¬ес, кгї и Ђћассаї? –ешать должен эксперт, а не софт.

  3. —писок товаров. ” каждого производител€ сво€ номенклатура и свои артикулы. ќтыскать у двух разных партнеров один и тот же товар Ч задача нетривиальна€. ѕотребуетс€ инструмент дл€ сопоставлени€ товаров (и он должен быть рассчитан на дес€тки партнеров).

  • Ѕонус. ѕосле сопоставлени€ товаров и свойств требуетс€ получить корректные значени€ свойств. Ђ0.5 кгї, Ђ0,5ї и Ђ500 грї Ч одно и тоже дл€ человека, но не дл€ софта.



—опоставл€ютс€ не каталоги, а товары. √руппы каталога у маркетплейса должны быть свои


—опоставление свойств и товаров Ч работа, которую нельз€ полностью автоматизировать. Ќо можно ускорить, разработав инструмент в помощь самому незаменимому дл€ маркетплейса сотруднику Ч категорийному менеджеру.


јрхитектура


ќбщее устройство маркетплейса


ј теперь поговорим о технике и тонкост€х реализации. ј если вы хотите обсудить свою задачу с нашим менеджером Ч оставьте за€вку на разработку маркетплейса в форме в конце статьи.





¬ предложенной Ђтиповой архитектуре маркетплейсаї система распределена по трем серверам.

  • ”чет товаров, сопоставление аналогов и управление деревом каталога происходит в учетной системе маркетплейса.

  • “очкой входа дл€ партнеров €вл€етс€ ESB (enterprise service bus Ч сервисна€ шина предпри€ти€). ќ предпосылках использовани€ сервисной шины дл€ т€желых веб-проектов мы уже писали в нашем блоге. ќна отлично подходит дл€ такого вида проектов, разгружа€ учетную систему и сайт.

  • —айт выводит каталог, оформл€ет заказы, взаимодействует с платежными шлюзами и службами доставки (как в схеме с обычным »ћ) и также взаимодействует с ESB.


¬ажно: —ервер ЂFRONTї в любой момент может превратитьс€ в кластер серверов.


¬ отдельных случа€х роль ESB может заменить учетна€ система (но сайт Ч никогда). ќт ESB можно отказатьс€ при см€гчающих услови€х, например:

  • товары не надо стандартизировать (если вы уговорили партнера использовать ваш фид);

  • товары не надо сопоставл€ть (если ваши партнеры не пересекаютс€ (и не пересекутс€) по ассортименту. “акой проект можно назвать light-маркетплейсом, потому что это снимает огромный пласт задач с учетной системы и/или ESB).


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


»нтеграци€ с партнерами


— каждым партнером нужно наладить обмены:

1. –едко:

  • ѕолучать товары партнера
2. „асто:
  • ѕолучать цены товаров партнера
  • ѕолучать остатки товаров партнера
  • ѕередавать заказы партнерам
  • ѕолучать статусы заказов партнера

Ѕольшие маркетплейсы требуют от партнеров файлы фидов или предоставл€ют личный кабинет на сайте (удобно, если у партнера ассортимент небольшой). 

ј вот маркетплейс-новичок не может диктовать услови€ рынку и вынужден поначалу подстраиватьс€ под каждого партнера.


ƒл€ каждого варианта интеграции мы предложили по три способа: 

  1. Ќа коленке Ч разрабатывать почти ничего не нужно, но пользоватьс€ этим не слишком-то удобно. ќтветственным сотрудникам придетс€ вносить или вытаскивать данные вручную, заниматьс€ их пост- или пред-обработкой, исполн€ть длинные инструкции.

  2. «олота€ середина Ч несколько недель разработки и достаточно удобный интерфейс. —амые сложные задачи выполн€ютс€ без участи€ человека.

  3.  ак в лучших домах ≈вропы Ч после нескольких мес€цев разработки все работает само, необходимо только мониторить процессы.

„ем обмениваемс€

ѕериодичность

Ќаправление

Ќа коленке

«олота€ середина

 ак в лучших домах ≈вропы

“овары

–едко

ѕартнер → ћѕ


ѕартнер и ваш контент-менеджер св€зываютс€ по E-mail или телефону и общаютс€ по заказу. ¬аш контент-менеджер дымитс€ и вносит все вручную в вашу учетную систему.

ѕартнер предоставл€ет товарный фид или вносит товары в Ћ  на сайте, или в вашей учетной системе (потребуетс€ настройка прав)

»нтеграци€ с (каждым!) партнером (фиды, FTP, веб-сервисы и т.д. ).


ѕартнеры работают со своей учетной системой, ваши сотрудники Ч в вашей.

÷ены

„асто

ѕартнер → ћѕ

ќстатки

„асто

ѕартнер → ћѕ

«аказы

„асто

ћѕ → ѕартнер

ѕартнер работает на сайте маркетплейса или в вашей учетной системе (потребуетс€ настройка прав)

—татусы заказов

„асто

ѕартнер → ћѕ

—остав заказов

„асто

ѕартнер → ћѕ


—опоставление данных


ќдна из самых больших задач дл€ старта маркетплейса. Ќужно сопоставл€ть тыс€чи свойств и сотни тыс€ч товаров всех партнеров. » делать это придетс€ достаточно часто (при подключении новых партнеров, при обновлении каталогов). 




“овары в маркетплейс дают партнеры. »ногда разные партнеры продают один и тот же товар.


ƒл€ первого партнера алгоритм наполнени€ каталога простой Ч скопировать товар в свою базу. —ложность становитс€ видна лишь со второго партнера. ≈сли второй продает такой же товар, как и первый, нужно эти товары как-то сопоставить. » этот процесс очень трудно полностью автоматизировать. јртикулы производител€ есть не у всех. ј если и есть Ч они могут отличатьс€. —равнивать по названию Ч несколько примеров из этой статьи показывают, какие ошибки при этом можно пропустить. 




¬ыбирать свойства дл€ сопоставлени€, управл€ть правилами преобразовани€ Ч очень кропотлива€ работа


ћожно внедрить сколько угодно инструментов поиска дублей в каталоге, но он либо будет находить совсем очевидные клоны, либо начнет сливать воедино ЂiPhone Xї и ЂiPhone XRї. “ак что от ручной работы тут никак не уйти. 


’от€ некоторые маркетплейсы (в том числе и гиганты) сдались на этой задаче и просто выдают пользовател€м многочисленные копии товаров от разных поставщиков без какого-либо сопоставлени€.






ѕример поисковой выдачи на OZON. Ќайдено 433 экземпл€ра одного и того же светильника.


ЧÑИÐ∞гменÑВ ER-диÐ∞гÑИÐ∞ммÑЛ Ð¼Ð∞ÑИкеÑВÐ¿ÐїÐµÐ¹ÑÐ∞


‘рагмент ER-диаграммы маркетплейса


ƒл€ решени€ этой задачи категорийному менеджеру понадобитс€ удобный инструмент. ExcelТем тут не обойтись, нужен специально изготовленное программное обеспечение. ƒл€ комфортной работы с каталогами категорийному менеджеру понадоб€тс€ следующие экраны.

ПосÑВÐ∞вÑЙики




—писок партнеров с возможностью быстро отключать их от маркетплейса


ТовÐ∞ÑИÑЛ Ð¼Ð∞ÑИкеÑВÐ¿ÐїÐµÐ¹ÑÐ∞




—водный список всех товаров маркетплейса с быстрым обзором всех аналогов в разрезе по партнерам

ТовÐ∞ÑИÑЛ Ð¿Ð∞ÑИÑВнеÑИÐ∞




—писок товаров каждого партнера, с фильтром Ђсопоставлен-не сопоставленї

РедÐ∞кÑВиÑИовÐ∞ние ÑВовÐ∞ÑИÐ∞ мÐ∞ÑИкеÑВÐ¿ÐїÐµÐ¹ÑÐ∞




 арточка товара маркетплейса с возможностью сопоставлени€ с товаром каждого партнера


РедÐ∞кÑВиÑИовÐ∞ние ÑВовÐ∞ÑИÐ∞ мÐ∞ÑИкеÑВÐ¿ÐїÐµÐ¹ÑÐ∞



 арточка товара маркетплейса (цены и остатки)


 ак все это организовать


–азработка и запуск маркетплейса требуют значительной вовлеченности со стороны бизнеса. “ребуетс€ отыскать партнеров и договоритьс€ с ними об услови€х сотрудничества, определитьс€ со схемой монетизации и доставки. » самый серьезный процесс Ч  внутренние преобразовани€ компании.


¬ процесс разработки и эксплуатации маркетплейса также должны быть вовлечены:

  • IT-команда от бизнеса. ќна об€зана быть, если вы созрели до разработки маркетплейса.

  • ѕодр€дчик по WEB и по учетной системе

  • ѕартнеры. —овсем без их участи€ сделать ничего не получитс€, нужно сразу закладывать в стоимость проекта совместное проектирование, разработку и тестирование обменов.


–аспределение остальных об€занностей по рол€м приведено в таблице ниже.

Ѕизнес

IT-команда от бизнеса

ѕодр€дчик WEB

ѕодр€дчик ”—

ѕартнеры

Ќайти партнеров

ѕолучить от партнеров прайс-листы

–азработать сайт маркетплейса

(дизайн, код, инфраструктура)

–азработать учетную систему дл€ сотрудников

(Ќеоб€зательно, но желательно) ƒоработать свои IT-системы дл€ обмена с маркетплейсом

¬ыбрать схему монетизации

—оставить собственный каталог (разделы, свойства)

Ќастроить правила преобразовани€ товаров и значений свойств товаров в собственный каталог

¬ыбрать схему доставки

(Ќе дл€ light-маркетплейса) —опоставить товары


(ƒл€ light-маркетплейса) —копировать товары

ѕреобразовать бизнес-процессы компании дл€ запуска маркетплейса


(Ќе дл€ light-маркетплейса) –азработать инструмент сопоставлени€ товаров



–азработать обмен: —айт-”—





–азработать обмен ”—-ѕартнер


јктуальность данных


ƒанные в маркетплейсе никогда не будут актуальны. Ќужно это понимать. «адержка в передаче данных между складом партнера, учетна€ система партнера, ESB маркетплейса, учетна€ система маркетплейса и сайтом может быть значительной.


Ќо и трагедии в этом нет, если к этому подготовитьс€. Ќапример, в момент добавлени€ в корзину (или открыти€ карточки товара) маркетплейс сам проверит у партнера актуальный срок поставки, наличие и цену. » честно предупредит пользовател€: Ђмы уточнили у партнера, вместо 100 рублей и доставки завтра это будет 200 и послезавтраї. 


√еозависимость


ћногое зависит от бизнеса и договоренностей с партнерами. ’орошо, если они соглас€тс€ дать единую цену и остаток на все ваши поддерживаемые населенные пункты. ј если нет, то нужно будет ув€зывать партнеров с городами и регионами. ¬ариативность можно заложить в архитектуру проекта, а можно Ђклонироватьї партнера дл€ каждого региона вместе с его товарами.


ћобильное приложение


ѕри удачной архитектуре (такой, как наша) новые участники экосистемы маркетплейса встро€тс€ без проблем. 


Ќапример, дл€ мобильного приложени€ есть целых 2 точки возможного подключени€:

  1. Ўина ESB

  2. REST API сайта


ќба варианта хороши. Ќо второй мы считаем более правильным. “ак в мобильном приложении можно будет повторно использовать хот€ бы часть логики, заложенной на сайте.

Ќа первом этапе работы маркетплейса ему может быть достаточно и mobile-версии сайта, без нативных приложений дл€ всех мобильных платформ. —тоит задуматьс€ о прогрессивном веб-приложении (progressive web app, PWA): эта технологи€ набирает хорошие обороты и все меньше сайтов чураютс€ этого решени€.


¬нутренние интеграции


Ќа первый взгл€д об интеграции учетной системы и сайта волноватьс€ не нужно Ч готовые инструменты есть, бери да пользуйс€. ≈сли бы.


“иповые решени€ (например, интеграци€ сайта на 1—-Ѕитрикс и 1—) хорошо справл€ютс€ с передачей товаров и заказов до какого-то объема. Ќо если в вашем маркетплейсе больше 300 000 товаров, то вам придетс€ ждать несколько дней(!) прежде чем последний товар загрузитс€ на сайт. ¬се это врем€ сервер с сайтом будет дымитьс€, так как он и записи из ESB обрабатывает, и на запросы клиентов отвечает. ”скор€ть типовой однопоточный обмен докупкой ресурсов сервера до бесконечности не получитс€. ѕоэтому, если вы сразу знаете, что объем данных будет колоссальный, нужно быть готовым рано или поздно (лучше рано) решать даже такую типовую задачу, как обмен товарами/ценами/заказами между учетной системой и сайтом (так произошло в нашем проекте ≈¬–ј« ћаркетплейс ).


»нтеграци€ ƒостоинства Ќедостатки
“ипова€ (например, Ѕ”—-1—) –аботает сразу ќграничена скорость обмена 
—лабо поддаетс€ доработке
ќбмен файлами по FTP ѕроста€ реализаци€ ќтсутствует обратна€ св€зь между приемником и источником данных
Ќепосредственна€ работа учетной системы с Ѕƒ сайта јрхитектура маркетплейса не усложн€етс€, нет новых узлов 
ћаксимально возможна€ скорость обмена
—пециалистам по доработке учетной системы нужно очень хорошо представл€ть устройство Ѕƒ сайта 
Ћегко испортить данные на сайте
¬еб-сервисы, например REST API  омпромисс по скорости и надежности “ребуетс€ больша€ доработка с обеих сторон (учетна€ система и сайт)
ѕромежуточна€ Ѕƒ ћаксимально возможна€ скорость обмена “ребуетс€ больша€ доработка с обеих сторон (учетна€ система и сайт) 
”сложн€етс€ архитектура проекта


  любому из вариантов, кроме первого, можно добавить многопоточность и/или сервер очередей дл€ надежности. Ёто увеличит нагрузку на сервера еще больше, но только так можно получить максимальную скорость обмена данными. ¬арианты интеграции можно комбинировать: например, передавать файлы товаров через FTP, а в промежуточную Ѕƒ записывать пути к файлам.


ѕлан действий


Ётап 1: Ѕизнес-MVP


Ѕизнес должен Ђдозретьї до маркетплейса и отыскать партнеров дл€ запуска. Ќа этом этапе »Ќ“≈–¬ќЋ√ј может выступить в качестве консультанта, рассказать Укак надоФ и Укак прин€тоФ в мире маркетплейсов.


Ётап 2: ¬ыбор подр€дчиков, создание единой команды


ѕодр€дчики должны подходить вам не только по ценнику, но и по духу. ќпытному руководителю проекта достаточно провести 2-3 предметных разговора с потенциальным подр€дчиком, чтобы пон€ть его квалификацию и возможность сработатьс€.


—ильна€ команда всегда едина€. ѕоэтому подр€дчики должны Ђжитьї в одном информационном поле. ќбщие обсуждени€ задач, проектирование, ретроспективы. ќдно ведь дело делают.


Ётап 3: “ехнический концепт


 команда собралась, настало врем€ утвердить архитектуру и принципы проекта. Ќе писать год “« до мелочей, а установить критерии успеха проекта и задать главные принципы.

Ётот этап не должен длитьс€ дольше 2-3 недель. ƒальше эту сжатую пружину надо отпустить.


Ётап 4: MVP и запуск

—обственно, разработка. ¬ременные рамки нужно задать жестко. ”чтите, что 2 мес€ца Ч маловато дл€ такого проекта, а 4 уже будет многовато дл€ MVP.


Ётап 5: Ёксплуатаци€ и рост

ѕосле 3 мес€цев напр€женной разработки нужно отдохнуть еще 3 мес€ца менее напр€женной разработки. Ќо если предыдущий этап был нацелен на качество, тут во главу угла должно встать количество.  оличество партнеров, товаров, пользователей. 

Ќовых функций в проект добавл€ть не рекомендуетс€ Ч продвигаемс€ в поисковиках и соцсет€х, тестируем MVP на реальных пользовател€х, собираем обратную св€зь, набиваем шишки в св€зке с партнерами, экспедиторами и платежными шлюзами.


Ётап 6: ќптимизаци€

—пуст€ полгода после запуска проекта в нем накопитс€ объемный технический долг.   этому времени и картина мира с точки зрени€ бизнеса может изменитьс€, возникнут новые требовани€ к системе. ј значит, настала пора прекратить рост и зан€тьс€ оптимизацией системы. 


ƒалее

ѕовтор€ть этапы 3-6

ѕоработаем?

–азработка маркетплейса Ч т€желовесна€ задача. Ќа маркетплейс с претензией на отказоустойчивость потребуетс€ не менее 1500 часов веб-разработчиков и столько же на разработку учетной системы.

»Ќ“≈–¬ќЋ√ј может Ђвыдатьї такое количество часов в разумный срок и вз€ть на себ€ обе роли Ч и сайт и учетную систему на базе 1—. –ечь идет, конечно же, сразу о команде из разработчиков, аналитика, верстальщика и дизайнера. ќставьте за€вку, и мы обсудим вашу задачу.



https://www.intervolga.ru/blog/projects/marketpleys-arkhitektura-i-organizatsiya/?bx_sender_conversi...

дата:†16.12.2020 18:09:07††† просмотров:†95

рейтинг:
(Ќет голосов)



ѕрикрепленные файлы

–екламный блок

ERP —»—“≈ћџ Ц ѕ≈–≈ƒќ¬џ≈ “≈’ЌќЋќ√»» »Ћ» «ј ќѕјЌЌџ≈ ƒ≈Ќ№√»? tms Ѕиблиотека логиста со стать€ми и книгами по теории ¬ычитание скоростей Ќикто не знает  ак мотивировать персонал в услови€х кризиса Ћичный бренд как инструмент карьеры ћосковских водителей застав€т снизить скорость оптимизаци€ склада ѕартнЄры компании Ћобанов-логист склад