How to become an author
Search
Write a publication
Pull to refresh

Comments 46

Я знаю что вы делали прошлым летом. с кого срисованы ваши картинки
Оригинал
image
Total votes 6: ↑6 and ↓0+6
Образ, который узнаешь из тысячи.
Total votes 1: ↑1 and ↓0+1
250 разработчиков додо.
Можно посмотреть на результаты ваших трудов?
Total votes 6: ↑4 and ↓2+2
Добрый день, botka4aet. Сразу скажу, что до отметки 250 разработчиков мы пока не добрались, так как главной была не цифра, а те изменения в подходах к работе, построению команд, процессов, которые характерны для компаний с таким штатом разработки. Сейчас в нашей IT-команде около 100 человек.
Результаты трудов посмотреть можно, а что конкретно вы хотите увидеть?
Total votes 1: ↑1 and ↓0+1

Главный вопрос, на какой 250? А почему не 256? Ну или 300, что за число магическое?) ничем не обосновано.

Total votes 2: ↑1 and ↓10

Точно, кажется это главный просчет. С числом 256 программисты бы точно пошли в компанию, а компания — к успеху!

Total votes 2: ↑2 and ↓0+2
И еще интересно узнать, сколько приходится тестировщиков на этих 100...250 разработчиков?
This comment wasn’t rated yet0
Сейчас в команде QA шесть человек.
This comment wasn’t rated yet0
То есть получается соотношение примерно 1:17, в то время как классическим считается 1:3.
Я даже не знаю, как такое комментировать… Разве что поблагодарить вас за откровенный ответ…
This comment wasn’t rated yet0
1:3 — это ооочень старое «классическое» соотношение для аутсорс-разработки. В современной продуктовой разработке, когда ты можешь годами вкладываться в качество и автоматизацию, такое количество QA просто не нужно. В идеале все сервисы должны релизиться по зеленым тестам без ручного тестирования, а QA — заниматься тем, что написано в названии должности, т.е. обеспечением качества: выстраивать процессы и писать ту самую автоматизацию.
Ручное тестирование должно сводиться только к исследовательскому тестированию, а для него столько людей не нужно.
В реальности же есть несколько областей, где с автоматизацией пока сложно: это в первую очередь мобильные приложения и иногда веб-UI. Остальное мы как правило релизим без тестирования руками, а автотесты пишут сами разработчики.

Total votes 1: ↑1 and ↓0+1
Есть небольшой нюанс. Это всё справедливо для тех компаний, которые согласны тестировать на реальных пользователях, приняли осознанное решение это делать. Эти компании сознательно готовы пропускать баги в прод, получать баг-репорты от пользователей.

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

Работа службы поддержки в таких компаниях тоже должна быть выстроена соответствующим образом.
Total votes 1: ↑1 and ↓0+1
Весь мой опыт разработки говорит ровно об обратном. Каждый раз проводить полный ручной регресс для большой системы просто нереально: он затягивается на дни, недели, а с учетом фикса багов — иногда и месяцы, и при этом благодаря человеческому фактору всегда что-то пропускается. Ручной тестировщик в этом процессе — самый ненадежный элемент просто потому что он человек)
Если все старые фичи и баги тестируются автоматически, то и пользователи их никогда снова не увидят. Ручное тестирование нужно только в исследовательской части, как я и написал выше: новые фичи, исследования безопасности и т.п.
В Додо, кстати, мы тоже проходили этот путь: была отдельная команда тестировщиков, которая целыми днями занималась регресом монолита, в результате чего релизы были раз в неделю по средам, а все наши франчайзи в этот день надевали шапочки из фольги и молились.

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

Вообще, если сервис активно разрабатывается, то единственный способ спать спокойно — это пресловутый CI/CD, и в нем просто нет места ручному тестированию, т.к. оно слишком медленное, но это тема для отдельной большой статьи.
Total votes 1: ↑1 and ↓0+1
Слишком много спорных моментов в вашем комментарии.
Пожалуй, воздержусь от полемики, чтобы не тратить понапрасну свое и ваше время.
Total votes 2: ↑1 and ↓10
lunavsegba, на самом деле всё просто. 250 – это не самоцель. 250 – это способ изменить мышление.

В первую очередь это амбициозная цель, которая заставляет мозг мыслить по-другому и учит масштабироваться. Задумайтесь, что будет, если ваша команда из 48 человек за 2 года вырастет в 5 раз? Какие процессы придётся изменить, как трансформируется структура, каким образом нужно будет принимать решения в новых реалиях? Цифра 250 – не была цифровой самоцелью, она давала нам понимание о решениях по масштабированию, которые помогут развивать бизнес и дальше.

This comment wasn’t rated yet0

Простите, но я не сильно понимаю, что сейчас то на вашем велосипеде делают 100 то разработчиков, чем их таким вы занимаете? Зачем штат из сотни программистов, аля раздуем его и порадуемся, какая эффективность команды? Ее отдельных членов? Тут речь за оптимизацию процессов разработки и почему на что то требуется столько сил? А не слишком ли дорого? Или вы там набираете студентов за 20к и говорите, а у нас штат из 100, ещё с таким штатом тестировщиков, о чем говорили выше, ну ситуация странная, весьма.

Total votes 1: ↑1 and ↓0+1
Очевидно же, что 256 может вызвать переполнение переменной в плохо написанной системе.
This comment wasn’t rated yet0
Сейчас мы находимся на цифре 100.

Про результаты работы:


К тому же, всегда можно посмотреть наш сайт, мобильное приложение или спросить наших инженеров в чате Dodo Pizza Engineering в Telegram.
Total votes 4: ↑3 and ↓1+2

Так что за магическое число 250? С чем оно связано? Зп не выше 250к, разработчиков 250 подавай, в чем магия, додошники? Любовь к круглым цифрам? Тогда надо 256, а 250 не круглое для программистов, пора бы знать

Total votes 3: ↑1 and ↓2-1
Ответила выше в другом вашем комментарии.
This comment wasn’t rated yet0
Классно, что вы обратили внимание на Open Source в Dodo. Мы давно задумывались о том, что нам как компании нужно инвестировать в Open Source и вносить вклад в комьюнити разработчиков. Проект стартовал в мае, на данный момент есть три подпроекта.

1. Платформенная библиотеки для повышения надёжности HttpClient’а. Исходный код доступен на GitHub. Распространяется как NuGet-пакет.
2. Реализация честного Uuid в соответствии с RFC4122 в проекте Primitives. Исходный код доступен на GitHub. Распространяется как NuGet-пакет.
3. Плагин для Jaeger, позволяющий использовать базу данных Azure Data Explorer(Kusto) для хранения трейсов. Azure Data Explorer (Kusto) gRPC backend for Jaeger. Исходный код доступен на GitHub.

Мы будем очень рады, если подпроекты окажутся полезными для вас. Разумеется в них есть над чем поработать, так что ваши Issues приветствуются. Новости по проекту Open Source в Dodo публикуем в телеграм-канале.
Total votes 2: ↑2 and ↓0+2
Присоединяюсь к данному вопросу, будучи клиентом никаких особых IT-прорывов за Додо замечено не было в клиентском обслуживании, ну разве что вебка на кухне и цены чуть выше (теперь знаю почему) и… все. Даже до мобильных POS-терминалов курьерам не доросли еще в отличии от конкурентов.
PS Напомнило:
Сколько менеджеров среднего звена требуется, чтобы вкрутить лампочку… Инженер чтобы вкручивать лампочку, а 7 менеджеров чтобы говорить ему как не правильно он это делает.
Total votes 1: ↑1 and ↓0+1
Спасибо за комментарий.

Как писала выше, если говорить про техническое развитие мы начали описывать систему в серии статей «Что такое Dodo IS?», так как сложно показать весь масштаб в одном материале, также планируем в скором времени выложить технорадары и общее описание IT-команды на GitHub.

Если говорить про продуктовое развитие, хороший вопрос. Обсудим с ребятами как про это можно рассказать.
Total votes 1: ↑1 and ↓0+1
«Серия статей...» — ну т.е. штат техписателей, ясно, понятно. Не, популяризация дело нужное конечно, реклама опять же в определенных кругах Хабра…
POS-терминалы — это сложно нынче назвать продуктовым развитием, это скорее требование 21 века по дефолту. Вроде как уход от налички и т.п.
Total votes 1: ↑0 and ↓1-1
Пицца вкусная, ничего не скажу. Но вот процесс ее заказа — так себе. Сегодня испытал боль от этого, и прямо в тему попалась ваша статья.

Сначала удивила невозможность посмотреть старые заказы, чтобы повторить из истории в один клик, не выбирая заново 7 пицц и их ингредиенты. Не нашел, ладно. Затем наткнулся на предложение «комбо 7 пицц» — и в нем тщательно выбрал необходимое. Однако уже в процессе отправки заказа выяснилось, что каких-то ингредиентов не хватает, в итоге всё комбо заказать невозможно. Какая именно пицца из этого комбо сфейлилась — не сказано. Гадайте как хотите.

Пришлось в третий раз выбирать эти семь пицц уже вручную, чтобы найти ту, на которую не хватает ингредиентов. А потом формировать новое комбо уже без нее. Через минут 20 заказ в итоге был сформирован, пицца заказана, получена и съедена.

Надеюсь, ваши новые 150 разработчиков смогут исправить эти недочеты :)
Total votes 5: ↑4 and ↓1+3

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

This comment wasn’t rated yet0
Это в дополнение к тем 100, которых вы уже наняли?!
Может что-то в консерватории подправить критерии найма поменять?

Вот я помнится несколько лет назад проходил у вас собеседование.
Отказали, т.к. по словам руководителя мои взгляды не соответствовали принятым в компании.
Не хотелось бы показаться самонадеянным, но мои взгляды точно бы не позволили случиться ситуации, на которую пожаловался vlad49 выше.
Total votes 1: ↑1 and ↓0+1
Михаил, если я правильно прочитала между строк, вы говорите, что ваши взгляды могли бы помочь сделать приложение, сайт, а вместе с ними и жизнь клиентов лучше. Верно?
Прошло несколько лет, многое могло измениться в вас и в нас. Оставлю ссылку на наши актуальные вакансии, может быть пришло время поработать вместе.
This comment wasn’t rated yet0
Нет, Олеся, работать в компании, где на одного тестировщика приходится 17 разработчиков мне совсем не хочется. Видимо, за последние несколько лет взгляды компании не так уж и изменились…

За ссылку на ваши актуальные вакансии спасибо, конечно. Но там опять же требуются разработчики, а не тестировщики.
Total votes 1: ↑1 and ↓0+1

Мне кажется описанное вами — скорее про тестирование, интерфейсы и менеджмент (может описанные вами проблемы известны, но их решили не фиксить, т.к. не нашли коммерческих причин, мало кто на них натыкается). И бОльшее число разработчиков тут ничего не исправят :(

Total votes 2: ↑2 and ↓0+2

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

This comment wasn’t rated yet0

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


История заказов есть, она находиться в профиле, это вторая вкладка. Далеко, неочевидно, когда-нибудь сделаем проще.


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

Total votes 2: ↑2 and ↓0+2
Мода называть красивыми иностранными словами обычные понятные вещи ещё не прошла.
Испытательный срок, стажировка, вводный инструктаж, кадровик…
Total votes 4: ↑3 and ↓1+2
Я уже обращал на это их внимание в одном из комментариев в другой статье. Бесполезно, увы.
This comment wasn’t rated yet0
Да, и выбирать себе имя типа lttlcrazy, видимо, тоже считается в Додо очень здорово.
Может и мне в резюме оставить контакт наподобие bigmadness@gmail.com…
Total votes 5: ↑0 and ↓5-5
Я не специалист в теме онбординга, поэтому прошу простить за дилетантский подход, но мне кажется, что для коллектива в 100 человек, вполне возможно обойтись просто здоровым отношением в коллективе.

Вот как некий «онбординг», силами «старичков», происходит у нас в региональном филиале на 25 человек, без построенных процессов и формальных процедур:

1) Знакомство, поддержка по вопросам в процессе чтения трудового договора
2) Показывается офис: где туалет, где кухня, принципы добровольной покупки кофепринадлежностей, что делать если что-то не выдали или сломалось, в какие кафешки можно сходить на обед
3) Объясняется как подключиться к корпоративной сети, какие информационные ресурсы нужны и ссылка к пространству, где описаны всякие процедуры
4) В процессе обычного общения рассказывается про линейных руководителей, директоров и всякие штуки типа корпоративов
5) В середине испыталки подойдет HR и обсудит проблемы/вопросы/переживания и оценит как человеку на новом месте

Возможно эта техника не масштабируется, но на нашем объеме работает. Если офис вдруг сильно разрастется, то просто на каждый укрупненный блок можно попросить одного-двух человек помогать новичкам. Пока у нас обходилось без просьб, просто кто свободен или с одного проекта — подходит и рассказывает все это дело :)
Total votes 2: ↑2 and ↓0+2
Добрый день, hMartin! Спасибо за комментарий и интерес к процессу онбординга в нашей компании!

Сразу уточню, что 100 человек — это только IT-команда. А во всей управляющей компании сейчас работает около 300 человек. И мы продолжаем расти.

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

Так мы и делали до момента взрывного роста. Команда сильно выросла, один офис превратился в шесть + удалённые сотрудники. Взаимосвязи команд друг с другом усложнились, например, между диджитал дизайнерами и разработчиками, маркетологами с R&D лабораторией и продакт оунерами и так далее. Усложнилась система коммуникаций, увеличилось количество сотрудников + бизнес и клиенты все ещё ждут новых фич и фикса старых.

На нынешней отметке, с нынешним потоком найма и скоростью усложнения бизнес-процессов мы как раз поняли, что такая схема, как сейчас у вас, не масштабируется. А жаль. Всё это привело к тому, что вы прочитали в статье.

Будет круто узнать, как вы справляетесь с этим процессом по мере роста компании. Если вы через полгода-год вернётесь рассказать про ваши изменения в онбординге (или их отсутствие) буду очень рада.
Total votes 2: ↑2 and ↓0+2
Спасибо за развернутый ответ! Надеюсь что кризис минует и мы продолжим расти, тогда смогу поделиться наблюдениями :)
Total votes 1: ↑1 and ↓0+1

А у вас что-то поменялось по части распределённости команд или по-прежнему — только московский офис?

Total votes 2: ↑2 and ↓0+2

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

Total votes 1: ↑1 and ↓0+1
А как часто вообще происходит увольнение по результатам этих 3 месяцев? Ну т.е. что будет если отзыв от ментора будет — «что-то человек не тянет». Или как таковой такой задачи нет?
Total votes 3: ↑2 and ↓1+1

Увольнение по итогам 3 месяцев испытательного срока происходит редко. Мы выстроили весь процесс найма и онбординга таким образом, чтобы такого просто не происходило. Если ментор замечает, что что-то идёт не так, мы узнаём об этом сразу и попытаемся исправить ситуацию ещё в зародыше.


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

Total votes 2: ↑2 and ↓0+2
Так а не боитесь при таком подходе что останутся довольно средние люди? Или как таковой нет политики сделать лучшее IT? Ну т.е. то что вы написали это подход больших компаний, но они не всегда эффективны в плане разработки полезной функциональности
This comment wasn’t rated yet0
Почему средние? Цикл найма предполагает довольно серьёзный отбор на старте.

И политика сделать IT лучшее тоже есть. Недавно наш СТО писал об этом пост. Вот выдержка из него: «Кандидаты делятся на: “точно нет”, “возможно” и “точно да”. Тем, кто “точно нет”, сразу отказываем. Остальных смотрим дальше, уточняем, в каких скиллах, подходах, он может нас усилить.

Уровень кандидата в сравнении с командой Додо дают ответ на вопрос — усилит человек нашу команду или нет? Обладает ли он такими навыками, которых у нас нет или их немного? Если да, стоит делать оффер».
Total votes 1: ↑1 and ↓0+1
Я не из Додо, но решил поделиться как у меня в компаниях было. Всего два случая за несколько лет, правда.
1 случай. Лид на хорошей должности просто забивал на трудовые обязанности и «делигировал» на сотрудников свою работу, красиво отмазывался и делал процентов 20 от своих обязанностей, на втором месяце с ним поговорило руководство и он решил уйти сам.
2 случай. Один обычный специалист хорошо начал, но был достаточно замкнут в себе, а потом начался театр — кошка рожает, застрял в пробке, заболел на две недели. Тоже пытались сначала разобраться в причинах и помочь человеку, но он продолжил забивать на работу и тоже ушел по «собственной» инициативе, рассчитали его за фактически отработанные дни, насколько я помню. Это было в его интересах, так как пропуски работы фиксировались каждый раз.
Total votes 2: ↑2 and ↓0+2
Sign up to leave a comment.

Your account

Sections

Information

Services

Support
© 2006–2024, Habr