Avito Playbook: initial commit

    Многие компании публикуют в open-source свой код. Мы тоже не исключение. Инженеры Avito активно публикуют на GitHub свои наработки. Но ведь код — это не единственное, чем компания может поделиться с сообществом. Не меньший интерес представляет описание различных процессов, гайдлайны и лучшие практики. Сегодня мы делаем первый шаг в этом направлении и выкладываем на GitHub первую версию Avito Playbook. Что это и зачем нужно — рассказываю под катом.



    Что такое плейбук


    Изначально термин playbook пришел к нам из американского футбола. Это что-то вроде свода правил, по которым играет команда, и признанных ими лучших практик, принятая стратегия и тактика. Для компании он играет такую же роль — это свод стандартов, которые команда вырабатывает с течением своей жизни. Это могут быть ценности, правила найма, практики code review, да даже список любимых баров, в которые команда ходит по пятницам. Playbook вмещает в себя всю информацию, с которой вы знакомите новичка в первые недели его работы.


    Строго говоря, плейбук у вас скорее всего уже есть. Это может быть пачка гуглодоков, раздел в Confluence, репозиторий в VCS. Главное, придерживаться двух основных правил: информация должна быть актуальной и структурированной.


    Авито плейбук — первая версия


    За 10 лет мы наработали ну очень много интересных материалов, которыми хочется поделиться. Но перед тем, как переносить их в open-source, нужно проделать много работы. Старую информацию актуализировать, недостающую собрать, секретные данные затереть и спрятать под грифом. Процесс может затянуться на долгие месяцы. Но в полном соответствии с Agile-манифестом мы решили работать итеративно и постепенно делиться новой информацией.


    В первой версии мы рассказываем про:


    • Авито в цифрах — сколько у нас сотрудников, разработчиков, RPS и серверов;
    • миссию и ценности — куда и как мы идем;
    • организационную структуру — юниты, кластеры и рабочий распорядок;
    • бизнес-процессы — OKR, performance review;
    • технологические процессы и практики — релизы, developer experience framework, технический радар, open-source;
    • условия работы — обучение, тренинги, конференции и прочие плюшки.

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


    Мы очень рассчитываем на ваш фидбэк. Если вы хотите узнать больше о каком-то аспекте работы компании, устройстве процесса или чем-то еще, то смело заводите issue на GitHub. Их же можно использовать и для того, чтобы задавать вопрос нашим инженерам по разным направлениям — постараемся ничего не оставить без ответа.

    Авито

    252,82

    У нас живут ваши объявления

    Поделиться публикацией

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

    Комментарии 14
      0
      Спасибо, отличное начинание. Думаю многим маленьким компаниям эта информация будет очень полезна.
        +9
        Интересное начинание.
        Термин playbook прочно с Ansible ассоциируется, подумал вы про свою автоматизацию рассказать решили.
          +2
          Да уж, зашёл в пост посмотреть на интересные Энсибл-плейбуки :)
          +1
          А мне не нравится модерация вашего сервиса — тысячи мошенников в некоторых сферах. Может вы все там отличные специалисты, но это все портит.
            0
            Мне вот тоже интересно, кнопочка 'Пожаловаться' на что нибудь влияет? Иногда очевидно левое объявление с тысячей просмотров и наверняка не одной жалобой… висит себе неделями.
            И кстати, кому можно подкинуть идею по функционалу, чтобы она не потерялась на уровне службы поддержки, а дошла до заинтересованных лиц, чтобы потом получить гонорар благодарность? ))
              +1
              Жалобы, которые мы получаем через кнопку «Пожаловаться», проверяются. Однако время обработки таких сообщений может затягиваться; при этом реакция на обращения в Службу поддержки будет дана вам всегда, как и сообщен сам результат проведенной проверки. Будем благодарны за помощь.

              Это же касается идей по функционалу. Ни одна из идей не «теряется» на уровне Поддержки, обратная связь собирается и передается в соответствующий отдел в рамках действующих внутренних правил.
              +2
              Тоже не фанат продукта, но в последнее время Авито как IT-компания оч подтянулась, не боятся писать про внутреннюю кухню, хорошие технические статьи и доклады, надеюсь, продукт подтянется со временем
                0
                Кому интересна внутренняя кухня, если внешняя — гуано?
                  +3

                  Например, мне.

              0

              А почему репозиторий dockerfiles как бы есть, но пустой? https://github.com/avito-tech/dockerfiles

                0
                Отличный вопрос, чтобы закинуть в issues в плейбуке!
                0

                Не холивара ради, почему не использовать ResourceView и не создавать классы User, Token с методами get,post,put и далее?

                  0
                  Не очень понял, к чему вопрос :) Проясните?
                  +2
                  Очень крутой шаг к созданию имиджа открытой компании. Браво! А как давно процесс change management'а для playbook'а у вас уже ведется? Кто и как принимает решения по внесению изменений? Как часто случается, что обсуждения заходят в тупик и в километры неконструктивных и не продвигающих вперед споров в issue discussion?

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

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