Про Dodo IS API и маркетплейс

Dodo IS сейчас это такой большой громоздкий конструктор, одна из важнейших характеристик которого – простота адаптации под конкретную страну и возможности к расширению.

Мы всегда придерживались подхода что мы все делаем сами. Да, мы покупаем в пользование лицензии на сторонние сервисы, интегрируем их в Dodo IS, но базовый подход остается в том что мы всю разработку (в том числе интеграционную) делаем сами.

В 2021 году мы сделали первый важный шаг к расширению и смене такого подхода: мы открылись для аутсорса. Мы по-прежнему сами делаем core-вещи в системе, но задачи локализации, задачи интеграции с локальными сервисами или устройствами при выходе в новую страну мы научились отдавать. Для этого разработали специальную систему плагинов (уже скоро будет статья на хабре про это).

И вот теперь мы делаем еще один важный шаг. Мы готовим к запуску полноценный маркетплейс. В прошлом году начали работу над полноценным API для Dodo IS (нет, пока без приема заказа, не торопитесь), покрыли несколько продуктовых доменов и зарегистрировали 39(!) приложений, расширяющих возможности работы Dodo IS. Пока это прототипы, часть еще в разработке, часть API не доделано, но даже при таком несовершенстве наши партнеры-франчайзи и внешние разработчики уже создают решения для себя.

И вот тут нам не хватает главного компонента – самого маркетплейса как инструмента масштабирования этих расширений. Этим и займемся в 2023 году.

Зачем нужен маркетплейс?
Ключевая идея заключается в том что мы будем “не одни”. У нас огромная сеть партнеров-франчайзи, с нами хотят интегрироваться вендоры и продавать свои решения. Мы уже открыли возможность создавать расширения для Dodo IS, а теперь еще и дожмем историю с маштабированием этих решений.

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

Цель Dodo IS – стать огромным интеграционным хабом. Хабом не в техническом понимании этого слова, а в бизнесовом. Маркетплейс – один из ключевых шагов в этом направлении. И рулить им будет теперь уже наш ex-CPO Дима Павлов.

Друзья, если вы хотите больше узнавать о маркетплейсе для Dodo IS, развитии API, подписывайтесь на Димин канал. Если хотите пообщаться на тему разработки для Dodo IS, хакатонов, если у вас есть SaaS решение, которое может быть полезно нашему бизнесу и вы непрочь интегрироваться, пишите в ЛС мне или Диме 🙂

Не знаю как вы, а я поставил себе сегодня Edge

It is all about scale. Не устану повторять эту фразу, потому что она определяет нашу стратегию и наши действия в Dodo IS.

Одно из важнейших решений и изменений в Dodo IS за последние пару лет – это введение плагинов для локализации. Плагины дают возможность быстрой изолированной локализации, а так же сильно упрощают поддержку и изменения для конкретной страны. Сейчас мы работаем в 17 странах и поддержка изменений в законодательствах стран это то еще приключение.

Как вы поняли уже, я про кассы, чеки, налоговую и вот это все.

Впервые плагины появились в кассах, в наших POS терминалах. О том как работает система плагинов, как ее разрабатывали, читайте в статье на Хабр.

Команда POS во главе с Димой Карповым написали большую статью о том как разрабатывали плагинную систему для касс, с какими проблемами столкнулись и как их решали. У себя в канале Дима пишет про QSR, POS и разработку продуктов, уже несколько раз он рассказывал кейсы, где мы используем плагинную систему для касс. Например, про Армению и новые страны, Дринкит Дубай

Мы сейчас ищем двух .NET разработчиков на аутстафф уровня middle и выше в команду CVM, которая занимается персонализацией и коммуникациями с клиентом. Но пост не об этом.

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

Шаблоны и список технологий
Все компании, которые предлагают аутстафф разработку, делают свои стандартные шаблонные резюме. По сути, когда ты получаешь пачку резюме, штук 5-10, они все выглядят одинаково. На 2-3 резюме это превращается уже в игру “найди 10 отличий”.

Ощущение что резюме составляют не разработчики, а HR или сейлзы аутстаферов. Вот возьмем например перечисление технологий. Напомню, мидлы нужны. В списке технологий перечислен абсолютно весь зоопарк, который когда либо трогал разработчик. Туда даже HTML вписывают, я не шучу! Мидл разработчик, в .NET, который будет работать с API приложения. Он знает HTML. Окей. А сам он видел это резюме?

Обычно список технологий еще делят на группы, языки, платформы, базы данных, IDE и…другое. В “другое” лучше вообще не заглядывать, там может быть что угодно вперемешку, winforms, а за ними сразу docker и aws, ну да ладно.

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

Но что же я часто вижу вместо этого?

• Автоматизация бизнес-процессов бэкофиса компании
• Разработка API для платежного приложения
• Вклад в in-house решение компании по управлению бизнес-процессами
• Вклад в инфраструктурные библиотеки компании
• Проведение code review
• Формализация требований заказчика
• Проектирование/создание таблиц/процедур/функций на стороне базы данных
• Оценка сроков выполнения работы

Это реальный пример и единственная ценность, которая тут есть – человек делал API платежек. Платежки – значит там повышенные требования к доступности, к мониторингу, к нагрузке. Я надеюсь, по крайней мере.

Друзья сейлзы, HRы аутстафф агенств, поймите, пожалуйста, общее формальное описание того что делает разработчик не нужна, она только мешает, она превращает информацию о кандидате из 1страничника, который реально можно сделать, в 5 страниц текста (а иногда и больше). И таких резюме может быть десяток, не рассчитывайте что получится вообще найти отличия в них.

И на сладкое, мое любимое.
Я напомню, мы ищем middle разработчиков на аутстафф. Вверху резюме написаны профессиональные навыки, которые хочет отметить аутстафер.

И один из них, внимание: Написание кода, Code review и контроль качества кода.

Вот объясните мне, зачем это писать в саммари резюме аутстафера, который потенциально присоединится к команде в роли middle разработчика?

И снова это не шутка, это реальный пример резюме от компании, которая предлагает свои услуги на аутстафф. Я как-то с горем пополам могу еще понять когда речь об аутсорсе и вы продаете услуги компаниям, которые вообще не имеют своего IT и не понимают чего там как работает и вам надо объяснить в стиле: “вот прожект менеджер, он отвечает за ваш проект, вот программист Иван, он умеет писать код, вот программист Семен, он тоже умеет писать код, вот тестировщик Женя, он умеет писать тесты и проверять работоспособность продукта”.

Но мы же с вами не про то…

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

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

Раньше эта задачка требовала навыков разработки.
Потом она стала требовать навыков работы с Google Docs, картами, в общем, минимальным сэтом инструментов от Google.
Теперь же можно просто спросить ChatGPT.

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

Результаты опроса про преемников.

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

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

Ключевой вопрос вообще в подготовке преемника – когда менять? Когда наступает такой период развития вашей команды или компании, когда качества и сильные стороны вашего преемника становятся нужнее, чем ваши? Когда наступает момент, когда человек “готов”?

Буду постепенно тему развивать и рассказывать как это происходило и происходит у меня 🙂

Live demo GPT-4. Через 2.5 часа!

Тем временем Amazon закрыл 8 оффлайн магазинов Amazon Go. Не стоит удивляться таком, оффлайн имеет свои законы и свои правила игры.

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

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

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

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

Не могу не поделиться. Мне прям оч нравится то какой становится Dodo IS. Публикую с разрешения автора.

Такие разные скорости. Кейс разработки бота с уведомлениями.

Сколько времени занимает разработка фичи в Додо ИС? Например, уведомить партнёра о стопах? 100% это не одна неделя разработки. Мы делаем фичи глобально, качественно, раскатываем сразу на сотни заведений и все страны. У нас одинаково тяжёлые требования к разработке ключевого функционала (например, отображение актуального меню на кассе) и опционального (например, экспорт отчёта в экселевский файл).

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

Стоимость бота 20 000 рублей, затраченное время — 25 часов. Бот был сделан ещё на парсинге. Разработчик с нуля погружался в особенности Додо ИС и искал откуда выковыривать данные, как подрезать куки и так далее. С API всё было бы куда проще и быстрее. Периферия должна быть быстрой и стоить дёшево.

@dodo_is_marketplace

Рекрутер оценивает резюме кандидата 5-10 секунд. Но и кандидаты делают так же с вакансиями.

Пример очень хорошей вакансии для .NET разработчика. В команду, которая занимается кассами в Додо.

Первичная информация в самых первых строчках – базово о чем речь вообще и про деньги.

Затем детали продукта. Не сухим языком, а просто и понятно, даже с картинкой. Потенциальный кандидат сразу может понять с чем будет иметь дело. Хочешь еще подробнее – добро пожаловать под кат. Нет хочешь, окей, читай дальше общие детали.

Ожидания must have и nice to have. К этому моменту уже точно можно понять хочешь ты вообще откликнуться или нет. Так же как у рекрутеров уходит 5-10 секунд (ну или сколько) чтобы окинуть глазами резюме и решить, хочется дальше изучать или нет, так же кандидат за 5-10 секунд может верхнеуровнево оценить вакансию.

Попробуйте эту вакансию оценить так, за 5-10 секунд. Что скажете?

Где и когда кончается всратость? И что такое MLP?
Приведу лайтовый кейс. Делаем визуальную карту нового направления ERP. Направление огромное, и нам самим не до конца ясно, какие сервисы и продукты будут в него входить, какие нет. Не говоря уже о том, что франчайзи просто пучат глаза и спрашивают, а что такое ERP? Можно на бумажке посмотреть? Хороший визуал в этом поможет.

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

И тут мы сталкиваемся с вечной дилеммой. С одной стороны мы хотим, чтобы все в ERP "было как у эппл", ничего всратого, а только интуитивно понятное и удобное, и прям шик вау лакшери.
С другой, блин, ребята, хз че там в этой карте, надо сделать mvp на коленке и показать франчайзи и потом уже дорабатывать.
Но с третьей стороны если мы сделаем это супер всрато и быстро, то франчайзи опять ничего не поймут из-за того, что mvp выглядит всрато.

Есть такая концепция - называется MLP. MInimum Lovable Product.
MLP - это то, где кончается всратость!
Это еще не полноценный продукт, там только часть функционала, но выглядит это приятно! И пользователь такой - о неплохо, мне нравится, а вот тут еще можно вот это доработать.
Очень хорошая концепция, если ее использовать к месту. И при условии, что вы точно знаете, что должно быть в продукте.

Мы, по крайней мере, попробуем 😎

Хочу вам рассказать кейс про то как Linkedin помогает решат проблемы и как можно не бояться писать незнакомым людям.

🔒 Контекст: после санкций у нас отрубился Google Pay не только в РФ, но и вообще во всех странах. Это выглядело тупо и надо было найти способ вернуть Google Pay.

🔨 Что делали: были гипотезы о том что гугл блочил по ID приложения, по стране или еще фиг пойми как. Рассматривали опции разделить приложения, но мы таким образом оч испортим опыт текущим клиентам. Контачили саппорт, пытались добиться от них объяснения, фиксов, получая стандартные ответы в стиле “ваш запрос очень важен для нас, вернемся через год”.

🔑 Хак: мы пошли в Linkedin. Фильтровали людей просто по Google Pay и писали короткое сообщение: “Привет, я из Додо, у нас есть приложения и у нас не работает Google Pay, нужна помощь, можно ли подробнее в почте?”. Из таких 20 или около того контактов один ответил мол да, пожалуйста. Мы описали весь контекст в почте уже детально. Контакт был неподходящий, но это был НЕ саппорт, это был один из менеджеров Google. Это был просто рандомный контакт, мы не знакомы с человеком, не общались никогда раньше. И он нас уже сориентировал на правильных людей внутри гугла. Он когда писал письмо уже конкретным нужным нам людям, даже отметил что “кажется, меня просто нашли по фразе Google Pay в Linkedin, вот мол ребята, пообщайтесь, помогите им”. С ними-то мы и работали уже напрямую и вот вчера ребята сделали оплату в Дринките через Google Pay. Скоро поедет в релиз!

🤔 Мораль: если вы работаете с внешними компаниями, если у вас в процессе есть обсуждения контрактов, условий, все движется медленно, ИСПОЛЬЗУЙТЕ Linkedin. Ищите людей кто работает в нужной вам компании, делайте короткое интро и общайтесь. Ваш network – это оч мощный инструмент!

Любой аспект работы, будь то техническая задача, крупный рефакторинг, апгрейд базы данных с одной версии на другую, замена технологий или даже вечный HR-вопрос «джуна или синьора», — всё это имеет прямую связь с бизнесом и клиентами. И когда мы говорим о работе СТО, то должны четко понимать, что на первом месте этой должности — Chief. А это значит, что СТО должен знать свой бизнес: как он работает, кто твой клиент, как твой бизнес зарабатывает и тратит.

Решили обсудить этот тезис в прямом эфире с организаторами и ламповым коммьюнити кэмпа для настоящих и будущих СТО — South Hub.

18 апреля в 19:00 (МСК) в телеграмм-канале кэмпа поговорим о связи внутренних процессов с бизнесом, постараемся её увидеть, понять лучше свой бизнес и своего клиента, а так же научимся видеть связь технических решений и их влиянием на клиентов.