Комментарии 23
Красиво
Кайф и огонь!
Постоянно смотрим в код, включаем в оценку время тесты.
На аналитику время заложили.
И на тестирование тоже.
И на возможные баги с прода.
И ещё всякого по мелочи.
а время на исправление багов по результатам тестирования?
Любой баг, по сути, нежданчик. Мы не можем его спланировать заранее.
А для нежданчиков у нас есть лаг — 50% от запланированного времени на задачи. Например, если мы оценили задачи в 20 часов, то лаг будет 10 часов.
Последнее время замечаем, что 50% нам стало многовато. Попробуем понизить или ещё что сделать. Но пока так.
А для нежданчиков у нас есть лаг — 50% от запланированного времени на задачи. Например, если мы оценили задачи в 20 часов, то лаг будет 10 часов.
Последнее время замечаем, что 50% нам стало многовато. Попробуем понизить или ещё что сделать. Но пока так.
Шикарная статья, спасибо.
Отличный материал на котором можно учить других и о том как оно может пойти и о том как самоорганизующаяся команда должна с этим справляться.
Хорошая у вас команда. :-)
Отличный материал на котором можно учить других и о том как оно может пойти и о том как самоорганизующаяся команда должна с этим справляться.
Хорошая у вас команда. :-)
Прочитав заголовок и открыв статью долго ждал, где же будет
и зачем там использовать
PS: Как прогресс с микросервисами? Есть ли ETA полного отказа от монолита?
git checkoutи зачем там использовать
◊PS: Как прогресс с микросервисами? Есть ли ETA полного отказа от монолита?
Я чувствую что-то неправильное в том что полтора экранчика делаются почти через героическое преодолевание трудностей. Почему так долго-то? А сколько в результате десятков тысяч строк кода написано?
То что список из 200 пунктов вызывает проблемы с производительностью — тоже непонятно. Из 200 тысяч пунктов я бы понял, но 200?
*почти год. Куда-то буквы из сообщения отвалились
Кровавый энтерпрайз жи ну:) 12 макетов за 8 месяцев — это реально быстро. Без сарказма.
На самом деле в новом чекауте 10 экранов:
1. Сама шторка, главный экран чекаута;
2. Список адресов;
3. Добавление нового адреса (не считаем его, мы переиспользовали старый экран);
4. Список пиццерий;
5. Карта пиццерий (тоже переиспользовали старый экран);
6. Выбор отложенного времени;
7. Способы платежа;
8. Добавление новой карты (тоже переиспользовали);
9. Указание имейла;
10. Указание имени.
Сколько десятков тысяч строк кода — не замеряли.
Про список из 200 пунктов — проблемы на этапе парсинга: там не просто маппинг, мы там с расписанием пиццерий работаем. Для каждой пиццерии надо собрать из стринги дату несколько раз: по 2 даты на каждый день, по 7 дней в неделю, да и расписаний у пиццерий аж два. Итого 28 конвертаций только на одну пиццерию.
Недавно пооптимизировали конвертацию, стало в 3+ раза быстрее. Но всё ещё есть что делать.
1. Сама шторка, главный экран чекаута;
2. Список адресов;
3. Добавление нового адреса (не считаем его, мы переиспользовали старый экран);
4. Список пиццерий;
5. Карта пиццерий (тоже переиспользовали старый экран);
6. Выбор отложенного времени;
7. Способы платежа;
8. Добавление новой карты (тоже переиспользовали);
9. Указание имейла;
10. Указание имени.
Сколько десятков тысяч строк кода — не замеряли.
Про список из 200 пунктов — проблемы на этапе парсинга: там не просто маппинг, мы там с расписанием пиццерий работаем. Для каждой пиццерии надо собрать из стринги дату несколько раз: по 2 даты на каждый день, по 7 дней в неделю, да и расписаний у пиццерий аж два. Итого 28 конвертаций только на одну пиццерию.
Недавно пооптимизировали конвертацию, стало в 3+ раза быстрее. Но всё ещё есть что делать.
Сама история с долгим выпуском чекаута исключительная, обычно большая фича полный цикл проходит за 3-4 месяца, поэтому и рефлексиреум особо сильно.
Про парсинг: «долго» это пол секунды в фоне. Недавно профилировали, оказалось, что промахнулись в моменте создания дейт форматтера, классика. И для всего списка он создавался не 1 раз, а 200*28 = 5600 раз. После фикса парситься стало в 5 раз быстрее, а 0.1 сек для всего списка в фоне уже вполне ок и дальше нет смысла упарываться. Хотя можно еще поменять на ленивое форматирование только видимой области, тогда станет совсем моментально.
Благодарю за шаринг опыта ) Звучит титанически всё, сколько человек в команде iOS работало над фичей ?
Выбьюсь из общего хора хвалебных отзывов. Извините, но это какой-то мрак — читать подобное в блоге компании, про которую из каждого утюга поют: «история успеха», «и ботаники делают бизнес», «пример успеха новой цифровой экономики» и т.д. и т.п.
Ну и дальше больше:
Часть людей и правда отпадает при переходе с экрана адресов на экран способов оплаты. Причины могут быть разные: начиная от технических и UX-проблем, заканчивая человеческим фактором — клиент и правда мог передумать заказывать, могли поменяться планы.Как бывший пользователь вашего сервиса, скажу: на выбор самой пиццы уходит не меньше 10 минут обычно, а на клик по кнопке «оформить заказ» около 5 секунд (с чтением страницы) — вероятность того, что я внезапно передумаю именно в этот момент равна 0,001%, в оставшихся 99,999% случаев причина ухода — это «ой, а мы не доставляем на этот адрес» и «ой, а в этой пиццерии этого больше нет, выберите что-нибудь другое».
Мы не запоминаем обслуживающую клиента пиццерию между заказами, а каждый раз определяем её в момент выбора адреса для доставки. В старом флоу это было уже после сбора корзины. До этого момента клиент видел общее меню всей франшизы, без какой-либо конкретики. В итоге клиент мог собрать заказ, выбрать адрес и узнать, что в нему не приедет наша фирменная пиццаЭто и есть главная проблема пользователя, которую и надо было решать с самого начала, так же как это сделано в других доставках еды. А вместо этого
Мы оценили разработку нового чекаута в 2 месяца, а закончили через 9. <...> В целом не было ничего нерешаемого, но в любом случае это требовало дополнительного времени. Самый яркий пример — кастомный транзишн выезжающей снизу шторки.т.е. команда 9 месяцев боролась со шторками и дизайном, вместо решения настоящей проблемы. Я так и не понял из статьи, а могу я теперь выбрать пиццерию до выбора пиццы, или флоу так и остался прежним?
Ну и дальше больше:
начинать с простого дизайна и усложнять итеративно.О божечки, это же Scrum.
попробовать затащить прототипы.
Не допускать релиза крупных фичей разом, делать всё итеративно.
не допускать новичков и менторов к разработке фич с горячими дедлайнами.Правда, без обид, ничего личного, но это серьезно? Это первый проект?
детальнее описывать требования к задачам.
копить причины принятых решений.
оценивать таски глядя в код.
не отказываться от тестов, даже если сроки горят.
Активнее шарить знания на встречах или во внутренней документации.
На этот раз точно, железобетонно и финально: конверсия выросла на 1,5%Это на уровне цифрового шума.
Я так и не понял из статьи, а могу я теперь выбрать пиццерию до выбора пиццы, или флоу так и остался прежним?
Можете.
Полностью согласен с вами. В кровавом энтерпрайзе очень много бесполезных людей — аналитиков непонятно, чем занимающихся, эффективных менеджеров Олегов и прочих людей просто так тратящих деньги компании, потому что «все так делают». Зато программисты только и умеют, что использовать фрэймворки, написанные индусами, втаскивают в проекты тысячи зависимостей, а сами понятия не имеют, как работают элементарные вещи, вроде Thread, synchronized, volatile и т.д. Да и чего хотеть от них? Ведь даже в вакансиях указывают в первую очередь знание фрэймворков, научиться работать с которыми много мозгов не надо, а вот на базовые вещи всем плевать.
Согласен, предельно грустное чтиво
Прекрасная статья! Спасибо за ценный опыт. Подписался!
Потрясающая статья, спасибо!
К тому же, приятно удивился, увидев Комсомольск-на-Амуре на скриншоте формы заказа.
Привет, AllDmeat. Спасибо за статью. Разработку фичи, которая в итоге дала +1,5% к конверсии прервали ради конкурирующие фичи. Прошло время. Можно ли сейчас сказать, что прерывание было оправданным?
Задал вопрос Боре Герну. Боря — ПО в команде ninja++, которая как раз таки толкала новый чекаут.
Цитата:
Цитата:
Рационально я бы сказал, что острой необходимости в этом не было. Но есть еще другая сторона медали. Выпустив MVP ресторана (свитчер в меню) мы начали готовить клиентов к тому, что у нас в целом появится скоро этот функционал. Мы ушли от термина «самовывоз» в сторону «ресторана». Тут сложно замерить эффект, но, как минимум, переход на реальный заказ в ресторане будет более плавный. Ну и плюс главное, что мы запустили БЧ в России, больше всего профита мы получили там, а отложенная раскатка на страны в данном случае не была так критичная, так как доля заказов в странах меньше
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как мы накосячили пока делали Бриллиантовый чекаут™ 9 месяцев, а планировали 2