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

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

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

2. Что произойдет с твоим бизнесом, если полгода-год-два мы вообще не будем в этой части системы ничего менять?

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

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

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

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

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

Свежий выпуск про IT-систему Додо

Додо Пицца — компания-киборг, IT-компания, цифровая франшиза. Как только не называют. Все из-за Додо ИС — бесшовной цельной облачной IT-платформы, которая позволяет Додо так быстро расти, поддерживает работу в 800+ точках в 16 странах и остается прорывной даже по мировым меркам.

Разбирались, что стоит за Додо ИС с Сашей Андроновым, СЕО Додо Инжиниринг:
- Можно ли сравнивать наш IT-продукт с Теслой?
- В России все понятно, а что за рубежом? Есть ли нам, что противопоставить конкурентам?
- Главная задача Додо ИС
- Как принимать решения в условиях быстрого роста? Что добавлять в систему, а что нет?
- Почему раньше думали, что внутрянка про Додо ИС (с точки зрения бизнеса) никому не будет интересна, а теперь развиваем глобальный бренд?
- Какое будущее ждет Додо ИС

Смотреть на YouTube
Слушать на Яндекс Подкастах

Расскажу про одну важную вещь, на днях вышедшую в #dodois

В прошлом году мы презентовали стратегию развития Dodo IS и она состоит из трех ключевых вещей:
1. Мы совмещаем глобальные и рыночные команды. Глобальные оперирует приоритетами сквозь все рынки, конкретные рыночные приоритизируют исходя из своего рынка.
2. Мы превращаем Dodo IS в конструктор.
3. Мы расширяем Dodo IS с помощью плагинов (Dodo IS Apps) и открытого API.

Так вот, на днях раскатали на всю сеть кастомизируемый трекинг (если надо отдельно рассказать про внедрение и раскатку в B2B, поставьте 🤔). Это, пожалуй, однин из лучших примеров реализации стратегии конструктора.

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

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

Нужны другие настройки станции конкретно под Донер, чтобы там показывалось больше продуктов на одной странице – пожалуйста. Печатать наклейки до того как продукт попадет на этап упаковки – легко. Кебстеру в донерной нужен свой процесс – снова пожалуйста. Напитки выводить на трекинг после того как все выпекаемые продукты готовы – снова можно.

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

Делать продукты, работающие в нескольких странах сложно. Делать продукты, работающие в десятках стран охренеть как сложно. Делать продукты, готовые масштабироваться на сотни стран – вообще жесть. Особенно если вы работаете с платежами, чеками и едой.

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

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

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

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

А теперь представим что завтра у нас 20 стран. Послезавтра 30. Потом 50. Как все это поддерживать, продолжать масштабироваться и не умереть?

Все оч просто 🙂

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

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

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

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

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

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

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

Напишем попозже в канал Dodo Engineering и на хабр статью с деталями о том как у нас устроены плагины.

Подписывайтесь на канал Саши про продуктовую антихрупкость!

Меня зовут Саша Столяров, я менеджер продуктов в Dodo Brands.

Сейчас в Додо я отвечаю за большой продукт под названием Ordering Platform, который включает в себя почти треть всей DodoIS. Мы закрываем путь клиента от коммуникации до оформления заказа – для этого создаем универсальные инструменты и сервисы для всех стран и концепций, которые ускоряют и защищают от ошибок прохождение этого пути. Мы инвестируем в DodoIS как в IT систему для быстрого масштабирования компании на разные рынки.
Если в простой аналогии, то одна большая ракета под названием “Додо Пицца Россия” успешно улетела в космос и теперь миссия нашего продукта построить космодром для запуска следующих больших ракет 😉

В основу этого канала легла книга Нассима Таллеба “Антихрупкость”. Я остался под большим впечатлением от простых идей Таллеба и его взгляда на мир. А также сам стал замечать сколько хрупкого люди в этом мире создают и как быстро это рушится с приходом черных лебедей (значимых событий-потрясений).

Додо – это антихрупкая компания (можете посмотреть последний съезд Додо и удостовериться в этом). В истоках её антихрупкости стоит Фёдор, та команда лидеров, которую он собрал, и вложенные ценности компании. Но чтобы компания просуществовала целый век, нужно не допускать хрупкости в отдельных моментах, в том числе и в продуктовой разработке.

Поэтому я и начинаю свой поиск ответов на вопрос “Что есть антихрупкость в разных аспектах работы над продуктом”. Здесь я буду делиться своими рассуждениями и примерами, буду честно говорить об ошибках, которые мы допускаем. Тут будет очень мало контента про готовые инструменты – да и кто я такой, чтобы говорить как вам устраивать свою работу над продуктом.
Я хочу подталкивать вас на рассуждения о том что вы делаете, нет ли в этом хрупкости (или херни, по-простому). А результаты своих поисков и опыта буду сводить на одной странице https://www.notion.so/stolyarovalex/3fe7f4c76b0848479c494c83689513e4

Погнали 🤘

#dodois Обновили пик! 🙂

614 заказов в минуту в Додо Пицце в России вчера. Это 10 заказов каждую секунду!

Словами не описать как такой пик ощущается, когда ты на смене в пиццерии.

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

Небольшой жизненный #лайфхак, который пришел случайно 🙂

Закрывайте все вкладки в браузере в конце дня.

Вкладки в браузере – настоящий бич! Открываем их десятками, чтобы “потом прочитать” или 10 вкладок разных микроволновок, чтобы сравнить их, когда выбираем себе покупку. Каждая вкладка в браузере сродни одному незаконченному делу, которое остается висеть не только на экране компьютера или телефона, но и в вашей голове. А Safari придумал еще и группировать их! 🤦

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

Что это дает?
1. Каждый день с чистого листа и свободной от вчерашнего груза головой. Поверьте, оч помогает 🙂
2. Если там остались действительно важные дела, вы на следующий день их снова найдете.Каждый раз когда вы будете заново их находить, это будут усилия, которые вам не хочется прикладывать. Мучайтесь, ага!
3. Научитесь доделывать. Не оставлять на “потом”, а доделывать. Прочитать что-то, заказать уже свою микроволновку (и пусть она будет неидеальной), но доделывать. Все потому что вы будете понимать что если не доделаете, завтра все по новой! Ну уж нет, лучше сегодня доделаю, либо это не так важно и просто выкину из головы!

Easy!

It’s all about scale!

Общались на днях на 1:1 с одним из продактов и наткнулись на одну простую мысль, которой можно описать вообще любое изменение в Dodo IS сейчас. Все что мы делаем сейчас нужно для масштабирования. Я не про технику, нет, точнее, не только про нее. Я про бизнес в целом. Масштабировании во всем – в клиентах, в подходах к качеству, новых странах, развитии брендов, маркетинговых коммуникациях, доставке, в инфраструктуре и аналитике, работе с данными и дизайне. Во всем!

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

🚨 У нас сегодня развалилась к херам Dodo IS!

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

У нас за вечер:
* DDoS на 2.8млн запросов в минуту.
* Пуши, которые свалили мобильное приложение, а затем и сайт.
* Наш плохой релиз, который непонятно как сломал центр системы.
* Сломался мониторинг раза 3-4 за вечер.
* Дикая нагрузка на базу.

Все эти ошибки умножали эффект друг на друга.

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

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

С понедельника будет 2 важных изменения в работе команд Dodo IS.
* Мы останавливаем продуктовые релизы, касающиеся приема заказа до восстановления к уровню SLO. В релиз пойдут только фиксы и технические улучшения системы
* Команды Ordering и CVM Евразии останавливают свою работу и переключаются в обязательном порядке на технические работы по восстановлению уровня сервиса.

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

Адский феил с нашей стороны.

Будем рассказывать о нем и пост-мортем сделаем публичным.

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

Рассказываю что у нас происходит, как мы строим работу после инцидента.

Если кратко объяснить процесс, то все управление Dodo IS сейчас проходит через CTO, Пашу Притчина. Когда мы бежим быстро, когда нам нужен темп и развитие, хорошо работает децентрализация и 100% свобода в принятии решений. Когда тебе надо притормозить, важен консерватизм и снизить вероятность ошибок, работает обратный режим централизации, когда все изменения проходят ревью через одну небольшую команду, дающую возможность релизить.

Фактически мы разделились на 3 группы
• Первое направление – пост-мортем. Над ним сейчас работает небольшая команда. Пост-мортем это не только сам анализ причин, но и ретроспектива на наши действия, восстановление полной картины событий, какие симптомы когда срабатывали, как мы на них реагировали, кого подключали и т.д. Эдакий полный лог произошедшего с выводами и изменениями в процессах.
• Второе направление – исследование конкретных гипотез. Здесь работают команды нагрузки, SRE и разработчики, чтобы проверять конкретные варианты причин. Да, мы пока на 100% не можем однозначно утверждать что стало причиной инцидента (часто триггер инцидента не совпадает с истинной причиной). Среди гипотез в том числе, например, попадание на плохую стойку в датацентре во время скейла. Года 2 назад такое было (подтверждено от MS, ну вот, даже такое бывает).
• Третье и самое большое направление – это фиксы. Здесь работают несколько команд и даже при том что корневая причина конкретного инцидента еще не установлена, у нас гарантированно есть места в системе, которые мы знаем, которые требуют улучшения и влияют на стабильность. Часть симптомов мы уже понимаем и так же снимаем нагрузку. Пример – перевод всех консьюмеров на новый сервис меню, что снизит нагрузку на самый больной компонент системы. Таких задач много, тут работает сразу несколько команд, координация оч простая через техлида.

Ежедневно есть синки общие и синки по конкретным направлениям.

Продуктовые команды сменили фокус и работают над повышением Service Level (SL). Продуктовые релизы мы делаем, но очень ограниченно, с нагрузкой и обязательными дополнительными ревью. К примеру, у нас есть комитмент рекламный, который мы не можем перенести и под него готовим изменения. Все гибко, обсуждаемо и всегда действуем по ситуации.

Когда будут следующие детали, напишем.

Вот так теперь выглядит мой menu bar. Есть оч классное приложение для osx Clocker. Удобно настраивать таймзоны, иметь их всегда перед глазами. Но самое впечатляющее для меня то что это приложение опенсорсное. Код к нему открыт на github. Автору большой респект и донат 🙂

Какую же крутоту запустил Дринкит!

Теперь можно позвать друга/знакомого/коллегу на кофе!
Представьте — сидите в офисе, работу работаете, наконец закончили задачку и хочется сделать перерыв. В приложении Дринкит, из списка контактов выбираете коллегу и отправляете приглашение. Адресат соглашается и вы идете вместе пить Латте трюфель с сырной пенкой. Кайф!

Кофе объединяет!