Dodo Engineering

Эксперимент, ретро и выводы 💙 Начнём с того, что понравилось: — скорость. Хоть и казалось, что всё на бегу, делать дольше было бы сильно утомительнее; — полное погружение: не отвлекались на другие задачи; — удалось и покреативить-порисовать от души, и связь с реальностью сохранить; — спустились к пользователю с «вижен» облачков; — получили результат. ⚙️ Что учесть на будущее: — составить подробное расписание и равномерно распределить нагрузку до старта, чтобы все участники знали заранее, что и когда их ждёт. У нас не получилось, потому что запускали эксперимент спонтанно; — спринт хорош для проверки одной гипотезы и одного исследования, иначе что-то выпадет из фокуса и будет делаться по остаточному принципу. Так у нас вышло с экстра-продуктами; — нужны активности в первый день для сближения, если в команде есть незнакомые друг с другом люди. Лексуса надо было приводить в первый день 🙂 — все участники должны верить в идею эксперимента — это важно для успешной работы команды; — тест с клиентами лучше проводить в отдельный день и закладывать время на опоздания. Мы проводили вечером в последний день эксперимента — были почти без сил; — заранее подумать о том, кого позвать на тест — в идеале должен быть пул клиентов, состоящий не только из знакомых и из знакомых знакомых, тогда не будет искажений в выборке; — для прототипа лучше использовать другой инструмент и как можно тщательней прорабатывать основной сценарий. 💡 Выводы Мы немножко и упоролись, но получили результат за 3 дня. Нас было шестеро — и это оптимальное количество людей, чтобы подойти к проблеме с разных сторон. Пять человек захотели участвовать ещё в таких экспериментах. Сам формат спринта показался хорошим для офлайна, в онлайне так не выйдёт. Изначальную гипотезу подтвердить не удалось, но мы получили много информации для других гипотез и исследований. И если бы пошли с этой идей сразу в разработку, потеряли бы много времени и денег. Само исследование надо строить по-другому, в два этапа: сначала на текущем варианте, потом, после фидбэка клиентов, делать и показывать новый. #продактвогне

С чего обычно начинается работа команды над задачей? С создания карточки в таск-трекере? С обсуждения в рабочем чате? Или с поиска готового решения, чтобы сэкономить себе кучу времени? У нас всё начинается с прожарки идеи для новой фичи. За экспериментальным спринтом мы наблюдали на прошлой неделе — ребята вчера провели ретро и уже совсем скоро поделятся результатами. А в этой статье наш iOS-разработчик Кирилл Орлов рассказывает, как обычно выглядит полный процесс разработки фичи на примере интеграции чата в приложение. Заглядывайте на Хабр, читайте и задавайте вопросы в комментариях.

Наш Донер 42 ещё совсем маленький, но в его приложении есть свои фишечки. Вот топ-5 «крышесносных» фич от Арсения Васильева, главного по айти в Донер 42: 🔹 Автосборка комбо — когда клиент заказывает Греческий Макси донер, картошечку, айранчик. Заходит в корзину, а приложение предлагает сконвертировать её содержимое в комбо по более низкой цене. Пусть так мы не зарабатываем случайные деньги, которые могли бы получить, зато повышаем лояльность. 🔹 Синхронизация с приложением «Здоровье» на iOS. Нам хотелось сделать что-нибудь приятное для аудитории, которая следит за своим питанием: теперь при создании заказа калории автоматически запишутся в «Здоровь». 7% пользователей уже включили эту синхронизацию. 🔹 Системный поиск по меню в глобальном поиске на iOS. Приложение не живёт само по себе, оно является частью операционной системы и должно естественно в ней выглядеть (кстати, поэтому мы с самого начала поддержали темную тему). Это, скорее, возможность напомнить пользователю о себе, чем удобная фишка, но мы стараемся на полную использовать такие интеграции. 🔹 Сохранение убираемых ингредиентов. Например, клиент не ест лук. Вместо того, чтобы убирать его из ингредиентов постоянно, гораздо проще один раз сохранить ингредиент в списке убираемых — тогда его перестанут добавлять во все продукты и в последующих заказах. 🔹 Донер-встряска. Для супер-юзеров, которые хотят исследовать приложение, разработчики обычно добавляют пасхалки. Чтобы увидеть нашу, надо потрясти телефон на главном экране. Мы сделали Донер-встряску по аналогии с функцией «Мне повезёт» в поисковиках. Клиент не знает, что сегодня съесть на обед? Достаточно потрясти телефон и мы предложим случайный выбор. Никаких рекомендательных алгоритмов, просто старый добрый рандом. А какую самую классную фичу вы встречали в приложениях для заказа еды?

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

Спринт-эксперимент, день третий. Кипели и вовлекались на 100%. ☑️ Обсудили прототип, формат исследования, план на день. Распределили роли и разошлись по группам. ☑️ Сделали таблицу с наборами и ценами для разного количества людей, отдали дизайнеру. ☑️ «Разработчики» просчитали экономику, определились со сценариями. «Исследователи» определили критерии успешности для каждой гипотезы и пошли дизайнить. ☑️ Подготовили сценарий с вопросами, подобрали фото для ситуаций, придумали название фичи и call to action. ☑️ Собрали прототип в Фигме. ☑️ Провели тестовый прогон на ребятах из офиса, немного поменяли скрипт интервью. ☑️ Выгуляли Лексуса. ☑️ Провели исследование и выжили! Силы кончились, но эмоций дофига. В процессе многое из изначально запланированного реализовать не удалось. Пришлось решать, от чего отказаться, чтобы успеть подготовить прототип. Помогли промежуточные «синки» — обсуждали спорные моменты, перестраивались на ходу. В понедельник проведём ретро по спринту и проанализируем результаты.

Эксперимент, день второй ✔️ Начали с презентаций интересных кейсов, вдохновились и заскечтили самые классные. ✔️ Взялись за креатив: каждому нажно было нарисовать за 8 минут 8 эскизов своего решения, а потом ещё скетчи 2-3 экранов за 30 минут. ✔️ После обеда изучали все варианты, отмечали, что больше всего понравилось. Нужно было выбрать одно решение, с которым пойдём дальше. Сделать это, конечно же, не удалось. ✔️ Решили взять всё самое лучшее из каждого варианта и магическим образом объединить в общий сценарий прототипа. Много и эмоционально спорили, но вовремя вспомнили о главной цели — протестировать формат спринта. Это помогло остыть и договориться. Вообще сегодня было сложнее, чем вчера: много сил ушло на креатив и споры. И хоть визуально понятно, каким будет прототип, завтра нужно будет решать важные конкретные вопросы. И понять, как будем проводить дизайн-тест на клиентах.

Любой день хороший, чтобы поговорить культуре и инструментах командного взаимодействия. О том, что команда может прийти к лучшим результатам через настройку процессов, а не увеличивая свои ресурсы. И о том, что культура должна разделяться на всех уровнях компании, потому что её невозможно навязать, только заботливо вырастить. Это вроде бы очевидные вещи, но о них часто забывают. И эту статью Паша Константинов, наш QA-инженер, написал как раз потому, что хотел напомнить об очевидном. В ней он также делится инсайтами, как распространять Agile-культуру в компании, что стоит за сопротивлением команд, как с ним работать и какие вопросы задавать.

Эксперимент, день первый Идея для прожарки: готовое решение для ситуативного заказа, например, для детского праздника или посиделок с друзьями. ☑️ Определили вместе цель для дизайн-спринта, дописали метрики и критерии успешности теста. ☑️ Провели интервью друг с другом, записали вопросы для обсуждения в формате «как мы можем». Например, как мы можем сделать так, чтобы пользователи обращали внимание на новый функционал? ☑️ Сгруппировали похожие вопросы, выбрали самые важные с точки зрения достижения цели. Перерисовали карту с текущего флоу клиента на тот, который будет в новом решении. ☑️ Определились с точкой приложения усилий в этом флоу. Вечером — ресёрч референсов и крутых примеров. Завтра посмотрим, кто что нашёл, и исользуем эти материалы для вдохновения при скетчинге. Впечатления положительные, но кажется, что к полученному результату можно было прийти быстрее. Мы взяли более-менее понятную идею, а фреймворк заточен под более сложную. Но для тестирования формата – нормально. #продактвогне

От постановки проблемы до проверки прототипа за 3 дня. Возможно ли? Приложение Додо Пиццы работает в 15 странах, нам приходится учитывать всё больше особенностей и корнер-кейсов. Сейчас на разработку новой стабильной масштабируемой функциональности уходит от 1 до 3 месяцев, поэтому важно брать в работу те фичи, в успехе которых мы уверены. Несмотря на то, что стали запускать быстрые эксперименты, с момента дизайна до получения результатов всё равно проходит 2-3 недели. Недавно у нас появилась идея, как развивать заказ в приложении, но не хватает уверенности, что эта фича будет востребована. Решили рискнуть и попробовать новый фреймворк из книги «Спринт», который позволяет пройти процесс от постановки проблемы до проверки прототипа на клиентах за 5 дней. Собрали кросс-функциональную команду, адаптировали формат под себя и готовы стартовать сегодня. Каждый день будем делиться, как идёт процесс. Оставайтесь с нами и делайте ставки, получится или нет. #продактвогне

Мы в Dodo создаём глобальные продукты, и всегда приходится думать о приоритетах и масштабировании. При этом все запросы на доработки стекаются в IT-команду, и долгое время перед нами вставали разные вопросы — важности, приоритета, ответственности. И на эти вопросы сложно было давать ответы, часто было непонятно, кто вообще должен их давать. Мы хотели, чтобы таких вопросов у нас не возникало в принципе, и попробовали поменять структуру Dodo Engineering, создали рыночные и глобальные команды и понятный способ взаимодействия через общий код. Что из этого получилось и как работает — рассказывает Саша Андронов в этой статье.

поставишь плюсик, когда сможешь? https://habr.com/ru/company/dododev/blog/666028/

Понимаете, у нас такая традиция... Несколько раз в год мы ходим в гембу. Гемба — это повод посмотреть с другой стороны на то, как используется наш продукт, возможность переключиться, вырваться из рутины и попробовать себя в новой роли. В конце апреля наши айтишники вышли на смену кассирами, курьерами, операторами контакт-центра и техподдержки. Никаких инсайтов сегодня не будет, просто фотокарточки и три забавных случая: — в техподдержке расследовали таинственное добавление грибного стартера в корзину в мобильном приложении без клика клиента; — QA-инженер доставлял заказ давней знакомой, а она его не узнала; — гость очень просил позвать его по имени, когда будет готов заказ. Имя было «Уничтожитель миров 3000».

Скажем честно, мы скучаем по крупным офлайн-конференциям. Поэтому очень рады, что HighLoad++ в мае состоится! И ещё больше рады тому, что там выступит Сергей Бухаров и расскажет, как мы выстроили систему дежурств и автоматизировали инцидент-менеджмент от первого алерта до генерации драфта постмортема. Если идёте на конференцию и интересуетесь темой SRE, заглядывайте 14 мая в 14.10 в зал «Синнакс». Кстати, про SRE в Dodo Engineering у нас есть пара статей на Хабре, вдруг вы пропустили: 🔹История внедрения SRE в Dodo Engineering 🔹Как подружить SRE с разработкой, а на сдачу улучшить качество сервиса

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

Про тестирование Недавно я поделился количеством тестов, в комментариях было много вопросов про них. На интервью в iOS Good Reads тоже много спрашивали. И так случилось, что у меня в черновиках давно пылится статейка про то, как мы их писали последние пару лет. Статья вышла очень большая, поэтому мы разбили ее на две части. В первой расскажу про то, как начали писать, почему тесты — неотъемлемая часть бизнеса, какие фрейморки используем и какие типы тестов пишем. В конце — мой ответ на вопрос насколько тесты полезны. Вторую опубликуем через пару недель. Интересно, что статью я начал писал еще год назад, поэтому когда я с нее сдул пыль пришлось переписать несколько вещей. Например, раньше распил был около 50% и мы лишь ставили себе цель за год довести его до больших значений. Сейчас он 82% и где-то около 90% его разумная граница. Прикольно наблюдать прогресс. https://habr.com/ru/company/dododev/blog/661741/

22 апреля мы считаем днём рождения компании Dodo и днём рождения Dodo IS (ведь мы неразрывно связаны). 11 лет назад наша система была маааленьким модулем для приёма заказов по телефону, теперь же Dodo IS — становится большооой платформой, которая помогает масштабировать наш бизнес! Мы много чего успели за последний год: 🔹IT-команда выросла почти на 50%. Наш средний возраст — 30 лет, а всем вместе нам больше 6 тысяч лет! 🔹Делали из Dodo IS платформу, запустили курьерское приложение с чаевыми, научились определять дефекты пиццы с помощью компьютерного зрения и прогнозировать закупки с ML. Добавили в приложение чат и сторис, перезапустили программу лояльности. 🔹Открыто делились своим опытом с миром: выпустили 2 новых подкаста, 30+ раз выступили на конференциях и митапах, написали 40+ статей, книгу «Про доступность iOS» и попали в топ-5 команд мобильной разработки. Считаем, что год прошёл круто. Впереди много новых вызовов, но мы с ними справимся и сделаем наш продукт ещё лучше. Ну и по традиции — поздравляем Dodo, Dodo IS, Dodo Engineering и всех, без кого всё это было бы невозможным — наших разработчиков, продактов, QA, SRE, c-level, менеджеров, дизайнеров, ppl, деврел, техподдержку (никого не забыли?) с праздником! 🎉

21 апреля вспоминаем день Великого падения Dodo IS Кто-то спросит «Ну, упали, что с того? Что вы носитесь со своим падением и почему оно великое? Неужто больше никогда не падали?». Падали. Например, в прошлом году 1 сентября мы пробили потолок в 400 заказов в минуту, уже хотели открывать шампанское и тут начались проблемы в трекере заказов. 4 часа ушло на починку. Больно, но не смертельно – обошлось без выезда IT-бригад реанимации, как было в 2018. В тот раз почти вся команда на несколько дней поселилась в офисе и чинила-чинила-чинила, а сочувствующие подвозили ребятам еду. Да, мы падаем не так громко, как гиганты. Вспомнить хотя бы глобальный сбой в соцсети-которую-нельзя-называть, когда на устранение проблемы ушло 7 часов. Или как сломался Google и потянул за собой кучу сервисов по всему миру. Падают все. Главное — найти силы подняться, исправить свои ошибки и больше их не повторять. Пока нам это удаётся.