company_banner

Онбординг разработчиков

    «Я прихожу на работу, мне дают ноутбук, показывают рабочее место, выдают задачу, а дальше сиди и делай сам. Спустя пару месяцев я должен знать всё о компании, но, на самом деле, я помню только сделанные задачи. Кому задавать вопросы? А можно подойти к директору? Где туалет?». Таким выглядит мир новичков в компаниях, где нет онбординга. Когда-то и мы были такими. В статье расскажем о том, как создали с нуля инструмент для онбординга новичков и выстроили процессы за год.





    Автор статьи: Яна Ходарцевич — Scrum master и онбординг лид в Додо Пицце.



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

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

    • Ничего не предпринимать, пусть выплывает сам. При таком раскладе новому сотруднику в первый день выдают ноут/комп, показывают, где кулер и провожают к рабочему столу. А через три месяца задают вопрос: «Ну как, все задачи готовы?». Хардкорно, но действенно, как в Спарте. Выживает мощнейший.
    • Сделать всё за новичка. При таком раскладе наставник или ментор везде носится с новичком, всё подсказывает, многое делает за него, чтобы не дать новичку ошибиться (читай «справиться самостоятельно»). Такой подход растит количество сотрудников, но не самостоятельность в них. А ещё занимает максимальное время наставника, что приводит к его полному выключению из текущих проектов.
    • Дать все необходимые инструменты, показать, как ими пользоваться и отпустить в плавание. Такой вариант онбординга кажется золотой серединой среди остальных. Он позволяет компании проявлять заботу о новых людях, безболезненно погружать их в процессы, а самим новичкам проявлять инициативу и учиться самостоятельности.

    Предпосылки к созданию процесса


    Как мы жили без онбординга


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

    Жирный повод к созданию процесса


    В 2018-2019 в команде произошёл взрывной рост — за два года мы выросли в два раза. Слышали про цель 250 разработчиков? Тогда мы упорно взялись за её выполнение, но ещё не знали, что не готовы к столь бурному росту. Наши подходы и ресурсы к расширению команд быстро исчерпали себя. В конечном итоге даже посадочные места для новичков находились с трудом. Но поняли мы это не сразу.

    Люди приходили в компанию и как-то оседали в командах, никто за ними особо не присматривал. По сути весь онбординг состоял из велком-пакета, дружелюбного приветствия, экскурсии по офису и, пожалуй, всё.

    Мы попытались натянуть старые процессы на новую реальность и треснули, как стеклянный стакан, в который резко влили кипяток. Без единой системы онбординга погружение новичка в команду было больше похоже на историю главного героя в фильме «Выживший». Когда мы обернулись назад, поняли, что потеряли много (более 40) новых сотрудников.

    Добро пожаловать на борт


    Формально мы разделяем онбординг на 2 потока: для IT-команды и для бизнес-подразделения. Они очень похожи друг на друга, а разница лишь в количестве этапов и Intro-встреч. В этой статье я расскажу про онбординг в IT-команду. Короткое видео о том, зачем вообще он нужен и какая от него польза, можно посмотреть здесь. Дальше делюсь подробностями.

    Действующие лица


    В процессе онбординга новичка принимают участие три действующих лица: ментор, онбординг лид и hr-куратор.



    Ментор.
    Цель: погрузить новичка в команду.
    Кто это такой и что он делает: ментор играет главную роль в онбординге новичка (даже если он об этом не знает). Это человек, который во всём помогает новичку. Он встречает его в первый день и полностью отпускает только по завершении онбординга. Знакомит с командой, поддерживает, отвечает на все почемучные и зачемные вопросы.

    Стать ментором может человек из команды новичка. Это может быть как человек с тем же стеком, так и, к примеру, Android-разработчик для mapi-новичка. Если у ментора и новичка стек один, то выбора у них нет — они очень много времени будут работать в паре. Если ментор и новичок из разных стеков, есть 2 опции:

    • Ментор на максималках. Ментор и новичок готовы работать в паре, ментор помогает с решением задач из разных стеков.
    • Ментор на минималках. Нет плотной совместной работы в вопросах разработки, есть синхронизация по процессам. Этот вариант может также подойти, если к вам в компанию пришёл супер-активный senior-разработчик, и ему не хватает лишь знаний домена и принципов работы компании.



    Онбординг лид.
    Цель: проконтролировать процесс онбординга, убедиться, что всё движется в нужную сторону.
    Кто это такой и что он делает: онбординг лид — это организатор онбординга в IT. Чтобы им стать необходимы скиллы по матчасти. Важно, чтобы онбординг лид знал и понимал ценность каждого из инструментов в IT, «варился в этой культуре». Основная задача онбординг лида — удостовериться, что у ментора с новичком всё получается, а моменты, которые не получаются, подсветить. Эта роль очень похожа на полицейского. Онбординг лид ходит где-то рядом, поглядывает за новичком, спрашивает, как дела, что уже получается. Подсказывает ментору в любых вопросах, оказывает поддержку. В общем, следит за порядком, чтобы всё было так, как должно быть (а как не должно быть — не было).



    HR-куратор.
    Цель: обеспечить новичку приятное вхождение в компанию с момента выставления оффера. Предоставить всю необходимую информацию со стороны HR, которая позволит ориентироваться новому сотруднику в компании.

    Кто это такой и что он делает: hr-куратор — это тот, кто встречает новичка в первый день в офисе, помогает оформить документы. Затем общается на неформальном обеде в середине испытательного срока. Это необходимо, чтобы новичок мог абстрагироваться от онбординга, инструментов, задач и пообщаться на любые темы, получить поддержку.



    Инструменты


    Для того, чтобы онбординг проходил чётко, мы выбрали себе в помощь такие инструменты: Slack, Kaiten, Google Docs, Nuclino, Miro, Google Calendar.



    Подробнее расскажу, как всё это работает.

    1. За несколько дней до выхода нового сотрудника hr-куратор пишет сообщение в чат онбординга в Slack. В этом же чате проходит вся коммуникация по адаптации и развитию новичков (например, провели встречу — написали итог в чат). Так мы поддерживаем прозрачность процесса для всех участников.
    2. Сразу после этого hr-куратор создаёт карточку новичка на доске онбординга в Kaiten (инструмент очень похожий на Trello). В этой карточке мы отмечаем статус новичка, пишем, на каком он сейчас этапе, фиксируем некоторые детали и заметки от онбординг лидов. Такая визуализация помогает синхронизироваться всей команде, которая онбордит новичка.
    3. В первую неделю ментор знакомит новичка с Nuclino — инструмент, который в нашей компании используется как источник всей технической документации. Внутри Nuclino также лежит описание всего процесса онбординга, в том числе описание ролей, функций и задач ментора.
    4. Доска в Miro с инфографикой процесса онбординга. На этой доске новичок всегда может посмотреть, какие блоки онбординга ещё остались впереди, что ещё предстоит узнать. Кроме того, этот инструмент помогает организаторам и участникам процесса синхронизироваться между собой, а также планировать нагрузку.
    5. Новичок потихоньку начинает знакомиться с компанией и её порядками. Чтобы не запутаться и всегда знать, когда и что его ждёт, мы используем Google Calendar. В нём ведётся календарь командных встреч, на которые ментор приглашает новичка уже с первого дня, а также календарь Intro.
    6. Кроме всего вышеперечисленного у новичка есть помощник Dodo Bot — это наш внутренний бот, который присылает новичку полезную информацию о компании, например, как оформить отпуск или как заказать билеты на конференцию и прочее.

    Процесс: от пребординга до свободного плавания


    Действующие лица и инструменты определены, значит мы готовы к трём месяцам активного знакомства компании и новичка. Процесс состоит из 2 этапов: пребординг (до момента выхода на работу) и онбординг.

    Пребординг


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

    Пребординг начинается за 3 дня до выхода новичка. Основная цель — проконтролировать, что все (ментор, онбординг лид, hr-куратор) помнят о выходе нового сотрудника и готовы к этому моменту. До того как у нас появился пребординг бывали случаи, что в первый день новичок искал себе место для работы в офисе. Или ещё хуже — в первый день начинались жадные поиски команды и ментора. Не повторяйте наших ошибок.

    Что мы делаем на пребординге?

    • Припудриваем ментора, рассказываем, что его ожидает, показываем, где лежит вся необходимая информация.
    • Готовим стол (не тот, о котором вы подумали).
    • Ещё раз пробегаем по списку, всё ли готово.
    • В общем, активные хлопоты.


    Чеклист пребординга

    Если что-то из списка ещё не готово, у нас есть время это исправить.

    Активная фаза онбординга


    Дальше начинается активная фаза, не запутаться в которой помогает схема. Остановлюсь детальнее на её частях и составляющих.



    Жёлтые прямоугольники — фокусы онбординга. То, на что ориентирован и заточен весь процесс и ментор в тот или иной период времени.

    Фокус ментора строится на основе теории о Situational Leadership. Ментор, отслеживая прогресс новичка в разных задачах, регулирует своё вмешательство в его жизнь. Если он видит, что где-то новичок уже неплохо справляется сам, — минимизирует своё участие. Первые 3-4 недели ментор с новичком практикуют парную работу. Кроме того, ментор приглашает новичка на все командные события и мероприятия. После середины онбординга ментор меньше замыкает новичка на себе и больше передаёт его в команду.

    Салатовые прямоугольники — Checkpoints. Ещё их можно назвать реперными точками, отсечками. На Checkpoints к процессу онбординга подключается онбординг лид или hr-куратор. Проходит это в формате встреч, на которых мы спрашиваем новичка о работе с ментором, что получается, где возникают трудности, нужна ли какая-то помощь или поддержка.


    Чеклист Checkpoint'a

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

    Почему Checkpoints проводят онбординг лиды и hr-кураторы, а не менторы?
    Всё гениальное просто. Так как менторы работают с новичком бок-о-бок, их глаз замыливается. Checkpoints похожи на код-ревью в разработке. Взгляд со стороны помогает увидеть свои ошибки или понять, как можно улучшить/упростить код.

    Итоговый Checkpoint. Отдельно хочется рассказать про итоговый Checkpoint. Он проводится в конце второго месяца работы и включает все ключевые знания, которые новичок успел получить за это время. В чеклист вопросов попали такие темы:

    • Technical skills: знание архитектуры системы.
    • Engineering practices: XP и всё, кто с ними связано.
    • Culture: наш бизнес, ценности, их воплощение или нарушение на примерах.
    • Processes: Scrum, LeSS, как формируется фича.
    • Overall: фидбек по онбордингу.

    Итоговый Checkpoint проводится на один месяц раньше, чем завершается испытательный срок. Мы осознанно делаем так, чтобы у нас было время на работу над ошибками, если возникли трудности адаптации.

    Белые звёздочки — Intro. Так мы называем встречи с экспертами и воркшопы. Сюда же относятся все вводные встречи, на которых рассказывают, показывают и делают что-то интересное, что помогает новичку лучше узнать компанию.

    Каждая встреча Intro заточена под свою тематику. Цель: познакомить новичка с компанией, её ценностями, процессами и бизнесом. Например, у нас есть Intro to Dodo Business, Intro to Scrum/LeSS, Intro to culture and principles of leadership.

    В основном все Intro длятся 1-1,5 часа. Но есть парочка технических воркшопов, которые занимают 2 часа.

    Длительность процесса


    Длительность онбординга составляет 3 месяца и на это есть пара причин:

    1. Объёмная программа, которую стоит грамотно дозировать, чтобы не было чисто гуманитарной или «лекционной» недели. Мы решили, что за 2-4 недели невозможно загрузить в новичка все знания. Ведь ему нужно не просто их получить, но и научиться ими пользоваться.
    2. Плавность вхождения в команду и процессы. В первый месяц новичок постепенно понимает, что вообще происходит вокруг и как мы живем. Со второго по третий он потихоньку переходит в самостоятельный режим работы. Появляется готовность взять на себя ответственность.

    Каждая компания должна поэкспериментировать со сроками, чтобы выбрать оптимальное время, которое подходит именно им. Для нас (как и для Яндекс, Adventum, Net by Net) онбординг за 3 месяца показался самым удачным решением.

    Завершение онбординга


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

    Основные сложности


    На каждом витке развития процесса мы сталкивались с небольшими трудностями. Кажется важным о них рассказать, ведь это может сэкономить вам кучу времени или нервов.

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

    • Как быть с Intro, которые предполагают очное участие?
    • Как выдавать велком-пакет? И как вообще не забыть его выдать?
    • Как организовать работу с ментором: неформальное общение, парная работа и так далее.

    Таких моментов набралось довольно много, и некоторые из них мы смогли решить только сейчас. Например, у нас есть воркшопы по декомпозиции и user-story mapping, которые раньше предполагали личное присутствие. Простой переделкой презентации отделаться не удалось. Спустя почти четыре месяца самоизоляции мы смогли перевести всё в online-формат.

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

    В онбординг приходится много вкладываться. Мы считаем, что все усилия, деньги, время и ресурсы — инвестиции в будущее. Верим, что онбординг помогает, и люди хвалят его не просто так. К нам даже приходили «старички» (сотрудники, которые больше двух лет работают в компании) и говорили, что им в своё время не хватало такого процесса. Получается, что пока мы можем подкрепить уверенность в эффективности и пользе онбординга только за счёт такого фидбека.

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

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

    Занимает много времени и у новичка, и у ментора. Мы всегда предупреждаем продакт оунеров, что в первые 1-1,5 месяца в команде будет не +1 человек, а -1. Так происходит из-за активного участия ментора в жизни новичка. Успехи, движение к целям, погружение в практики и так далее. Всё это в сумме отъедает очень много сил ментора. Такой факт мешает продуктовой разработке фич команды и замедляет её.

    Бизнес не всегда готов соглашаться на такие условия. Тогда приходится договариваться о снижении нагрузки на новичка или ментора. Только обсуждение и здравый смысл может помочь в решении данного вопроса. Например, у нас были случаи, когда мы освобождали новичка от некоторых Intro, если он сам хорошо разбирается в теме.

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

    Что было самым крутым за 3 месяца?

    • Больше всего мне понравились Intro. Причём все. Это нереально заряжает, когда видишь настолько болеющих своим делом людей.
    • Общение и обратная связь, куча новых проектов, в которых можно принимать участие.
    • На мой взгляд, всё было очень круто, последовательно и полезно.

    Что можно улучшить?

    • Сложно представить, что ещё улучшить. Раньше я работал в компаниях без онбординга. Приходишь и сразу фигачишь.
    • Сначала было непонятно что делать, чему отдавать приоритет, потому что в первые недели 100500 встреч, но и задачи по работе уже есть.
    • Пока не хватает индивидуального плана развития.

    А вот, что пишут менторы.

    Что было самым крутым за 3 месяца?

    • Главное в онбординге, что он, во-первых, в принципе есть, а, во-вторых, реагирует на обратную связь. Пожалуйста, не останавливайтесь. Спасибо вам за вашу работу!
    • Всё очень круто.

    Что можно улучшить?

    • Хотелось бы сделать онбординг более гибким. Например, использовать существующий процесс с возможностью изменить любую его часть под определённую команду (кроме встреч по фундаментальным принципам компании).
    • Не спешить и делать первые недели адаптации не такими супер-насыщенными.
    • Заранее оценивать время ментора. Если времени у него нет, то легко завалить весь процесс. И стоит учитывать, что чем слабее новичок, тем больше времени потребуется.
    • По моим ощущениям, онбординг близок к идеальному, но неидеальный. Жопой чую, что можно что-то ещё сделать, но что не знаю.

    Мы собрали отзывы со всех участников: менторов и новичков. И по итогам опроса взяли в фокус заботу о менторе и его времени.

    Заключение


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

    И! Если в паре ментор-новичок что-то не работает, это не значит, что кто-то из них мудак. Возможно, что-то не так с процессом и где-то он больше мешает, чем помогает.
    Dodo Pizza Engineering
    О том как IT доставляет пиццу

    Похожие публикации

    Комментарии 44

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

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

              +2

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

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

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

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

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

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

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

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

                      +1

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

                +2
                Сейчас мы находимся на цифре 100.

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


                К тому же, всегда можно посмотреть наш сайт, мобильное приложение или спросить наших инженеров в чате Dodo Pizza Engineering в Telegram.
                  –1

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

                    0
                    Ответила выше в другом вашем комментарии.
                  0

                  Ну вот "взрослый опенсорс" на гитхабе: https://github.com/dodopizza У некоторых репозиториев есть даже по 30 звёздочек.

                  +1
                  Присоединяюсь к данному вопросу, будучи клиентом никаких особых IT-прорывов за Додо замечено не было в клиентском обслуживании, ну разве что вебка на кухне и цены чуть выше (теперь знаю почему) и… все. Даже до мобильных POS-терминалов курьерам не доросли еще в отличии от конкурентов.
                  PS Напомнило:
                  Сколько менеджеров среднего звена требуется, чтобы вкрутить лампочку… Инженер чтобы вкручивать лампочку, а 7 менеджеров чтобы говорить ему как не правильно он это делает.
                    +1
                    Спасибо за комментарий.

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

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

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

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

                  Надеюсь, ваши новые 150 разработчиков смогут исправить эти недочеты :)
                    0

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

                      +1
                      Это в дополнение к тем 100, которых вы уже наняли?!
                      Может что-то в консерватории подправить критерии найма поменять?

                      Вот я помнится несколько лет назад проходил у вас собеседование.
                      Отказали, т.к. по словам руководителя мои взгляды не соответствовали принятым в компании.
                      Не хотелось бы показаться самонадеянным, но мои взгляды точно бы не позволили случиться ситуации, на которую пожаловался vlad49 выше.
                        0
                        Михаил, если я правильно прочитала между строк, вы говорите, что ваши взгляды могли бы помочь сделать приложение, сайт, а вместе с ними и жизнь клиентов лучше. Верно?
                        Прошло несколько лет, многое могло измениться в вас и в нас. Оставлю ссылку на наши актуальные вакансии, может быть пришло время поработать вместе.
                          +1
                          Нет, Олеся, работать в компании, где на одного тестировщика приходится 17 разработчиков мне совсем не хочется. Видимо, за последние несколько лет взгляды компании не так уж и изменились…

                          За ссылку на ваши актуальные вакансии спасибо, конечно. Но там опять же требуются разработчики, а не тестировщики.
                      +2

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

                        +2

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


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


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

                        +2
                        Мода называть красивыми иностранными словами обычные понятные вещи ещё не прошла.
                        Испытательный срок, стажировка, вводный инструктаж, кадровик…
                          0
                          Я уже обращал на это их внимание в одном из комментариев в другой статье. Бесполезно, увы.
                            –5
                            Да, и выбирать себе имя типа lttlcrazy, видимо, тоже считается в Додо очень здорово.
                            Может и мне в резюме оставить контакт наподобие bigmadness@gmail.com…
                            +2
                            Я не специалист в теме онбординга, поэтому прошу простить за дилетантский подход, но мне кажется, что для коллектива в 100 человек, вполне возможно обойтись просто здоровым отношением в коллективе.

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

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

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

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

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

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

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

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

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

                                +1

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

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

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


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

                                    0
                                    Так а не боитесь при таком подходе что останутся довольно средние люди? Или как таковой нет политики сделать лучшее IT? Ну т.е. то что вы написали это подход больших компаний, но они не всегда эффективны в плане разработки полезной функциональности
                                      +1
                                      Почему средние? Цикл найма предполагает довольно серьёзный отбор на старте.

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

                                      Уровень кандидата в сравнении с командой Додо дают ответ на вопрос — усилит человек нашу команду или нет? Обладает ли он такими навыками, которых у нас нет или их немного? Если да, стоит делать оффер».
                                    +2
                                    Я не из Додо, но решил поделиться как у меня в компаниях было. Всего два случая за несколько лет, правда.
                                    1 случай. Лид на хорошей должности просто забивал на трудовые обязанности и «делигировал» на сотрудников свою работу, красиво отмазывался и делал процентов 20 от своих обязанностей, на втором месяце с ним поговорило руководство и он решил уйти сам.
                                    2 случай. Один обычный специалист хорошо начал, но был достаточно замкнут в себе, а потом начался театр — кошка рожает, застрял в пробке, заболел на две недели. Тоже пытались сначала разобраться в причинах и помочь человеку, но он продолжил забивать на работу и тоже ушел по «собственной» инициативе, рассчитали его за фактически отработанные дни, насколько я помню. Это было в его интересах, так как пропуски работы фиксировались каждый раз.

                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                  Самое читаемое