Комментарии 46
Я знаю что вы делали прошлым летом. с кого срисованы ваши картинки
Оригинал
250 разработчиков додо.
Можно посмотреть на результаты ваших трудов?
Можно посмотреть на результаты ваших трудов?
Добрый день, botka4aet. Сразу скажу, что до отметки 250 разработчиков мы пока не добрались, так как главной была не цифра, а те изменения в подходах к работе, построению команд, процессов, которые характерны для компаний с таким штатом разработки. Сейчас в нашей IT-команде около 100 человек.
Результаты трудов посмотреть можно, а что конкретно вы хотите увидеть?
Результаты трудов посмотреть можно, а что конкретно вы хотите увидеть?
Главный вопрос, на какой 250? А почему не 256? Ну или 300, что за число магическое?) ничем не обосновано.
Точно, кажется это главный просчет. С числом 256 программисты бы точно пошли в компанию, а компания — к успеху!
И еще интересно узнать, сколько приходится тестировщиков на этих 100...250 разработчиков?
Сейчас в команде QA шесть человек.
То есть получается соотношение примерно 1:17, в то время как классическим считается 1:3.
Я даже не знаю, как такое комментировать… Разве что поблагодарить вас за откровенный ответ…
Я даже не знаю, как такое комментировать… Разве что поблагодарить вас за откровенный ответ…
1:3 — это ооочень старое «классическое» соотношение для аутсорс-разработки. В современной продуктовой разработке, когда ты можешь годами вкладываться в качество и автоматизацию, такое количество QA просто не нужно. В идеале все сервисы должны релизиться по зеленым тестам без ручного тестирования, а QA — заниматься тем, что написано в названии должности, т.е. обеспечением качества: выстраивать процессы и писать ту самую автоматизацию.
Ручное тестирование должно сводиться только к исследовательскому тестированию, а для него столько людей не нужно.
В реальности же есть несколько областей, где с автоматизацией пока сложно: это в первую очередь мобильные приложения и иногда веб-UI. Остальное мы как правило релизим без тестирования руками, а автотесты пишут сами разработчики.
Ручное тестирование должно сводиться только к исследовательскому тестированию, а для него столько людей не нужно.
В реальности же есть несколько областей, где с автоматизацией пока сложно: это в первую очередь мобильные приложения и иногда веб-UI. Остальное мы как правило релизим без тестирования руками, а автотесты пишут сами разработчики.
Есть небольшой нюанс. Это всё справедливо для тех компаний, которые согласны тестировать на реальных пользователях, приняли осознанное решение это делать. Эти компании сознательно готовы пропускать баги в прод, получать баг-репорты от пользователей.
Потому как автоматизация не может найти все проблемы в продукте, и если у вас QA занимаются только выстраиванием процессов и автоматизацией проверок, то реальные пользователи будут находить реальные баги.
Работа службы поддержки в таких компаниях тоже должна быть выстроена соответствующим образом.
Потому как автоматизация не может найти все проблемы в продукте, и если у вас QA занимаются только выстраиванием процессов и автоматизацией проверок, то реальные пользователи будут находить реальные баги.
Работа службы поддержки в таких компаниях тоже должна быть выстроена соответствующим образом.
Весь мой опыт разработки говорит ровно об обратном. Каждый раз проводить полный ручной регресс для большой системы просто нереально: он затягивается на дни, недели, а с учетом фикса багов — иногда и месяцы, и при этом благодаря человеческому фактору всегда что-то пропускается. Ручной тестировщик в этом процессе — самый ненадежный элемент просто потому что он человек)
Если все старые фичи и баги тестируются автоматически, то и пользователи их никогда снова не увидят. Ручное тестирование нужно только в исследовательской части, как я и написал выше: новые фичи, исследования безопасности и т.п.
В Додо, кстати, мы тоже проходили этот путь: была отдельная команда тестировщиков, которая целыми днями занималась регресом монолита, в результате чего релизы были раз в неделю по средам, а все наши франчайзи в этот день надевали шапочки из фольги и молились.
Да, автоматизация процессов тестирования требует намного более высоких скилов и дисциплины от разработчиков, но таков путь.
Вообще, если сервис активно разрабатывается, то единственный способ спать спокойно — это пресловутый CI/CD, и в нем просто нет места ручному тестированию, т.к. оно слишком медленное, но это тема для отдельной большой статьи.
Если все старые фичи и баги тестируются автоматически, то и пользователи их никогда снова не увидят. Ручное тестирование нужно только в исследовательской части, как я и написал выше: новые фичи, исследования безопасности и т.п.
В Додо, кстати, мы тоже проходили этот путь: была отдельная команда тестировщиков, которая целыми днями занималась регресом монолита, в результате чего релизы были раз в неделю по средам, а все наши франчайзи в этот день надевали шапочки из фольги и молились.
Да, автоматизация процессов тестирования требует намного более высоких скилов и дисциплины от разработчиков, но таков путь.
Вообще, если сервис активно разрабатывается, то единственный способ спать спокойно — это пресловутый CI/CD, и в нем просто нет места ручному тестированию, т.к. оно слишком медленное, но это тема для отдельной большой статьи.
Слишком много спорных моментов в вашем комментарии.
Пожалуй, воздержусь от полемики, чтобы не тратить понапрасну свое и ваше время.
Пожалуй, воздержусь от полемики, чтобы не тратить понапрасну свое и ваше время.
lunavsegba, на самом деле всё просто. 250 – это не самоцель. 250 – это способ изменить мышление.
В первую очередь это амбициозная цель, которая заставляет мозг мыслить по-другому и учит масштабироваться. Задумайтесь, что будет, если ваша команда из 48 человек за 2 года вырастет в 5 раз? Какие процессы придётся изменить, как трансформируется структура, каким образом нужно будет принимать решения в новых реалиях? Цифра 250 – не была цифровой самоцелью, она давала нам понимание о решениях по масштабированию, которые помогут развивать бизнес и дальше.
В первую очередь это амбициозная цель, которая заставляет мозг мыслить по-другому и учит масштабироваться. Задумайтесь, что будет, если ваша команда из 48 человек за 2 года вырастет в 5 раз? Какие процессы придётся изменить, как трансформируется структура, каким образом нужно будет принимать решения в новых реалиях? Цифра 250 – не была цифровой самоцелью, она давала нам понимание о решениях по масштабированию, которые помогут развивать бизнес и дальше.
Простите, но я не сильно понимаю, что сейчас то на вашем велосипеде делают 100 то разработчиков, чем их таким вы занимаете? Зачем штат из сотни программистов, аля раздуем его и порадуемся, какая эффективность команды? Ее отдельных членов? Тут речь за оптимизацию процессов разработки и почему на что то требуется столько сил? А не слишком ли дорого? Или вы там набираете студентов за 20к и говорите, а у нас штат из 100, ещё с таким штатом тестировщиков, о чем говорили выше, ну ситуация странная, весьма.
У вас правильные и интересные вопросы. Подскажите, пожалуйста, серия статей о том, что такое Dodo IS не отвечает на них?
Очевидно же, что 256 может вызвать переполнение переменной в плохо написанной системе.
Сейчас мы находимся на цифре 100.
Про результаты работы:
К тому же, всегда можно посмотреть наш сайт, мобильное приложение или спросить наших инженеров в чате Dodo Pizza Engineering в Telegram.
Про результаты работы:
- Начали выпуск серии статей про IT в Додо.
- Все актуальные данные про бизнес вы можете найти на нашем сайте, а также узнать из соц. сетей Фёдора.
- Результаты работы команд можно найти на нашем YouTube канале, либо на еженедельных встречах, которые проходят каждый понедельник в 8:30 там же.
К тому же, всегда можно посмотреть наш сайт, мобильное приложение или спросить наших инженеров в чате Dodo Pizza Engineering в Telegram.
Ну вот "взрослый опенсорс" на гитхабе: https://github.com/dodopizza У некоторых репозиториев есть даже по 30 звёздочек.
Классно, что вы обратили внимание на 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 публикуем в телеграм-канале.
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 публикуем в телеграм-канале.
Присоединяюсь к данному вопросу, будучи клиентом никаких особых IT-прорывов за Додо замечено не было в клиентском обслуживании, ну разве что вебка на кухне и цены чуть выше (теперь знаю почему) и… все. Даже до мобильных POS-терминалов курьерам не доросли еще в отличии от конкурентов.
PS Напомнило:
PS Напомнило:
Сколько менеджеров среднего звена требуется, чтобы вкрутить лампочку… Инженер чтобы вкручивать лампочку, а 7 менеджеров чтобы говорить ему как не правильно он это делает.
Спасибо за комментарий.
Как писала выше, если говорить про техническое развитие мы начали описывать систему в серии статей «Что такое Dodo IS?», так как сложно показать весь масштаб в одном материале, также планируем в скором времени выложить технорадары и общее описание IT-команды на GitHub.
Если говорить про продуктовое развитие, хороший вопрос. Обсудим с ребятами как про это можно рассказать.
Как писала выше, если говорить про техническое развитие мы начали описывать систему в серии статей «Что такое Dodo IS?», так как сложно показать весь масштаб в одном материале, также планируем в скором времени выложить технорадары и общее описание IT-команды на GitHub.
Если говорить про продуктовое развитие, хороший вопрос. Обсудим с ребятами как про это можно рассказать.
Пицца вкусная, ничего не скажу. Но вот процесс ее заказа — так себе. Сегодня испытал боль от этого, и прямо в тему попалась ваша статья.
Сначала удивила невозможность посмотреть старые заказы, чтобы повторить из истории в один клик, не выбирая заново 7 пицц и их ингредиенты. Не нашел, ладно. Затем наткнулся на предложение «комбо 7 пицц» — и в нем тщательно выбрал необходимое. Однако уже в процессе отправки заказа выяснилось, что каких-то ингредиентов не хватает, в итоге всё комбо заказать невозможно. Какая именно пицца из этого комбо сфейлилась — не сказано. Гадайте как хотите.
Пришлось в третий раз выбирать эти семь пицц уже вручную, чтобы найти ту, на которую не хватает ингредиентов. А потом формировать новое комбо уже без нее. Через минут 20 заказ в итоге был сформирован, пицца заказана, получена и съедена.
Надеюсь, ваши новые 150 разработчиков смогут исправить эти недочеты :)
Сначала удивила невозможность посмотреть старые заказы, чтобы повторить из истории в один клик, не выбирая заново 7 пицц и их ингредиенты. Не нашел, ладно. Затем наткнулся на предложение «комбо 7 пицц» — и в нем тщательно выбрал необходимое. Однако уже в процессе отправки заказа выяснилось, что каких-то ингредиентов не хватает, в итоге всё комбо заказать невозможно. Какая именно пицца из этого комбо сфейлилась — не сказано. Гадайте как хотите.
Пришлось в третий раз выбирать эти семь пицц уже вручную, чтобы найти ту, на которую не хватает ингредиентов. А потом формировать новое комбо уже без нее. Через минут 20 заказ в итоге был сформирован, пицца заказана, получена и съедена.
Надеюсь, ваши новые 150 разработчиков смогут исправить эти недочеты :)
Спасибо вам за то, что выбираете нас. Надеемся, что в дальнейшем ваш опыт, как нашего клиента, будет только лучше!
Мы как раз сейчас ведём найм людей, которые смогут нас усилить и ускорить выпуск фич.
Это в дополнение к тем 100, которых вы уже наняли?!
Можетчто-то в консерватории подправить критерии найма поменять?
Вот я помнится несколько лет назад проходил у вас собеседование.
Отказали, т.к. по словам руководителя мои взгляды не соответствовали принятым в компании.
Не хотелось бы показаться самонадеянным, но мои взгляды точно бы не позволили случиться ситуации, на которую пожаловался vlad49 выше.
Может
Вот я помнится несколько лет назад проходил у вас собеседование.
Отказали, т.к. по словам руководителя мои взгляды не соответствовали принятым в компании.
Не хотелось бы показаться самонадеянным, но мои взгляды точно бы не позволили случиться ситуации, на которую пожаловался vlad49 выше.
Михаил, если я правильно прочитала между строк, вы говорите, что ваши взгляды могли бы помочь сделать приложение, сайт, а вместе с ними и жизнь клиентов лучше. Верно?
Прошло несколько лет, многое могло измениться в вас и в нас. Оставлю ссылку на наши актуальные вакансии, может быть пришло время поработать вместе.
Прошло несколько лет, многое могло измениться в вас и в нас. Оставлю ссылку на наши актуальные вакансии, может быть пришло время поработать вместе.
Нет, Олеся, работать в компании, где на одного тестировщика приходится 17 разработчиков мне совсем не хочется. Видимо, за последние несколько лет взгляды компании не так уж и изменились…
За ссылку на ваши актуальные вакансии спасибо, конечно. Но там опять же требуются разработчики, а не тестировщики.
За ссылку на ваши актуальные вакансии спасибо, конечно. Но там опять же требуются разработчики, а не тестировщики.
Мне кажется описанное вами — скорее про тестирование, интерфейсы и менеджмент (может описанные вами проблемы известны, но их решили не фиксить, т.к. не нашли коммерческих причин, мало кто на них натыкается). И бОльшее число разработчиков тут ничего не исправят :(
Привет, я разработчик мобильного приложения. Если заказывали в нем, то смогу рассказать почему так. Кратко: у всего разные приоритеты. Мы бы рады улучшить, но ресурсов немного, а задач навалом. Все как у всех.
История заказов есть, она находиться в профиле, это вторая вкладка. Далеко, неочевидно, когда-нибудь сделаем проще.
Проблема с комбо в корзине и отсутствием ингредиентов очень важная, она в ближайших планах. Уже в ближайшем релизе появится выбор адреса прямо в меню, а значит мы поймем в какой пиццерии вы заказываете, узнаем наличие в ней ингредиентов и сможем раньше показать что доступно, а что нет.
Мода называть красивыми иностранными словами обычные понятные вещи ещё не прошла.
Испытательный срок, стажировка, вводный инструктаж, кадровик…
Испытательный срок, стажировка, вводный инструктаж, кадровик…
Я уже обращал на это их внимание в одном из комментариев в другой статье. Бесполезно, увы.
Да, и выбирать себе имя типа lttlcrazy, видимо, тоже считается в Додо очень здорово.
Может и мне в резюме оставить контакт наподобие bigmadness@gmail.com…
Может и мне в резюме оставить контакт наподобие bigmadness@gmail.com…
Я не специалист в теме онбординга, поэтому прошу простить за дилетантский подход, но мне кажется, что для коллектива в 100 человек, вполне возможно обойтись просто здоровым отношением в коллективе.
Вот как некий «онбординг», силами «старичков», происходит у нас в региональном филиале на 25 человек, без построенных процессов и формальных процедур:
1) Знакомство, поддержка по вопросам в процессе чтения трудового договора
2) Показывается офис: где туалет, где кухня, принципы добровольной покупки кофепринадлежностей, что делать если что-то не выдали или сломалось, в какие кафешки можно сходить на обед
3) Объясняется как подключиться к корпоративной сети, какие информационные ресурсы нужны и ссылка к пространству, где описаны всякие процедуры
4) В процессе обычного общения рассказывается про линейных руководителей, директоров и всякие штуки типа корпоративов
5) В середине испыталки подойдет HR и обсудит проблемы/вопросы/переживания и оценит как человеку на новом месте
Возможно эта техника не масштабируется, но на нашем объеме работает. Если офис вдруг сильно разрастется, то просто на каждый укрупненный блок можно попросить одного-двух человек помогать новичкам. Пока у нас обходилось без просьб, просто кто свободен или с одного проекта — подходит и рассказывает все это дело :)
Вот как некий «онбординг», силами «старичков», происходит у нас в региональном филиале на 25 человек, без построенных процессов и формальных процедур:
1) Знакомство, поддержка по вопросам в процессе чтения трудового договора
2) Показывается офис: где туалет, где кухня, принципы добровольной покупки кофепринадлежностей, что делать если что-то не выдали или сломалось, в какие кафешки можно сходить на обед
3) Объясняется как подключиться к корпоративной сети, какие информационные ресурсы нужны и ссылка к пространству, где описаны всякие процедуры
4) В процессе обычного общения рассказывается про линейных руководителей, директоров и всякие штуки типа корпоративов
5) В середине испыталки подойдет HR и обсудит проблемы/вопросы/переживания и оценит как человеку на новом месте
Возможно эта техника не масштабируется, но на нашем объеме работает. Если офис вдруг сильно разрастется, то просто на каждый укрупненный блок можно попросить одного-двух человек помогать новичкам. Пока у нас обходилось без просьб, просто кто свободен или с одного проекта — подходит и рассказывает все это дело :)
Добрый день, hMartin! Спасибо за комментарий и интерес к процессу онбординга в нашей компании!
Сразу уточню, что 100 человек — это только IT-команда. А во всей управляющей компании сейчас работает около 300 человек. И мы продолжаем расти.
Несколько лет назад вся компания помещалась в офисе г. Сыктывкар, там как такового процесса онбординга не было, и новичок вливался в коллектив ровно так, как происходит сейчас у вас. Честно говоря, мне кажется то, что вы описали очень соотносится с нашим онбордингом, только без стандартизации, сроков, ролей и зон ответственности участников.
Так мы и делали до момента взрывного роста. Команда сильно выросла, один офис превратился в шесть + удалённые сотрудники. Взаимосвязи команд друг с другом усложнились, например, между диджитал дизайнерами и разработчиками, маркетологами с R&D лабораторией и продакт оунерами и так далее. Усложнилась система коммуникаций, увеличилось количество сотрудников + бизнес и клиенты все ещё ждут новых фич и фикса старых.
На нынешней отметке, с нынешним потоком найма и скоростью усложнения бизнес-процессов мы как раз поняли, что такая схема, как сейчас у вас, не масштабируется. А жаль. Всё это привело к тому, что вы прочитали в статье.
Будет круто узнать, как вы справляетесь с этим процессом по мере роста компании. Если вы через полгода-год вернётесь рассказать про ваши изменения в онбординге (или их отсутствие) буду очень рада.
Сразу уточню, что 100 человек — это только IT-команда. А во всей управляющей компании сейчас работает около 300 человек. И мы продолжаем расти.
Несколько лет назад вся компания помещалась в офисе г. Сыктывкар, там как такового процесса онбординга не было, и новичок вливался в коллектив ровно так, как происходит сейчас у вас. Честно говоря, мне кажется то, что вы описали очень соотносится с нашим онбордингом, только без стандартизации, сроков, ролей и зон ответственности участников.
Так мы и делали до момента взрывного роста. Команда сильно выросла, один офис превратился в шесть + удалённые сотрудники. Взаимосвязи команд друг с другом усложнились, например, между диджитал дизайнерами и разработчиками, маркетологами с R&D лабораторией и продакт оунерами и так далее. Усложнилась система коммуникаций, увеличилось количество сотрудников + бизнес и клиенты все ещё ждут новых фич и фикса старых.
На нынешней отметке, с нынешним потоком найма и скоростью усложнения бизнес-процессов мы как раз поняли, что такая схема, как сейчас у вас, не масштабируется. А жаль. Всё это привело к тому, что вы прочитали в статье.
Будет круто узнать, как вы справляетесь с этим процессом по мере роста компании. Если вы через полгода-год вернётесь рассказать про ваши изменения в онбординге (или их отсутствие) буду очень рада.
А у вас что-то поменялось по части распределённости команд или по-прежнему — только московский офис?
Сейчас мы все еще в большинстве своем работаем из дома до конца июля. Но есть те, кто хочет ходить в офис – ходит, кому по соображениям собственного комфорта и безопасности, удобно работать из дома – работают из дома.
Работая на удаленке мы поняли, что в ней нет ничего страшного, поэтому после того, как все карантинные меры потеряют свою актуальность мы планируем дать командам самим выбирать: они будут распределенной командой или локализованной в офисе.
А как часто вообще происходит увольнение по результатам этих 3 месяцев? Ну т.е. что будет если отзыв от ментора будет — «что-то человек не тянет». Или как таковой такой задачи нет?
Увольнение по итогам 3 месяцев испытательного срока происходит редко. Мы выстроили весь процесс найма и онбординга таким образом, чтобы такого просто не происходило. Если ментор замечает, что что-то идёт не так, мы узнаём об этом сразу и попытаемся исправить ситуацию ещё в зародыше.
Разбираемся в причинах: что конкретно новичок не тянет, как выглядит их процесс парной работы с ментором и прочее. Причина может быть зарыта где угодно от предъявления требований к кандидату до найма и до локальных действий внутри команды, и всё надо исследовать. В первую очередь, мы стараемся удержать человека и помочь ему справиться с трудностями.
Так а не боитесь при таком подходе что останутся довольно средние люди? Или как таковой нет политики сделать лучшее IT? Ну т.е. то что вы написали это подход больших компаний, но они не всегда эффективны в плане разработки полезной функциональности
Почему средние? Цикл найма предполагает довольно серьёзный отбор на старте.
И политика сделать IT лучшее тоже есть. Недавно наш СТО писал об этом пост. Вот выдержка из него: «Кандидаты делятся на: “точно нет”, “возможно” и “точно да”. Тем, кто “точно нет”, сразу отказываем. Остальных смотрим дальше, уточняем, в каких скиллах, подходах, он может нас усилить.
Уровень кандидата в сравнении с командой Додо дают ответ на вопрос — усилит человек нашу команду или нет? Обладает ли он такими навыками, которых у нас нет или их немного? Если да, стоит делать оффер».
И политика сделать IT лучшее тоже есть. Недавно наш СТО писал об этом пост. Вот выдержка из него: «Кандидаты делятся на: “точно нет”, “возможно” и “точно да”. Тем, кто “точно нет”, сразу отказываем. Остальных смотрим дальше, уточняем, в каких скиллах, подходах, он может нас усилить.
Уровень кандидата в сравнении с командой Додо дают ответ на вопрос — усилит человек нашу команду или нет? Обладает ли он такими навыками, которых у нас нет или их немного? Если да, стоит делать оффер».
Я не из Додо, но решил поделиться как у меня в компаниях было. Всего два случая за несколько лет, правда.
1 случай. Лид на хорошей должности просто забивал на трудовые обязанности и «делигировал» на сотрудников свою работу, красиво отмазывался и делал процентов 20 от своих обязанностей, на втором месяце с ним поговорило руководство и он решил уйти сам.
2 случай. Один обычный специалист хорошо начал, но был достаточно замкнут в себе, а потом начался театр — кошка рожает, застрял в пробке, заболел на две недели. Тоже пытались сначала разобраться в причинах и помочь человеку, но он продолжил забивать на работу и тоже ушел по «собственной» инициативе, рассчитали его за фактически отработанные дни, насколько я помню. Это было в его интересах, так как пропуски работы фиксировались каждый раз.
1 случай. Лид на хорошей должности просто забивал на трудовые обязанности и «делигировал» на сотрудников свою работу, красиво отмазывался и делал процентов 20 от своих обязанностей, на втором месяце с ним поговорило руководство и он решил уйти сам.
2 случай. Один обычный специалист хорошо начал, но был достаточно замкнут в себе, а потом начался театр — кошка рожает, застрял в пробке, заболел на две недели. Тоже пытались сначала разобраться в причинах и помочь человеку, но он продолжил забивать на работу и тоже ушел по «собственной» инициативе, рассчитали его за фактически отработанные дни, насколько я помню. Это было в его интересах, так как пропуски работы фиксировались каждый раз.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Онбординг разработчиков