Наш Донер 42 ещё совсем маленький, но в его приложении есть свои фишечки. Вот топ-5 «крышесносных» фич от Арсения Васильева, главного по айти в Донер 42:

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

🔹 Синхронизация с приложением «Здоровье» на iOS. Нам хотелось сделать что-нибудь приятное для аудитории, которая следит за своим питанием: теперь при создании заказа калории автоматически запишутся в «Здоровь». 7% пользователей уже включили эту синхронизацию.

🔹 Системный поиск по меню в глобальном поиске на iOS. Приложение не живёт само по себе, оно является частью операционной системы и должно естественно в ней выглядеть (кстати, поэтому мы с самого начала поддержали темную тему). Это, скорее, возможность напомнить пользователю о себе, чем удобная фишка, но мы стараемся на полную использовать такие интеграции.

🔹 Сохранение убираемых ингредиентов. Например, клиент не ест лук. Вместо того, чтобы убирать его из ингредиентов постоянно, гораздо проще один раз сохранить ингредиент в списке убираемых — тогда его перестанут добавлять во все продукты и в последующих заказах.

🔹 Донер-встряска. Для супер-юзеров, которые хотят исследовать приложение, разработчики обычно добавляют пасхалки. Чтобы увидеть нашу, надо потрясти телефон на главном экране. Мы сделали Донер-встряску по аналогии с функцией «Мне повезёт» в поисковиках. Клиент не знает, что сегодня съесть на обед? Достаточно потрясти телефон и мы предложим случайный выбор. Никаких рекомендательных алгоритмов, просто старый добрый рандом.

А какую самую классную фичу вы встречали в приложениях для заказа еды?

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

У нас всё начинается с прожарки идеи для новой фичи. За экспериментальным спринтом мы наблюдали на прошлой неделе — ребята вчера провели ретро и уже совсем скоро поделятся результатами.

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

Эксперимент «От постановки проблемы до проверки прототипа за 3 дня», ретро и выводы

💙 Начнём с того, что понравилось:
— скорость. Хоть и казалось, что всё на бегу, делать дольше было бы сильно утомительнее;
— полное погружение: не отвлекались на другие задачи;
— удалось и покреативить-порисовать от души, и связь с реальностью сохранить;
— спустились к пользователю с «вижен» облачков;
— получили результат.


⚙️ Что учесть на будущее:
— составить подробное расписание и равномерно распределить нагрузку до старта, чтобы все участники знали заранее, что и когда их ждёт. У нас не получилось, потому что запускали эксперимент спонтанно;
— спринт хорош для проверки одной гипотезы и одного исследования, иначе что-то выпадет из фокуса и будет делаться по остаточному принципу. Так у нас вышло с экстра-продуктами;
— нужны активности в первый день для сближения, если в команде есть незнакомые друг с другом люди. Лексуса надо было приводить в первый день 🙂
— все участники должны верить в идею эксперимента — это важно для успешной работы команды;
— тест с клиентами лучше проводить в отдельный день и закладывать время на опоздания. Мы проводили вечером в последний день эксперимента — были почти без сил;
— заранее подумать о том, кого позвать на тест — в идеале должен быть пул клиентов, состоящий не только из знакомых и из знакомых знакомых, тогда не будет искажений в выборке;
— для прототипа лучше использовать другой инструмент и как можно тщательней прорабатывать основной сценарий.

💡 Выводы
Мы немножко и упоролись, но получили результат за 3 дня. Нас было шестеро — и это оптимальное количество людей, чтобы подойти к проблеме с разных сторон. Пять человек захотели участвовать ещё в таких экспериментах. Сам формат спринта показался хорошим для офлайна, в онлайне так не выйдёт.

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

#продактвогне

Команда архитекторов из Тинькофф организовала книжный клуб Code of Architecture — для всех, кто строит программные системы. Сейчас читают книгу Software Architecture: The Hard Parts и позвали наших ребят из «Читаем вместе» поучаствовать в обсуждении.

Четвёртую и пятую главу разберут вместе с Юрой Пастушенко (Юра руководит командой автоматизации системы контроля качества в Dodo):

— обсудят подходы к архитектурной декомпозиции приложения (component-based decomposition и tactical forking);
— детально поговорят про component-based decomposition: расмотрят пошаговый процесс декомпозиции на основе компонентов.

Трансляция будет на ютуб-канале в четверг, 2 июня, в 18:00 (ссылка будет чуть позже), а пока можно посмотреть разбор первых трёх глав книги.

Всё-таки это было легендарно!

Лёша Берёзка, наш iOS-разработчик, рассказал историю того самого «ретро»: как он готовил мир под сценарий самой встречи, как беспокоился о том, чтобы ребятам было всё понятно, а на самом деле всё получилось… Да отлично получилось, на 10 из 10!

Тут вся правда.