Тем временем 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 (МСК) в телеграмм-канале кэмпа поговорим о связи внутренних процессов с бизнесом, постараемся её увидеть, понять лучше свой бизнес и своего клиента, а так же научимся видеть связь технических решений и их влиянием на клиентов.

Друзья, посоветуйте пожалуйста React Native разработчика? На проект на 4-6 недель. Оплата в валюте :)

PS. Не в Додо.

Вот это, пожалуй, одно из самый значимых событий в жизни Dodo IS. В маркетплейсе появилось первое стороннее решение. Когда я говорил о том что со временем над Dodo IS, над бизнесами Додо будут трудиться тысячи разработчиков, я не шутил :)

Лучшая инвестиция в себя, которую вы можете сделать – английский язык 🇬🇧. Учите английский, в общем 🙂

Вспомнил как снимали этот ролик для Microsoft Inspire с ребятами из США. Как в 4 утра пытались понять как попасть из Сыктывкара в Москву из-за отмененного рейса и летели сначала в Питер, а потом в Москву оттуда. Интересно что некоторые вещи, о которых говорится в ролике, тогда еще не было их и в помине, мы были к ним не готовы тогда, не было приложения даже, мы падали часто. А сегодня они работают в 900 пиццериях. https://www.youtube.com/watch?v=qnshI4dfP6E

Платформа. Что это такое и чем они отличаются от продукта.

Какие софтверные продукты вы используете в своей компании? GMail для почты и Google Docs для работы с документами, используете Jira или другой таск-трекер, Slack для обмена сообщениями, Zoom или Google Meet для онлайн звонков, Miro для онлайн досок, Notion для внутренней документации, github или gitlab для работы с кодом, figma для дизайна. Много разных продуктов и не всегда их легко интегрировать друг с другом. А было бы круто нарисовать дизайн в Figma и закрепить его сразу в Notion и запинить в рабочий канал команды в слаке.

Есть очень крутая статья от HubSpot на тему того чем отличаются платформы от продуктов. Здесь я приведу основные мысли о разнице продуктов и платформ со своими рассуждениями и примернами на Dodo IS.


Продукт – это набор инструментов от одной компании, который поставляется одним общим пакетом, решает 1-2-3 конкретные задачи. Когда у вас большой бизнес, скорее всего у вас много разных продуктов, как-то интегрированных друг с другом. Иногда интеграция в продукте с другими вообще не предусмотрена и он может работать только “сам в себе”, решая конкретные задачи.

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

Подключение внешних ресурсов

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

Объясню на примере Dodo IS, уже давно реализованный пример с плагинами для касс. Каждый раз когда мы выходим в новую страну, мы интегрируемся с местными чековыми принтерами, кассами, налоговой. Для PoS терминала не важно, в какой он стране, чек он и в Африке чек. Но детали того как этот чек печатается, какая информация на нем отличаются. Мы создали систему плагинов и теперь любая подобная интеграция может делаться независимо от Dodo IS, взаимодействуя с ней через API контракт. Мы можем привлекать любое количество команд на аутсорс чтобы реализовать интеграцию в конкретной стране. Так работает платформа.

Подключение внешних продуктов и гибкость

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

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

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

Что нужно чтобы такая гибкость работала?

Для того чтобы это работало действительно так, важно соблюдать два ключевых фокуса при разработке платформы:
1. API everywhere. Любое взаимодействие между продуктами платформы осуществляется через API.
2. Доступные данные. На данных строится принятие решений, данные, которые генерит один продукт, могут использоваться десятком других продуктов внутри платформы. Даете ли вы такой доступ через дата-платформу или просто выставляете API с данными наружу – ваш выбор.

А теперь еще попробуем площадку на dzen с тем же материалом. Не спрашивайте почему именно dzen, просто предложили там публиковать то что публикую в канале, я и решил попробовать.

https://dzen.ru/a/ZFSXwvHf1gub0kg7?share_to=telegram