Pull to refresh

Comments 23

Постоянно смотрим в код, включаем в оценку время тесты.

На аналитику время заложили.

И на тестирование тоже.

И на возможные баги с прода.

И ещё всякого по мелочи.


а время на исправление багов по результатам тестирования?
Любой баг, по сути, нежданчик. Мы не можем его спланировать заранее.
А для нежданчиков у нас есть лаг — 50% от запланированного времени на задачи. Например, если мы оценили задачи в 20 часов, то лаг будет 10 часов.

Последнее время замечаем, что 50% нам стало многовато. Попробуем понизить или ещё что сделать. Но пока так.
Шикарная статья, спасибо.

Отличный материал на котором можно учить других и о том как оно может пойти и о том как самоорганизующаяся команда должна с этим справляться.

Хорошая у вас команда. :-)
Прочитав заголовок и открыв статью долго ждал, где же будет
git checkout

и зачем там использовать


PS: Как прогресс с микросервисами? Есть ли ETA полного отказа от монолита?

Если вы про iOS-приложение, то оно у нас уже распилено больше, чем на половину.


А если вы про тот самый М О Н О Л И Т — это не ко мне. Но могу уточнить.

Я чувствую что-то неправильное в том что полтора экранчика делаются почти через героическое преодолевание трудностей. Почему так долго-то? А сколько в результате десятков тысяч строк кода написано?


То что список из 200 пунктов вызывает проблемы с производительностью — тоже непонятно. Из 200 тысяч пунктов я бы понял, но 200?

*почти год. Куда-то буквы из сообщения отвалились

Кровавый энтерпрайз жи ну:) 12 макетов за 8 месяцев — это реально быстро. Без сарказма.
На самом деле в новом чекауте 10 экранов:
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 ресторана (свитчер в меню) мы начали готовить клиентов к тому, что у нас в целом появится скоро этот функционал. Мы ушли от термина «самовывоз» в сторону «ресторана». Тут сложно замерить эффект, но, как минимум, переход на реальный заказ в ресторане будет более плавный. Ну и плюс главное, что мы запустили БЧ в России, больше всего профита мы получили там, а отложенная раскатка на страны в данном случае не была так критичная, так как доля заказов в странах меньше


Sign up to leave a comment.